Spring为什么用接口代替抽象类？

Question

Sometimes,we use Spring in some automatic way. Today i was thinking and searching the followig.

Why we use to do this in Spring? @Autowired IAnimal animal;

And why we usually dont do something like this? @Autowired Animal animal;

Animal is an abstract class,and in our beans.xml ,or using @Autowired with Qualifier,we can specify which implementation we want.A Dog,a Cat,etc.

I know i am wrong,but i would like some explanation about the cons of the Abstract Class approach instead of Interfaces approach.

Now,if we want to inject some ORM implementation,Ibatis or Hibernate,it makes more sense to use interfaces injection,because both providers dot not share an abstract class,but they share same Interface.But any other example?

Thanks in advance!

Answer 1

In the early Spring versions, declaring an interface could be mandatory to make the bean working with some features that required proxy class generation via interface.
Recent Spring versions don't have any more this restriction. So now, in Spring (as without Spring) a shared good practice is to make a bean class implement an interface only if it makes sense : KISS (Keep it simple and stupid) principle.
Abstraction has a cost and we want to accept it only for good reasons.

Answer 2

The main advantage of an interface is multiple inheritance. Java does not allow you to extend multiple classes, and there are sensible reasons for this. Some languages allow this (eg C++ and others) and there are reasons why it can be useful, but Java doesn't.

However, you can implement multiple interfaces. There is also a more subtle point about what an interface really is vs. what a abstract class is.

If you have class MyClass extends MyAbstractClass , you are effectively saying "all instances of MyClass are instances of MyAbstractClass ". This applies to most common metaphors applied to OOP. For example, all Dogs are in fact Animals.

However, an interface just defines some behaviour. In a lot of programming contexts, it makes more sense to define things by what they can do , rather than what they are . Eg A Dog is a Barkable, Runnable, Walkable, Feedable, etc... Here you are defining what it can do.

With your Spring example, you probably don't care that the object you are working with is actually an Animal, you probably just care that it can do all the things Animals can do. That is a major reason why interfaces are preferred.

Answer 3

It really depends on your project.

You want to use an interface ( IAnimal ) in cases where you may have multiple implementations of such interface and you are going to decide which one to use during packaging.

For example, let's say that implementations on IAnimal need to be different based on whether you are under Windows or Linux, during packaging you may want to prepare two different versions of your application (one for Windows and one for Linux) and each package will contain only the code meant for that platform. In such case, in one package you will include the implementation for Windows and in the other case the implementation for Linux.

Another common scenario is teams working as "black boxes" with one team needing the dependency of another team. In that case all that is agreed between the teams is the "contract" of the implementation (that is: the interface). Your team will be able to work against a "mock" implementation built by you while the other team develops the one that will eventually be released.

Otherwise, the general advice is to "keep it simple" and add the interface only if it's demonstrated that it's needed. Not doing so will result in much more code than necessary, which will only make everybody's life difficult.