Should every Java domain class implement an interface?

I've been looking over another Java project done at my company and in this project the developers created an interface for pretty much ever domain entity (there are hundreds). In some cases, I think the abstraction works, but in other cases it doesn't seem like it is need at this time.

Whenever instances are passed around they are always referred and access via the interface.

Is this bloat from too much future proofing? or is this sound engineering practice?

Answers


Interfaces specify required behavior without implementation. They allow you to swap implementations without affecting clients. They can be especially useful for techniques like aspect-oriented programming or proxy generation.

But if implementation doesn't change, I see no justification for an interface.

Most model objects fall into that category. If there's no implementation differences, don't use an interface.

Interfaces are terrific for services and persistence classes, but I have never seen them used to abstract model objects.


Primarily interfaces are obviously a design tool to unite disparate classes with common traits.

But then interfaces like the ones mentioned can also help a lot when writing unit tests. Tools like easymock works really well with interfaces.

Personally I like having interfaces for services, but not necessarily domain objects, depending a bit on how "rich" the domain objects are. If they, for instance, do a lot of filesystem stuff or have really close ties to the services/dao layer, I will probably make interfaces there too - to make easier unit tests.


Need Your Help

Checking out a git branch while in a path that exists only in the initial branch

git

Can anyone help me make sense of this quirk I've found with git?

<vector> is messing up my Quicksort

c++ vector quicksort

I have to implement quicksort in C++. I wanted to use std::vector for my quicksort algorithm because I'm going to be reading in a load of numbers from a text file and the dynamic sizing would be us...