One interface to rule them all

Software nerd rant here... skip if this isn't you.

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.