I am building out my domain model and continuing to refactor it. As I do, I am finding that I like interfaces as it allows me to create reusable methods/controllers/views for concrete types based on their interfaces. However, I am finding that I am creating an interface every time I add a new property to one of my domain entities.
For example, I have a MemberStatus object which inherits from an abstract Entity object which in turn implements the IIdentifiableEntity interface meaning that it has an Id property. MemberStatus also implements the INamedEntity interface meaning that it has a Name property, the IOrderedEntity interface meaning that it has a DisplayOrder property and the IHasMembers interface meaning that it has a collection Member objects. Here's the code:
public class MemberStatus : Entity, INamedEntity, IOrderedEntity, IHasMembers { public string Name { get; set; } public float DisplayOrder { get; set; } public ICollection<Member> Members { get; set; } } public abstract class Entity : IIdentifiableEntity { public int Id { get; set; } } public interface IIdentifiableEntity { int Id { get; set; } } public interface INamedEntity { string Name { get; set; } } public interface IOrderedEntity { float DisplayOrder { get; set; } } public interface IHasMembers { ICollection<Member> Members { get; set; } }
Now, this seems to work fine as I other similar objects such as MemberPosition and MemberTeam which all implement these same interfaces and I can use my repository methods and controller actions with generics that implement these interfaces and have a lot of code reuse.
However, my concern is whether or not it's appropriate to keep adding simple, one-property interfaces every time I add a new property to my concrete objects. For example, let's say I want to add a bool Enabled
property... should I continue to create a IEnabled interface? The reason I'm asking is that some of controller "initializers" that are using generics are becoming very long as shown in the following line of code. Is this normal and best-practice?
public abstract class OrderedCrudController<TEntity> : CrudController<TEntity> where TEntity : Entity, INamedEntity, IOrderedEntity, IHasMembers, new()
One class can implement any number of interfaces, allowing a single class to have multiple behaviors.
Interfaces are overused in a lot of C# code, and in some cases are not merely extra baggage, but are actively the wrong thing to do. These interfaces tend to be created upfront, with the object, in advance of any need of them; and are wide, mirroring all the public parts of the object.
No, every class should not have an interface. It's overkill squared. You use an interface when you need to abstract what's done from how it's done, and you're certain that the implementation can change.
When discussing these principles in the book, I regularly encourage the reader to add more interfaces to their classes, to make the overall design of the package or application more flexible. However, not every class needs an interface, and not every interface makes sense.
The fact that you are using interfaces is a good thing. However, you should ask yourself, if I create an IEnabled
interface, will I ever reference my class by that interface alone? i.e. will there be contexts where I interact with my class purely via the single property that interface exposes?
Also, can you consider contexts where you will interact with multiple implementation of this IEnabled
interface?
If the answer to both of these question is "no", then the interface serves very little purpose.
Having said that, please don't worry too much about this! it does very little harm.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With