Should every Java domain class implement an interface?

开发者_JAVA技巧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?

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.

A good rule of thumb: Don't introduce abstraction for abstraction's sake. Only do it if it enables your project somehow. If it makes your unit testing easier, or it makes upgrades easier, or enables dependency injection etc. Don't make your project any more complicated that is useful.

For domain objects, if they are POJOs then there really isn't any benefit to making interfaces out of them. If they are not POJOs then I would argue that they might not actually be domain objects... but I guess that is a different argument.

I think they wanted to show off with complexity. You should only have an interface if you have several implementaions or to indicate that it would be an extension point.

Using interfaces allow you to have multiple, independent implementations of the same functionality, which in turn allows you to put away implementation details.

You might have public classes in your implementation that you could be tempted to use if you directly referred to the classes. By using the interface and only that, you are guaranteed that the calling code does not trespas on what it is allowed to do.

You can do all kinds of advanced tricks when dealing with an interface. Need to add debugging. Write a wrapper that for each method does the logging and then calls the wrapped instance.

The list goes on and on. Code to interfaces. your code will be better for it.

No. If you say that an interface was created for every domain, then what is the point? Interfaces are only actually useful in grouping several classes together and representing common behavior.

Abstraction is sometimes overrated and can be easily overdone.