When to code to interfaces? In my opinion only when you have to “INTERFACE” with a 3rd party component, or some external piece you might have to interact with. Writing an interface for every concrete class seems way to redundant. It is probably easier to convert a concrete class to an interface when you need to instead of coding and Interface and Class or every entity object you want to created. What you end up doing is just duplicating code that you will never use.
Oh yeah, your UML (who even uses UML?) will look good, but its usefulness is lacking. I say write interfaces for things like File System interaction, Database interaction, some other 3rd party or external thing you need to interact with. Then you can easily swap out the backend later
if you need to.
I just don’t get writing say, and IPerson interface for a Person object. They are just going to be exactly the same. Down the road I don’t see you swapping it out for a new “Person”. Maybe but at that point, you might as well just create your IPerson and then create your APerson, BPerson that use the IPerson interface.
I guess what I am saying is follow YAGNI (You aren’t gonna need it) principle, and you will see the benefits in your code.
Steve Novoselac's Blog 
5 replies on “When To Code To an Interface”
In my opinion coding against interfaces helps to enforce a key OOP’s principle ‘coding against abstractions rather than implementation’ . This gives us the freedom to swap components at run time, also from a testability perspective , many frameworks like NMock ,RhinoMock ,etc which use DI to mock your calls require you to code against interfaces rather than implementations.
LikeLike
right but how often to you need to mock your person class?
LikeLike
Too much of a good thing is bad. 😉 But I do agree that many concepts which could be abstracted eventually end up being so, and interfaces are the way to go. My general rule of thumb is: if I need to use it polymorphically, it’s usually done via an interface. If I can see a case where I’ll want to use it polymorphically in the future, I’ll use an interface. Otherwise, just use a straight-up class. Honestly, the refactoring to turn something into an interface when following this rule is so trivial that it really doesn’t hurt.
LikeLike
You are partly correct saying that there are times when a concrete class will suffice and you’ll never need a different implementation of it, But your example is wrong. a Person is a an entity abstraction, where the importance of it being its properties rather than interacting methods. There’s really no need to interface your model domain, as changing it will not require changing other layers of the system.
The paradigm of coding to interfaces rather than to classes is more relevant to a service layer or persistency and not to models.
When you’re coding services, you’re almost always predefining a “contract” which other components shall respect and interact upon. With this in mind, it’s actually a must to code to interfaces in order to gain the benefits of loosely coupled components (and of course “extras” such as IoC, strategy and other patterns, etc.)
It’s actually pretty easy to see which components should be “interfaced” and which should not by drawing a UML component diagram (where interfaces components actually take a large part)
LikeLike
Actually, semantically what a person “is” could be vague enough for some businesses, like healthcare, to warrant to use of interfaces.
LikeLike