Jeff and .NET

The .NET musings of Jeff Putz

Sponsors

News

My Sites

Archives

One interface to rule them all

I'm not shy about telling people that I'm not much of a computer science kind of guy. It's not that I don't respect computer science or understand it, I'm just not one to get academic over it to the point of not building anything. And while I can't always remember what the hell SOLID stands for, I do remember that the "I" stands for the "interface segregation principle." It says, "Thou shalt not force everything to use one interface, because specific interfaces are better."

I've seen this principle violated many times, but twice in the last six months I've seen projects that just abuse it to death. The big problem for me is that trying to force everything into a particular interface leads to pain and suffering whenever you want to change something. While developers are in the general sense understanding what dependency injection is, I find that they're often doing it a way that violates the interface segregation principle.

For example, I've seen several instances where people are passing in the dependency resolver itself (for MVC, this is one of the IDependencyResolver interfaces) to various classes, and then those classes new up instances of whatever they need. This is bad for two reasons. For one, you're then coding on One Interface to rule them all, and for another, the overhead of mocking and verifying in testing gets bigger. That's no fun.

Another anti-pattern, related to the ISP, is the master do-it-all abstract class. These drive me nuts, too. While an abstract class isn't exactly an interface per se, it ends up being used as one. In an effort to keep the interface concise (as if it's easy to change when it's used in a thousand places), it ends up having one or two methods in order to conform to the base type. This is suboptimal because it keeps you from grouping similar functionality together, it abuses generics (which are fun when you have to bounce between value and reference types), and more to the point, that single interface isn't single for any really good reason. I would rather see you inject whatever functionality you need by way of a specific interface than force One Interface.

Think about it in terms of the mature frameworks that you've used. There aren't a lot of interfaces to be had that are widely used, because they would be hard to change, and force-feed members that don't need to be widely used. When there are widely used interfaces, they're pretty sparse (think IDisposable).

Specific is better. Don't try to cure cancer with an interface.

Comments

Mr Programmer said:

Totally agreed, I do have a Comp Sci degree and some developers just like to use interfaces and abstractions for the sake of looking like they understand design patterns and OOP.

# April 20, 2013 3:17 AM

Steven said:

The last couple of years I found out that systems benefit greatly from having a few well defined generic interfaces that define a srt of closely related classes in the system. For instance an ICommandHandler<TCommand> for use cases, an IRepository<TEntity> as abstraction over the DAL and an IQueryHandler<TQuery, TResult> abstraction over queries in the system.

# April 20, 2013 4:44 AM

Jeff said:

I tend to disagree in the case of data repos and querying mechanisms. A common interface rarely helps you out here, because a) you're never swapping the concrete implementations for each other, and b) there isn't any real advantage for testing either. What I see is a lot of extraneous methods that never get used.

# April 21, 2013 11:23 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)