Does the code-to-interface principle apply to entity classes?

Question

I'm trying to follow code-to-interface on a project. Should I be creating an interface first then implementing that interface for entity classes? I'm thinking this might be taking the interface first approach too far and entities should be ignored. This is what I mean...

public interface Address {
  public String getStreet();
  public void setStreet(String street);
}

@Entity
public class AddressImpl implements Address {
  private String street;

  public String getStreet(){
    return this.street;
  }
  public void setStreet(String street){
    this.street = street;
  }
}

@Entity
public class OfficeImpl /* implements Office */ {
  private Address location;

  public Address getLocation(){
    return this.location;
  }
  public void setLocation(Address location){
    this.location = location;
  }
}

public class Driver {
  public static void main(String[] args) {
    Office work = new OfficeImpl();
    Address workAddress = new AddressImpl();
    workAddress.setStreet("Main St.");
    work.setLocation(workAddress);
  }
}

Answer 1

I think creating Interfaces for Entities is probably not necessary.

The purpose of creating Interfaces (or at least, one of the purposes) is to make it easier to swap out one concrete implementation in favour of another. This is obviously a good thing for your DAOs, Business Logic etc.

But unless you have plans for the implementation of your entities to change as well, I would avoid it!

Answer 2

In your example, you are probably taking it too far, but once you add methods, write test cases and possibly use dependency injection, it will make more sense.

For simple projects like this, it is overkill, but once you get into a 'real' application, then it is often a good idea. Just be careful not to overdo it, everything doesn't need to implement an interface, just where it makes sense.

Answer 3

I think when you're talking about entities, it's probably overkill.

Interfaces are useful when you're working with entities that have a common usage, but aren't necessarily the same. Can't think of a good way to explain it, but here's an example:

interface IFlaggable {
  bool IsFlagged ...
  string Reason ...
}

class ForumPost implements IFlaggable { }

class PrivateMessage implements IFlaggable { }

Hope that helps!

Answer 4

I generally don't make interfaces for data holding beans, that is I don't make interfaces for classes with primitive type values and getters/setters for them. Haven't really ever hit a moment where I would've needed interfaces for anything I usually use them for (polymorphism and mocking, mostly) so I haven't bothered doing that.

I guess I should point out that most of the time when I use databeans I also reflect the values from those same objects with custom classes which work like this:

Reflector r = new Reflector(new DataBean( [ values given through constructor ] ));
long someNumber = r.get("method", Long.class);

Answer 5

the interface for Entities should be the behaviors and properties that are common to all Entities!

public interface IEntity
{
    int EntityId { get; set; }
    bool FindById(int id);
    bool Create(object [] values);
    bool Delete(int id);
    //etc.
}

sorry for the C# example, but the language doesn't matter. Interfaces are for 'plug compatability'.