Interfaces: Consolidate, Partition or Combine?
time to read 3 min | 480 words

(Just to note, I am working on more than one project at any given time, so if you wonder why I am jumping between topics, it is because I am drawing from several very different projects, with different goals and technologies.)

I have a project where most (all?) of my entities implements several common interfaces:

  • IHaveNameAndId
  • IHaveHistory - I think that I will have to hate that one. Think about chained histories, and then try to debug that.
  • ISecurable
  • IVersionable

My classes are defined as:

public class Employee : IHaveNameAndId, IHaveHistory, ISecurable, IVersionable { ... }

It is likely that I will find more common stuff in the future that all the classes needs to implement. I am not sure if this is a good style. I can see several options in front of me:

  • Keep the existing interfaces, they state intent clearly, and they allow easy partioning of functionality (I can be versioned without having history, for instnace).
  • Consolidate the existing interfaces to one or two interfaces: IEntity, IEntityWithHistory, etc.
  • Combine interfaces to create a common interface:
    public interface IEntity : ISecurable, IHaveNameAndId {}

I like the ability to say something like:

public bool IsAllowed(ISecurable securable) 

I think that this is far less clear:

public bool IsAllowed(IEntity entity)

The second one may very well be, is allowed to move to another state by the business rules, for instnace. The first one make it very clear that it is the security that we are checking.

Any thoughts?

Tweet Share Share 0 comments
Tags: