aspose file tools*
The moose likes Agile and Other Processes and the fly likes Clean Code: A Handbook of Agile Software Craftsmanship - Interfaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Clean Code: A Handbook of Agile Software Craftsmanship - Interfaces" Watch "Clean Code: A Handbook of Agile Software Craftsmanship - Interfaces" New topic
Author

Clean Code: A Handbook of Agile Software Craftsmanship - Interfaces

Tomasz Prus
Ranch Hand

Joined: May 20, 2008
Posts: 73
I heard from someone such advise to use everywhere interfaces where it is possible. Is it good to extract always interfaces or should i do it just when i need it?
Alaa Nassef
Ranch Hand

Joined: Jan 28, 2008
Posts: 460
This is one of the basic design principles "Code to interfaces and not to concrete classes". I'm sure that you do that all the time, with things as simple as for example. This is typically important with multi-tiered applications, with the extension/integration points of your application, and sometimes with things that you need to generalize or have several implementations for it. Coding to interfaces reduces the coupling between your concrete classes (and more importantly to the layers).

Imagine that you coupled your service layer with a hibernate data access layer, if your architect/technical lead decided for some reason or the other that you're going to re-implement the data access layer using iBatis, JPA or even JDBC. If you're not coding to interfaces, you'll be changing code in the service layer as well as creating the new implementation. Just imagine the number of bugs that could be produced in the already tested and stable service layer. If you are using interfaces and a factory to decide which implementation to use (or better off, dependency injection via spring, seam or EJB3), you won't face such problems.

Of course you'll not be doing that with EVERYTHING. Creating interfaces to domain objects, wrapper classes and utility classes is absurd.


Visit my blog: http://jnassef.blogspot.com/
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
In my opinion, it depends.

For code that you publish, for example if you provide an API for third party developers, interfaces are a vital part to keep your API flexible for future extensions.

On the other hand, for code that is totally under your control and only used internally in your own systems, today's refactoring tools are powerful enough that introducing an interface for a class later on is so cheap that introducing it before you actually need it just doesn't make sense.

On the third hand , when you unit test your code, for example using JUnit, you will need to introduce interfaces anyway, to make your units reasonably testable. With other words, good unit testing practice already leads to reasonably decoupled systems in general, because to test a unit in isolation, it needs to be well decoupled from other units.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Robert Martin
Author
Ranch Hand

Joined: Jul 02, 2003
Posts: 76
Originally posted by Tomasz Prus:
I heard from someone such advise to use everywhere interfaces where it is possible. Is it good to extract always interfaces or should i do it just when i need it?


You should only do it when you need to. Of course if you follow the disciplines of Test Driven Development, you'll need to all the time. ;-)


---<br />Uncle Bob.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Clean Code: A Handbook of Agile Software Craftsmanship - Interfaces