C# OO design problem with override from methods

Situation:

Assembly 1
________________________             ________________________
| Class A               |           | Class B               |
|-----------------------|           |-----------------------|
| Method someMethod     |---------->| Method otherMethod    |
|                       |           |                       |
|_______________________|           |____________________开发者_高级运维___|

Assembly 1 is a application that other developers can use. We will give them only the .dll so we can publish updates from the application if we don't change the api. The developers can't change the framework in assembly 1

Methods are virtual so developers can override methods to implement there own logic if needed.

The problem is that a developer can't override otherMethod from class B, he can override it but Class A will always call the method from Class B and not the overridden method.

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

Assembly 2 haves a reference to assembly 1

Partial class doesn't work because it must be the same assembly and will not work over 2

Are there design patterns for this problem ? Or is there a other solution with reflection or something ?

EDIT Added a code example:

/* 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();
        }
    }
}

---

you should refactor

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

with this refactoring done, developers can use the default implementation by using the empty constructor. if they need some other logic than they just have to implement the interface IClassB and just pass it in the other constructor.

the usage in assembly 2 would be something like this

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

---

Assuming that A calls an instance of ExtendedB that is referenced through a variable of type B, and the method is marked virtual in B and override in ExtendedB, the call should be polymorphic. It should work. Maybe you could show some code.

---

It's hard to tell without the actual code, but taking your diagram (by the way, love the ASCII art!) at face value, I would suggest that Class A have a reference to an interface rather than being hard-coded to Class B.

Like this:

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

In your Assembly 2, assign OtherB to ClassA:

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

Now whenever ClassA executes the myDependentObject.OtherMethod(), it will pick up from assembly 2 rather than assembly 1 definitions.

HTH...

---

Can you provide some cut down code of the example? I appreciate the ascii art, but I suspect that the problem may be in how A gets the B that it works on. If its instantiating its own copy, then there's no way it can call the overridden method in the derived class.

That said, I also agree that the interface refactoring suggested by others is the way to go. Allow A to work from interface IB, so it must use a provided implementer of IB, rather than generate its own. That way it doesn't matter whether the object provided is a B, a subclass of B, or something else entirely. It also makes A, B, and Bs subclasses more testable, which is A Good Thing.

---

It appears that you may need to use a stragey or a template pattern to solve this issue.

---

There are several design patterns that might work. Here is the list that came to my mind (in this order) while reading your post.

1. ADAPTER
2. DECORATOR
3. TEMPLATE METHOD.