Should Model Objects Have Interfaces?

Question

I am creating the domain model in my system. When designing my model objects, should I make interfaces for each entity object? People have told me that our web tier should not care about the implementation of an entity and we should be able to swap out implementations, but I'm not sure that would ever happen.

For example, if we have a Teacher class that maintains a List of Students, the getStudents method could either be:

public List<Student> getStudents() {
      return this.students;
}

or this:

public List<Student> getStudents() { 
     return someExternalService.retrieveStudents();
}

I understand this benefit, but what is the general practice?

Answer 1

Unless you have good reason to think you will need to swap-out the model I wouldn't worry about it yet. Based on the YAGNI principle (You ain't gonna need it)

Answer 2

None of the projects I've ever seen or participated in had interfaces for domain entities.

But in one of my projects I had interface NamedEntity:

public interface NamedEntity {
   int getId ();
   String getName ();
}

All domain entities implemented this interface. It gave me a possibility not to create different jsf converters for different entities but create one converter which used this interface instead of concrete domain classes.

Answer 3

I can't speak to general practice, but it is hardly just about hiding the implementation.

It's about formalizing the interface as the basis for documentation and contracts.

In abstracting your models out into interfaces, you are creating documentation for service client developers. Depending on your development style, you may or may not already have a formal description of your service (e.g., a WSDL-based description). Interfaces can fill that need.

Answer 4

I think there is an important difference between having interface for service to retrieve the object and the model object itself.

At runtime the service to load a model object can differ based on from where you are requesting the data. But the format and type of data object expected does not change, no matter how you create this object. Therefore model objects which carry the state would not need an interface, but service classes to create and load these model objects needs the interface.

The only reason for model objects to have interfaces would make sense if model object is not just a simple bean type of object but object which exposes some kind of behavior as well.

Answer 5

My general view is that I would not create a one-to-one set of interfaces for the domain models, since this does nothing other than duplicate your domain model's class structure. It doesn't add anything useful.

The two cases I can think of immediately where I would consider introducing interfaces is:

1. an interface describes the contract/behaviour of some set of classes in the domain model, where it is useful to model that behaviour independantly of the classes which implement it
2. you need to expose your domain model to external clients and want to hide implementation details from them

In other words, add interfaces if they help you describe behaviour or help you hide implementation details from clients. Other reasons might be valid, but those are two that come to mind.

Answer 6

Extracting an interface is one of the simplest refactorings; worst case it is a class re-name -> move method. The effort to change your mind, once you've found a reason to do so, is minimal. I have always found that if a decision is easy to change, it reinforces YAGNI and KISS even more. The counter-argument is that it is not much effort to create an interface initially, which is true, but the maintenance adds up over time if the decision is made many times over - often not being used.