C# problème de conception OO avec priorité des méthodes

Question

Situation:

Assembly 1 
________________________    ________________________ 
| Class A    |   | Class B    | 
|-----------------------|   |-----------------------| 
| Method someMethod  |---------->| Method otherMethod | 
|      |   |      | 
|_______________________|   |_______________________| 

Assemblée 1 est une application que d'autres développeurs peuvent utiliser. Nous leur donnerons seulement le .dll afin que nous puissions publier des mises à jour de l'application si nous ne changeons pas l'API. Les développeurs ne peuvent pas modifier le framework dans l'assembly 1

Les méthodes sont virtuelles afin que les développeurs puissent remplacer les méthodes pour implémenter leur propre logique si nécessaire. Le problème est qu'un développeur ne peut pas remplacer otherMethod de la classe B, il peut le remplacer, mais la classe A appellera toujours la méthode de la classe B et non la méthode surchargée.

Assembly 1 
________________________    ________________________ 
| Class A    |   | Class B    | 
|-----------------------|   |-----------------------| 
| Method someMethod  |----XX---->| Method otherMethod | 
|      |   |      | 
|_______________________|   |_______________________| 
       \         | 
       \         | 
        \         | 
Assembly 2   \         | 
        \    ________________|_______ 
        \    | Class ExtendedB  | 
         \    |-----------------------| 
         \____________>| Method otherMethod | 
            |      | 
            |_______________________| 

Assemblée 2 nantis d'une référence à l'assemblage 1

classe partielle ne fonctionne pas car il doit être le même ensemble et ne fonctionnera pas plus de 2

Y at-il des modèles de conception pour ce problème? Ou existe-t-il une autre solution avec réflexion ou autre chose?

EDIT Ajout d'un exemple de code:

/* ASSEMBLY 1 */ 

namespace Assembly1 
{ 
    public interface IAService 
    { 
     void TestMethod3(); 
     void TestMethod4(); 
    } 

    public interface IBService 
    { 
     void TestMethod1(); 
     void TestMethod2(); 
    } 

    public class AService : IAService 
    { 
     // Base implementation of AService 
     public virtual void TestMethod3() 
     { 
      //do something 
     } 
     public virtual void TestMethod4() 
     { 
      //do something 
     } 
    } 

    public class BService : IBService 
    { 
     // Base implementation of BService 
     public virtual void TestMethod1() 
     { 
      //do something 
     } 
     public virtual void TestMethod2() 
     { 
      //need to call AService implementation from assembly 2 
     } 
    } 
} 





/* ASSEMBLY 2 */ 
namespace Assembly2 
{ 
    public class NewAService : AService 
    { 
     public override void TestMethod3() 
     { 
      //default implementation which could be overridden 
      base.TestMethod3(); 
     } 

     public override void TestMethod4() 
     { 
      //default implementation which could be overridden 
      //An implementation of IBService Should be called 

      base.TestMethod4(); 
     } 
    } 
} 

Answer 1

vous devez factoriser

public interface IClassB 
{ 
    void SomeMethod(); 
} 
public Class A 
{ 
    private IClassB myInstanceB = new ClassB(); 

    public ClassA(){} 

    public ClassA(IClass B) 
    { 
     myInstanceB = B; 
    } 

    public void SomeMethod() 
    { 
     myInstanceB.SomeMethod(); 
    } 
} 

public ClassB : IClassB 
{ 
    public void SomeMethod() 
    { 
     // some wicked code here... 
    } 
} 

avec ce refactoring fait, les développeurs peuvent utiliser l'implémentation par défaut en utilisant le constructeur vide. s'ils ont besoin d'une autre logique que celle qu'ils ont juste pour implémenter l'interface IClassB et juste la passer dans l'autre constructeur.

l'utilisation dans l'assemblage 2 serait quelque chose comme ça

public class NewFunctionalityClass : IClassB 
{ 
    public void SomeMethod() 
    { 
     //something else 
    } 
} 
public TestClass() 
{ 
    public void ShowMethod() 
    { 
     var defaultObject = new ClassA(); 
     defaultObject.SomeMethod(); // default implementation 

    var otherObject = new ClassA(new NewFunctionalityClass()); 
    otherObject.SomeMethod(); // here the new implementation will run 
    } 
} 

Answer 2

Il semble que vous devrez peut-être utiliser un stragey ou un motif de modèle pour résoudre ce problème.

Answer 3

Plusieurs motifs de conception peuvent fonctionner. Voici la liste qui me vient à l'esprit (dans cet ordre) en lisant votre message.

1. ADAPTER
2. DECORATOR
3. TEMPLATE METHOD.

Answer 4

En supposant que A appelle une instance de ExtendedB qui est référencé par une variable de type B, et la méthode est marquée virtual dans B et override dans ExtendedB, l'appel doit être polymorphes. Ça devrait marcher. Peut-être pourriez-vous montrer du code.

Answer 5

Il est difficile de dire sans le code réel, mais en prenant votre diagramme (en passant, aiment l'art ASCII!) À leur valeur nominale, je suggérerait que la classe A a une référence à une interface plutôt que d'être codée en dur à la classe B.

Comme ceci:

// ----- this is in Assembly 1 ----------- 
public ClassA 
{ 
    public MyInterface myDependentObject; 
} 

public interface MyInterface 
{ 
    void OtherMethod(); 
} 

public class ClassB : MyInterface 
{ 
    public void OtherMethod() 
    { 
     // some code here... 
    } 
} 


// ----- this is in Assembly 2 ----------- 
public class OtherB : MyInterface 
{ 
    public void OtherMethod() 
    { 
     // some code here... 
    } 
} 

Dans votre Assemblée 2, attribuer Autresb à ClasseA:

// ----- this is in Assembly 2 ----------- 
OtherB b = new OtherB(); 
ClassA a = new ClassA { myDependentObject = b }; 

Maintenant, chaque fois que ClassA exécute le myDependentObject.OtherMethod(), il ramassera de l'assemblage 2 au lieu de l'assemblage 1 définitions .

HTH ...

Answer 6

Pouvez-vous fournir un code réduit de l'exemple? J'apprécie l'art ascii, mais je soupçonne que le problème peut être dans la façon dont A obtient le B sur lequel il travaille. Si c'est l'instanciation de sa propre copie, il est impossible d'appeler la méthode substituée dans la classe dérivée. Cela dit, je suis également d'accord que le refactoring d'interface suggéré par d'autres est la voie à suivre. Permettre à A de fonctionner à partir de l'interface IB, il doit donc utiliser un implémenteur fourni de IB, plutôt que de générer le sien. De cette façon, cela n'a pas d'importance si l'objet fourni est un B, une sous-classe de B, ou quelque chose d'autre entièrement. Il rend également les sous-classes A, B et Bs plus testables, ce qui est une bonne chose.