Should Interface implementations be independent

Question

I have come across some legacy code that has raised all my heckles as an Object Oriented Programmer.

Here's the pattern used often: An interface has two implementations and one implementation calls a method of the other.

Now, I think it should be refactored so that the implementations do not know about each other. It is simple enough HOW to do it. What I cannot figure out clearly - & hoping good people of SO would help me with - is WHY.

I can see the theoratical reason - it is a terrible object-oriented design. But I am playing the devil's advocate here and asking - what is the practical disadvantage of two implementation having knowledge of each other. Why should time & money be spent to get rid of this (in my mind) anti-pattern?

Any info or links on this will be appreciated.

Answer 1

There is nothing wrong with an implementation1 of interface1 being aware of or interacting with implementation2 of interface1.

I think you have just spotted an intended or un intended implementation of proxy pattern http://en.wikipedia.org/wiki/Proxy_pattern

Hope this helps :)

Answer 2

I can see the theoratical reason - it is a terrible object-oriented design.

Why? It sounds entirely reasonable to me.

For example, suppose I want to decorate every call - e.g. to add statistics for how often a call has been made, or add some authorization check etc. It makes sense to keep that decoration separate from the real implementation, and just delegate:

public class DecoratedFoo : IFoo
{
    private readonly IFoo original;

    public DecoratedFoo(IFoo original)
    {
        this.original = original;
    } 

    public string Bar() // Defined in IFoo
    {
        // Update statistics here, or whatever
        return original.Bar();
    }
}

Why do you view that separation of concerns to be "terribly object-oriented design"? Even if the decorated class knows about a specific implementation of IFoo and calls members which aren't part of IFoo itself in order to make things more efficient, it doesn't seem particularly awful to me. It's just one class knowing about another, and they happen to implement the same interface. They're more tightly coupled than the example above which only knows about IFoo, but it's still not "terrible".

Answer 3

My thoughts on this are

1. Suppose in the due course of time if you are retiring one implementation and you have kept that separately then there is no change in the other and you dont need to test that. If there is no separation you need to spend time in separating and testing the other implementation.

2. Its always cleaner to have single responsibility.

Answer 4

That method of the "other implementation" that the first implementation calls is what I would call a library function. Put it in a separate module/file/project/whatever (depends on your language/dev env) and have both implementations include it and use it from there.

There is absolutely nothing wrong with two implementations of some interfacing containing common code, but of course that common code should probably be separated from each implementation so that you can load either into your program without having to load the other.