Is there any reason to have interfaces for very basic data objects?

Question

In writing my current project, I have created interfaces for all of my objects. I thought that this was considered good coding practice.

I've basically ended up with a bunch of interfaces which define pretty trivial classes.

Eg:

public interface IUser
{
    int Id { get; }
    string DisplayName { get; }
}

I don't really see any point to having these here. I've additionaly now run into problems in a couple of places where I want to do things like define operator overloads, which I can't do at the interface level.

I'm tempted to go through my project and remove all these interfaces (I would keep interfaces for my repositories and other such things which define more complex behaviour), but I'd be a bit gutted to be going through deleting 100s of lines of code and all the refactoring that will go with it.

I'd like to hear opinions of other users here. Is there any purpose to defining interfaces on basic objects? Is there any harm in having them there, even if they aren't really necessary?

Answer 1

Interfaces imply different implementations to me. If your model objects won't change behavior, or ever be proxied, or if they're immutable, or if they're nothing more than DTOs, then I wouldn't see the reason for an interface.

Answer 2

If the interfaces aren't adding value, then remove them. When it comes to interfaces on entities unless they share a common ground, I don't see value added in putting them behind an interface.

If they do share common ground this will allow for you to use generic algorithms for processing them.

I commonly see "entities" extend base classes that contain audit information.

interface IAuditBase{
    int Id { get; }
    string UpdateDate{ get; }
    //etc.
}

Answer 3

The main point of an Interface is to provide a "contract" to which a class will adhere. This really only becomes important if multiple classes will need to adhere to the same contract or if some class need only access to the Interface members and doesn't care about the class implementation.

If you're not going to have those scenarios, then feel free to leave out some interfaces.

On the other hand, having defined the interface already, I think any additional overhead would be so minimal (if it exists at all) that to remove it now would be premature micro-optimization.

Answer 4

I wouldn't use them if you can't define why you are using them. Interfaces are great when you have a very standardized way of interacting with a collection of similar objects and need them to all 'interface' the exact same way.

I have found that if my 'interface' is changing a lot, interfaces are a bad idea, I only use them when I know the standard isn't likely to change much and the interface is well understood and makes sense.

If you can't explain why you're using interfaces, I would have to recommend against using them, no need to over-complicate things if there's no benefit to doing so.

You mentioned IUser interface, so do you have a bunch of difference implementations of a User object that all share a similar interface, similar methods and behavior etc? An interface might make sense but if you only have on User class, then there's no real reason to be using an interface.

Answer 5

Interface should be only treated as an contracts most of the times. Entities like you have defined should be treated as Class (As an Object would be created from it).

Interfaces provide a kind of Flexibility in Implementation.

There are several other reasons why you might want to use interfaces instead of class inheritance:

Interfaces are better suited to situations in which your applications require many possibly unrelated object types to provide certain functionality.

Interfaces are more flexible than base classes because you can define a single implementation that can implement multiple interfaces.

Interfaces are better in situations in which you do not need to inherit implementation from a base class.

Interfaces are useful in cases where you cannot use class inheritance. For example, structures cannot inherit from classes, but they can implement interfaces.

Answer 6

Personally, I think DTOs should very rarely have intefaces. It's much more likely that the DTO will stay static and what will be "interfaced" will be the code from which the DTO is acquired/persisted.

Answer 7

This one of the reasons why I like a TDD (or similar approach). You won't get Interfaces until the Refactoring step tells you need them.