C# OO problema de diseño con anulación de métodos

Question

Situación:

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

Asamblea 1 es una aplicación que otros desarrolladores pueden utilizar. Les daremos solo el .dll para que podamos publicar actualizaciones desde la aplicación si no cambiamos la API. Los desarrolladores no pueden cambiar el marco en el ensamblaje 1

Los métodos son virtuales, por lo que los desarrolladores pueden sobrescribir los métodos para implementar su propia lógica si es necesario.

El problema es que un desarrollador no puede anular otherMethod de la clase B, , puede anularlo, pero la Clase A siempre llamará al método de la Clase B y no al método reemplazado.

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

Asamblea 2 haves una referencia al ensamblaje 1

clase parcial no funciona porque tiene que ser el mismo conjunto y no funcionará durante 2

¿Hay patrones de diseño para este problema? ¿O hay alguna otra solución con reflejo o algo así?

EDITAR añadido un ejemplo de código:

/* 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

debe refactorizar

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... 
    } 
} 

con esta refactorización hecho, los desarrolladores pueden utilizar la aplicación por defecto utilizando el constructor vacío. si necesitan alguna otra lógica que simplemente tienen que implementar la interfaz IClassB y simplemente pasarla en el otro constructor.

el uso en el montaje 2 sería algo como esto

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

Parece que puede que tenga que utilizar un stragey o un patrón de plantilla para resolver este problema.

Answer 3

Existen varios patrones de diseño que podrían funcionar. Aquí está la lista que me vino a la mente (en este orden) mientras leía su publicación.

1. ADAPTER
2. DECORATOR
3. TEMPLATE METHOD.

Answer 4

Suponiendo que A llama a una instancia de ExtendedB que se hace referencia a través de una variable de tipo B, y el método está marcado virtual en B y override en ExtendedB, la llamada debe ser polimórficos. Deberia de funcionar. Quizás puedas mostrar algún código.

Answer 5

Es difícil de decir sin el código real, pero teniendo su diagrama (por cierto, me encanta el arte ASCII!) A su valor nominal, lo sugeriría que la clase A haga referencia a una interfaz en lugar de estar codificada de forma rígida para la clase B.

De esta manera:

// ----- 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... 
    } 
} 

En su Asamblea 2, asigne Otrosb a claseA:

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

Ahora cada vez claseA ejecuta el myDependentObject.OtherMethod(), será recogida en el montaje 2 en lugar de ensamblaje 1 Definiciones .

HTH ...

Answer 6

¿Puede proporcionarnos algún código de reducción del ejemplo? Aprecio el arte ascii, pero sospecho que el problema puede estar en cómo A consigue la B en la que funciona. Si está creando una instancia de su propia copia, entonces no hay forma de que pueda invocar el método reemplazado en la clase derivada.

Dicho esto, también estoy de acuerdo en que la interfaz de refactorización sugerida por otros es el camino a seguir. Permita que A funcione desde la interfaz IB, por lo que debe usar un implementador proporcionado de IB, en lugar de generar el suyo propio. De esta forma, no importa si el objeto proporcionado es una B, una subclase de B o algo completamente diferente. También hace que las subclases A, B y Bs sean más comprobables, lo cual es Algo bueno.