Programming to an Interface (or not?)

From: Noah B.
Sent on: Tuesday, October 6, 2009 9:39 AM
We all know that we're supposed to "program to an interface, not an 
implementation".  However, I'm wondering how far this should be taken 
and would love input from everyone here.  Specifically, should domain 
models -- plain old data objects  -- be abstracted? 

We're currently using the Entity Framework for a project and in order to 
"program to an interface", interfaces have been extracted from all 
entities.  Now things have gotten a little out of hand IMHO and we're 
spending as much time keeping interfaces in line with entities as 
expanding the system.

Our specific issue aside, what do people think of this type of 
architecture?  I'm typically of the opinion that if a class doesn't DO 
anything, there's no reason to have an interface (i.e. you need a method 
before getting an interface).  One of the big reasons I  like lots of 
interfaces is for testing and since you can test a data object easily 
(just set it's setters and test its getters or whatever).

What are your thoughts?

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy