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 have seen many spring projects but I have noticed one thing common that is 'coding to interface'. I don't know why people are using interface. Please tell me why this is require and what is the benefit. please explain me what are the problem if we are not use 'coding to interface' and how interface overcome this problem.
I think the 'code to an interface not an implementation' first really gained traction in the extremely popular GOF book on design patterns if I am not mistaken. There are lots of good reasons for it, however this is more of a design discussion than a Spring one, so I am going to add this to our Patterns forum as well.
Are you familiar with the GOF patterns? Understanding them will help you understand the benefits, as many pattern depend on this abstraction.
Yes I read it 3 times, I not understood this point :
An interface distills the collaboration between objects. An interface is free from implementation details, and it defines the vocabulary of the collaboration. Once I understand the interfaces, I understand most of the system. Why? Because once I understand all the interfaces, I should be able to understand the vocabulary of the problem.
If we have good formatting then we can understand all the vocabulary. WHY WE GIVES LOAD TO OUR SERVER BY CREATING INTERFACE.
Please explain me with example
PLEASE, PLEASE, PLEASE help me I am very confuse. This topic is very important for me.
The only "load" I can imagine interfaces having on the runtime system is in loading its .class file. This, as Jeanne says, is hardly significant. Do not concern yourself too much with performance up front. Well-factored code is usually easier to performance tune anyway so you should worry about creating a well-factored, coherent design first.
Coding to an interface is actually more aligned with the "L", the Liskov Substitution Principle, than the Interface Segregation Principle. Coding to an interface helps make the code more flexible and abstract in that it is not coupled to a particular implementation but rather to the contract that the interface defines. You should be able to substitute one implemention for another without affecting the validity of your code.
The ISP has to do with having small and cohesive APIs rather than large, all-encompassing ones.
Coding to an interface is also an absolute must to achieve proper modularization, by cleanly separating the exposed public API from its implementation details. For instance, in an OSGi environment it's common practice to use separate bundles for each, and us declarative services to provide an implementation at runtime.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.