依赖注入：基于接口和类的松耦合机制之间的区别？

Question

Suppose, I have 2 configurations.

First one:

interface I {
    ...
}

class A implements I {
    ...
}

class B implements I {
    ...
}

class Component {
    I i;    
    Component (I i) {
        this.i = i;
    }
}

Second one:

class C {
    ...
}

class A extends C {
    ...
}

class B extends C {
    ...
}

class Component {
    C c;    
    Component (C c) {
        this.c = c;
    }
}

What in the difference between those two configurations which are using two different loose coupling mechanisms (based on interface and based on class)?

Why should I need to use interface over class?

Answer 1

An object can implements multiple interfaces but can only extends one class, so sometimes the user of your loose coupled library may not be able to extends your class.

when you extends, you incorporate the code of the superclass into yours, sometimes there is no code to incorporate so implements is better suited.

Finally it is not the same paradigm, when you write "B extends A" you say "I am A, I do the same things, but I can also make other things". When you write "B implements A" you say "I am B, but you can treat me as an A".

Long story short, the only practical reason would be the first.

Answer 2

Mainly, using classes is a more heavy approach. Base classes usually contain concrete (non-abstract) methods. And if you derive from them you will need also to inherit such concrete methods, which you may not want.

For example, imagine that you want to benefit from composition design patterns like the decorator pattern . Here, your decorator needs also to derive from the base class and will inherit the concrete methods. However, your decorator will not need the concrete method to function.

In summary, it is more hard/unclean to do object composition if your abstractions are class-based.

Abstraction through interfaces on the other hand, does not force implementing classes to inherit any concrete method implementation. Therefore, it is more clean.

Answer 3

A hierarchy based upon interfaces is a good desing approach, because it eases implementation: You can always implement an interface, but not always you can extend a class (for example, a final class). Or, in the other hand, not always a class' author want it to be extended.

So, you are highly interested on using interfaces over classes, because in this way you may accept a wider set of implementations. For example:

Using classes:

class Component
{
    AbstractList c;
    Component (AbstractList c){...}
}

... Component would accept ArrayList or Vector.

Instead, using interfaces:

class Component
{
    List c;
    Component (List c){...}
}

... Component would be able to accept ArrayList, Vector, CopyOnWriteArrayList...