20 Aug 03:57
Multiple Interfaces
From: moffdub <moffdub <at> yahoo.com>
Subject: Multiple Interfaces
Newsgroups: gmane.comp.programming.domain-driven-design
Date: 2008-08-20 01:58:19 GMT
Subject: Multiple Interfaces
Newsgroups: gmane.comp.programming.domain-driven-design
Date: 2008-08-20 01:58:19 GMT
I recently had a vision about how to combat the abuse of the
pesky-but-needed getters and setters that are necessary for domain
objects that live in a real system and that have to be stored,
displayed, and sometimes created by external factories.
Anyway, since the getters and setters will end up being there anyway,
alongside your actual business logic methods, would it be better to
have the domain object implement multiple interfaces, one for each
layer of the system that has to see assorted getters and setters?
Here is what I'm talking about:
// for use with other domain objects; exposes meaningful business
logic methods only
public interface Customer
{
// our lone business logic method
void describe(CustomerDescription description);
}
// to be used when displaying a customer in UI and capturing a new one
from the user; TO stands for Transfer Object
public interface CustomerTO
{
String getFullName();
String getAddress();
void setFullName(String name);
void setAddress(String addr);
}
(Continue reading)
And when you post about designing classes without getters and setters to the tool XXX
group, you sound like an alien from outer space.
Probably the answer is around "the whole point is about being DOMAIN DRIVEN not TOOL/FRAMEWORK DRIVEN". On
the other hand, at least for some types of applications or cases, the amount and complexity of code around
the domain model is large enough so that it can not be ignored. The cost for developing and maintaining that
piece of code is comparable to cost of the domain model. It is hard to justify a decision that would really
increase this non-domain cost. At the end, DDD is also about lowering the cost of development and maintenance.
Yet, all of the above is speculation not based on any actual measurement. I believe factors like the number
and needs of the clients that will consume the domain model, is important in this decision. If the only
impurity in the model is the use of getters and setters in the model, the ease of developing and maintaining
non-domain code might justify that, at least in some cases. Of course there are problems, with getters and
setters and the biggest is probably that there are more questions than answers. Second to that, some
problems come out to be deeper than one imagines and can not be solved with a few nice ideas.
--- On Wed, 8/20/08, Greg Young <gregoryyoung1 <at> gmail.com> wrote:
> From: Greg Young <gregoryyoung1 <at> gmail.com>
> Subject: Re: [domaindrivendesign] Multiple Interfaces
> To: domaindrivendesign <at> yahoogroups.com
> Date: Wednesday, August 20, 2008, 5:05 AM
> I think a better route of discussion might be "Do they
> actually need
> to be there?"
RSS Feed