addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrosseditemptyheartexportfacebookfolderfullheartglobegmailgoogleimageimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

RE: [dotnet-120] Programming to an Interface (or not?)

From: Mark P.
Sent on: Tuesday, October 6, 2009 12:54 PM

Generally agree.  The domain model isn’t has heavily interface based as a service or data access layer where you want alternative implementations for testing and/or to allow interception.  Still, the good old strategy interface, for example to support a family of different calculation, uses interfaces and is valid in building up your domain model.  Generally speaking, interfaces with nouns, (IPerson) feels like a code smell….


From: [address removed] [mailto:[address removed]] On Behalf Of Steve Bohlen
Sent: Tuesday, October 06,[masked]:23 PM
To: [address removed]
Subject: Re: [dotnet-120] Programming to an Interface (or not?)


One of the intents of the Interface abstraction is to provide for multiple implementations of the interface in your code base.  If you aren't going to have more than one implementation, then under this guide its probably a waste of time to introduce an abstraction layer designed to support something you're not going to do.

Note, of course, that having a second implementation for TESTING does of course count as a need for a second implementation :)

The other reason for the interface is to separate the declaration of your contract from even its SINGLE implementation (typically for isolation/decoupling reasons).  The canonical example is probably coding to the IRepository -style interface in your application and then developing the implementation of that interface in a completely different project/solution/whatever and using the common interface-defining assembly as the only point of 'common contact' (dependency) between the projects.

I wouldn't personally use 'just-a-bunch-of-properties' vs. 'has-methods' as the discriminator for whether something needs (or not!) an interface refactored out of it (thought I do concede that frequently those things with just properties don't have multiple implementations and those with methods more often do).

I would also suggest being very careful about casually lumping the term 'domain models' in with 'plain old data objects' since in many corners of the software development world these are not only different things but also diametrically-opposed concepts :)

In the case of an actual domain model (in the DDD sense) I think its hard to suggest you would ever need an interface for such things as much of the point of the process of refining your domain model in close collaboration with the business stakeholders is so that this *one* domain model represents and aggregates the software development team's comprehension of the business rules, constraints, behaviors, etc. needed to drive the function of your software.  In such a context, I think if you start to be able to imagine 'alternate implementations' of the domain model (by coding to interfaces your models then implement) it probably points out that there's insufficient clarity in your present understanding of the problem domain to be modeling it properly in code.

In the case of DTOs-as-Domain-Model (a sadly common anti-pattern in domain modeling but an approach with two feet firmly planted in the world of database-driven-software modeling), I think it also unlikely that there's value in coding to an interface for these.  Sort of 'by definition' their shape ('public surface area' that even *could* be defined in an interface) is driven by you data-modeling needs rather than your application behavior needs and so there's similarly little value in the interface abstraction permitting you to substitute alternate implementations of them.

The last thought is this: with any reasonably-modern refactoring tools at your disposal, swapping out signatures and dependencies to introduce an interface later as you discover you *really* need it is usually pretty straightforward so there's a big part of YAGNI being violated by up-front 'interface explosion' for things you only *think* you're really going to need.

Just my two cents; hope this helps (and YMMV of course).

Steve Bohlen
[address removed]

On Tue, Oct 6, 2009 at 9:39 AM, Noah Blumenthal <[address removed]> wrote:

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?

Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Noah Blumenthal ([address removed]) from New York .NET Meetup Group.
To learn more about Noah Blumenthal, visit his/her member profile:
To unsubscribe or to update your mailing list settings, click here:
Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA

Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Steve Bohlen ([address removed]) from New York .NET Meetup Group.
To learn more about Steve Bohlen, visit his/her member profile
To unsubscribe or to update your mailing list settings, click here

Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA

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