为什么转换为接口而不是转换为类 java？

Question

I have come across some java classes used in the spring framework. First, there is the beans in the applicationContext.xml

<bean id="someBean" parent="txProxyTemplate">
    <property name="target">
        <bean class="path.to.bean.impl.SomeBeanImpl">
            ...
        </bean>
...
</bean>

And I have the interface ISomeBean , and its implementation SomeBeanImpl Then, I have another class which uses ISomeBean.

public class SomeOtherClass {
  ...
    public function doStuff() {
        ...
        ApplicationContext ctx;
        SomeBean theBean = (SomeBean) ctx.getBean; 
   }
}

I want to know why do we cast to an interface instead of casting to the class.

Answer 1

Why would you want to tie SomeOtherClass to a specific implementation? Using the interface, you get loose coupling - you can test against a fake implementation, or switch to a different implementation later.

This is a large part of the benefit of inversion of control - you aren't as tightly coupled to your dependencies as if you instantiate them directly within the class.

Answer 2

The logic behind such type of casting is to give freedom to the Spring IOC and Dependency Injection. One of the benefits of using this approach is that the coupling between classes is very loose,

for example in ur case if some fine morning u decide to change the code of ISomeBeanImpl, u don't need to change anything else as long as functionality doesn't change..

Have a look on Spring IOC documentation , the idea will be more clear...

Answer 3

One great benefit of using dependency injection is that your classes doesn't have to know which implementation is used, only that they need one implementation. Thereby it makes sence to cast it to an interface.

You should not however confuse it with what can or can't be done.

Answer 4

You cast to an interface to keep your code generic and loosely coupled. Once you cast an object to a concrete class you have added a tight coupling between your object and its collaborator. Should the class type of the collaborator change then your object's cast operation will potentially break - causing a ClassCastException. If instead we use an interface you can freely change the implementing class type of the collaborator without worrying about implications on clients.

Answer 5

There is the style-aspect of it - loose coupling and all that.

More concretely: If you are using AOP (which Spring does by default for many built-in functionalities, transactional support for instance) and for instance cglib proxying, the actual bean will not be of the implementation class, it will be aa dynamically created proxy-class. In that case, your application will fail with all sorts of ClassCast-like exceptions. This can come as a nasty surprise down the road if you make changes that inadvertently actives the proxying behaviour in spring.

Answer 6

A dependency injection framework have two goals:

1. to manage the lifecycle of object, that is, how they are created.
2. to decouple the code from concrete implementation, that is, you can switch between implementations of an interface without recompiling

If you are not interested in 1 nor 2, obviously you don't need dependency injection: simply create the bean yourself SombeBeanImpl = new SomeBeanImpl() .

If you are interested only in 1 but not 2, you could cast the bean you obtain to SomeBeanImpl , but then you are bound to always use it. I suspect there is a way to specify in Spring that you are just having one implementation and you don't have an interface, but I'm not sure.

If you are interested in 2, you are by definition interested in 1 as well. Indeed, if you don't want to explicitely state what concrete class to instantiate, you delegate that to a factory that control the creation of objects. This is what a dependency injection framework actually is, a complex factory.