views:

231

answers:

6

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();
        }
    }
}
A: 

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

David Williams
A: 

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.
Jerod Houghtelling
This doesn't explain why the call apparently isn't being resolved virtually. Let's diagnose before prescribing.
Steven Sudit
+3  A: 

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.

Steven Sudit
+3  A: 

hi

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
   }
}
nWorx
I don't see how this helps.
Steven Sudit
so you can easily add new functionality in assembly2
nWorx
i've added some code example for youit helps because you wont have to override or virtualize any methods anymore -> simpler
nWorx
Please see my comments to code4life for an explanation of why I don't see this as being a helpful answer.
Steven Sudit
+3  A: 

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

code4life
Having a reference to a base class is not hard-coding. It should work just fine, so I see no reason to complicate this with interfaces, particularly when we don't yet know why it doesn't already work.
Steven Sudit
@Steven, the OP was asking for a design pattern or best practice approach. In that case, I'd still stick to using interfaces. Also I think it's pretty evident why it doesn't work - ClassA is establishing a hard dependency to ClassB somewhere in Assembly 1. Another words, we have a "separation of concerns" issue here. Interfaces is the best approach to handle these cases, because it loosens the dependency and allows for these to be resolved further down the process (i.e., in Assembly 2 per my example).
code4life
I thought the best practice is to use inheritance when you actually want inheritance, as we do here. But my deeper concern is that, from all that we have heard, inheritance with a virtual method should have led to polymorphism, yet it didn't. I'd like to understand why, before punting on inheritance and working around the problem. The problem described is *not* reproducible.
Steven Sudit
you shouldn't use that much inheritance..composition over inheritance -interfaces are the best solution for this kind of problem-your way cannot work, because of the hard dependency like code4life already wrote
nWorx
@Steven, overriden virtual methods is automatically handled by the compiler. The reason for why the override not being invoked is not rocket science. The reason clearly is because the classA instance is not referencing the extendedClassB instance. Inductive reasoning leads us to recognize that the classA instance is hard-referencing to an Assembly1.classB instance somewhere in its code. There's no other way that an override would fail. My point is, this whole design begs for trouble. Interface-driven approach allows for signature-only based relationships, which is what is required here.
code4life
Clarification on signature-based relationships: Assembly2.extendedClassB and Assembly1.ClassB both have the same method signature, but different execution. All classA cares about is that the method signature is correct, in order to invoke the method - based on what I see from the diagram.
code4life
If it's failing because classA is referencing a classB instance in Assembly1 instead of an extendedClassB instance, then changing the relationship to implementation instead of inheritance won't fix anything. Whether interfaces are more appropriate than inheritance or not, that's completely orthogonal to the issue.
Steven Sudit
@nWorx: No, interface implementation is not the same thing as composition. You can do composition without interfaces, or do interfaces without composition. Composition is only better than inheritance when there isn't an Is-A relationship.
Steven Sudit
@Steve, I'm not implying that changing to interface will immediately fix the problem. The OP describes a problem that is problematic from a design perspective. As an addendum to your comments, if the failure is due to classA referencing classB instance in Assembly1, inheritance won't work either. Additionally, with inheritance, you would have to make some ugly hacks to get the correct code to invoke. The fundamental problem is the relationship definition between classA and the 2 classes classB and extendedClassB.
code4life
Further to my comment, the OP's design of the relationships between the classes need to be redefined. If you want classA to properly invoke either classB or extendedClassB, then defining this via interfaces is the best approach to take, IMO.
code4life
@code4life: It may be, but that's irrelevant.
Steven Sudit
@Steven, you're free to have your own opinions... defining contracts between classes and assemblies using inheritance is definitely possible. However I believe it's not at all desirable, especially in the long run.
code4life
With all due respect, you're assuming your conclusion instead of arguing for it. Why should we view this as a matter of "defining contracts between classes"? More simply, one class is exposing some behavior that its children may choose to modify. We don't necessarily *want* to allow non-children to simply implement some interface in order to fit in. There's a big difference between is-a (inheritance) and shares-certain-commonalities (implementation), and the former has not become obsolete just because the latter can be convenient. I've said my piece.
Steven Sudit
+1  A: 

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.

philxan
No, it's really not. Sometimes you want to inherit so that you can selectively override some methods and not others, and so that you can selectively chain to the base implementation as well. Interfaces are a good thing, but they are not a direct replacement for inheritance, nor does switching to them offer us any insight into why inheritance was not polymorphic.
Steven Sudit