Clean Code: A Handbook of Agile Software Craftsmanship - Interfaces

[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?

[Alaa Nassef]

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

Set mySet = new HashSet();

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.

[Ilja Preuss]

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.

[Robert Martin]

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. ;-)