This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I just have been seeing few projects recently. There is a strange feeling I have.
We normally (if we are using Spring, then most of the times) expose our libraries to application with interface rather directly with class. Sure I know that if we have multiple implementation of methods we should use interface, I also understand the conditions when we should choose abstract class over interface but to my surprise I fail to understand
exposing entire class structure with interfaces. For example
If we are use Action (Struts) and Controller(Spring) , in either case we inject Service Interface.
Service Interface is accessed by its Impl method ,which injects DAO Interface
DAO Interface is accessed by its Impl Of course you may add few more layers viz. Business and access that with BusinessImpl class .*
I understand the reason if you have multiple class implementing this interface giving it real meaning, but why there is 90 % times one to one mapping of One class One interface might be fore sighting future to add some more classes with similar methods ,again a future which 95% + times never comes in any project I guess.
Of course I guess you will not answer me saying it’s done because of IoC principal because we anyway if need only one class ,we still can follow IoC and can inject direct class object does no harm and even reduce code and load in JVM (Load in JVM I am still not sure about , Since they say Interface don’t create objects but JVM load balancer take reverse hit using so many interfaces and classes with only one to one mapping)
* Impl is just the most common name you can use whatever.
I am not aware of how things work in Struts or Spring, but stating in general terms its often recommended to program to interface not implementation. Usually when someone provides an API they dont expect the consumer of the API to be dependent on the implementation of the API, rather the consumer should be bound to the contract of the API. Suppose we didn't have the interface and the consumer of the API was using the specific implementation of the API, if at all there has to be a new feature to be accommodated and the new feature is implemented in the same method for which there are already consumers would break those consumers.
In such cases if the consumers were bound to the interface then we could provide the old consumers an instance of old Impl and the new consumers with an instance of new Impl there by not breaking the old consumers as well as implementing the new feature. There's a related OO Design principle called: open closed principle which states that classes must be closed for modification but open for extension.
But its not always the case that you may need the consumers of the API to depend on the interface, for example you are sure that this implementation is not going to change then you can safely provide the only implementation in the form of a concrete class. (but you really cant be sure of anything in software development). So you pick the design choice based on the current requirements, but you always need to give scope for the future refactoring that can happen.
Of course I guess you will not answer me saying it’s done because of IoC principal because we anyway if ...
Mohamed Sanaulla wrote:what is IoC? I dont know if its l (L) or I (i) .
Inversion of Control. Also known as Dependency Injection.
I can think of one good reason: testing. Say you're using a given interface: while it may be true that there is only one implementation that will be used in the code (and in some cases it may be obvious that there's never going to be another implementation) it's still highly likely that a complete set of unit tests is going to want to test components that depend on that interface in isolation of the implementation. Which means you're going to want to mock up that interface. Hey presto, you've now got a second implementation.
Yeah, pretty much, I'd say. There may be some subtle differences - my previous post was a bit strong when it said "also known as..." - dependency injection is one way (the most common way?) of achieving Inversion of Control. But they're all related.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Why One to one mapping for one interface and one class in project.is it not wrong pattern to follow?