This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Programming to Interfaces rather than concrete implementations is a good design practice.
While developing an application we will divide the whole system into sub-systems and one sub-system will talk to other sub-system to complete the whole task.
Each sub-system is separated in such-way that it should be responsible for certain kind of tasks.
So when you design the architecture of a system, first we need to divide the whole system into several sub-systems and we need to clearly define the responsibilities of each sub-system without bothering about how to implement those responsibilities. In this way we develop a prototype/blueprint of our system to be developed.
Once we have a prototype, then we need to turn these design into coding. To do this we need to use Interfaces rather than classes as we don't know the actual implementations.
And also this approach will expose the contract between the sub-systems on how to interact with each other.
Later based on the technology we chose we can provide the concrete implementations for the interfaces without affecting the design of our system.
For example, Once we have an interface with all the operation to be performed on Customer, we can choose JDBC/Hibernate/IBatis to implement the actual behavior.
Later if we want to change the Persistent handler to JPA we can change without affecting the caller code.
I am very consfused about the term "Program to an interface, not an implementation" in java.
Could you please elaborate and explain me detail
By Programing to Interfaces your application/code is always open for modification without much code change. In Software Development process more time is spent on maintaining the code rather than its development and during this period there may be requirement of new classes.
Like if you coded to concrete classes then your code will look something like this
But if you program to Interfaces then it can be made generic
Now if there is any new addition of any foodItem/Beverages then its a lot easier for you to process it as the method processFood(FoodItem foodItem) takes an implementation of FoodItem. On the other hand if you have programmed to concrete classes like the code given at first then you have to write new method for every food type.
Hope it makes clear that why programming to interfaces is more useful as compared to program to concrete classes.
think of a hardware analogy (probably not a perfect one, but close enough).
would you rather have every MP3 player on the market all connect to your computer via a proprietary hardware jack or a standard USB type connector?
think about it...if you had to re-configure your pc when you change from a iPod to a Zune (just go with it), you'd think a long time before making any change. Even upgrading from a iPod Nano to an iPod Touch would require hardware reconfiguration.
OR...everything uses a USB. you can swap out MP3 players all day long, and you never have to touch your PC's hardware configuration.
think of 'programming to an interface' as a USB, and 'programming to an implementation' as a proprietary jack.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors