moffdub | 20 Aug 03:57
Favicon

Multiple Interfaces

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)

Greg Young | 20 Aug 04:05
Gravatar

Re: Multiple Interfaces

I think a better route of discussion might be "Do they actually need
to be there?"

Cheers,

Greg

On Tue, Aug 19, 2008 at 6:58 PM, moffdub <moffdub <at> yahoo.com> wrote:
> 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
(Continue reading)

Ertugrul Uysal | 20 Aug 09:31
Favicon

Re: Multiple Interfaces

Yes, I think this is one point that needs discussion. 
I believe it is not that hard to observe the problems introduced by getters and setters, while modeling with DDD.
However, the reason for having getters and setters in domain classes is not related to the domain or having a
"better" the model. Either the tools used for non-domain related purposes like user interface, ORM, web
services tools, work much better with such classes. I believe it is not possible to discuss the topic
without asking questions like "how would you accomplish this scenario without getters and setters on
classes using tool/framework XXX?". At this point the discussion goes beyond the "ANTI-CORRUPTION
LAYER" around DDD :-) 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?"
(Continue reading)

moffdub | 20 Aug 12:33
Favicon

Re: Multiple Interfaces

That is indeed a fascinating and controversial discussion that I have
participated in before. For the purpose of this thread, let's assume
that such methods are a necessary evil that must be isolated as much
as possible.

--- In domaindrivendesign <at> yahoogroups.com, "Greg Young"
<gregoryyoung1@...> wrote:
>
> I think a better route of discussion might be "Do they actually need
> to be there?"
> 
> Cheers,
> 
> Greg
> 

------------------------------------

Greg Young | 20 Aug 19:12
Gravatar

Re: Re: Multiple Interfaces

I will start a separate thread (likely with a blog post) as I find
them completely unnecessary. They should be seen as an architectural
smell.

Cheers,

Greg

On Wed, Aug 20, 2008 at 3:33 AM, moffdub <moffdub <at> yahoo.com> wrote:
> That is indeed a fascinating and controversial discussion that I have
> participated in before. For the purpose of this thread, let's assume
> that such methods are a necessary evil that must be isolated as much
> as possible.
>
> --- In domaindrivendesign <at> yahoogroups.com, "Greg Young"
>
> <gregoryyoung1@...> wrote:
>>
>> I think a better route of discussion might be "Do they actually need
>> to be there?"
>>
>> Cheers,
>>
>> Greg
>>
>
> 

--

-- 
It is the mark of an educated mind to be able to entertain a thought
(Continue reading)

moffdub | 20 Aug 19:20
Favicon

Re: Multiple Interfaces

I look forward to reading about a solution that doesn't introduce its 
own smell.

______
The views expressed here are mine and do not reflect the official 
opinion of my employer or the organization through which the Internet 
was accessed.

--- In domaindrivendesign <at> yahoogroups.com, "Greg Young" 
<gregoryyoung1@...> wrote:
>
> I will start a separate thread (likely with a blog post) as I find
> them completely unnecessary. They should be seen as an architectural
> smell.
> 
> Cheers,
> 
> Greg
> 

------------------------------------

Rickard Öberg | 20 Aug 04:17

Re: Multiple Interfaces

moffdub wrote:
> 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?
<snip>

Here's how you can do it with Qi4j: properties are first class objects 
defined by methods in interfaces like this:
interface Foo
{
   Property<String> name();
}

A mixin in a Composite(=composed object) can cast itself to any of the 
types the Composite implements like this:
public Bar class BarMixin
   implements Bar
{
   @This Foo meAsFoo;

   public void doStuff()
   {
     meAsFoo.name().get();
   }
(Continue reading)

moffdub | 20 Aug 12:48
Favicon

Re: Multiple Interfaces

I have considered using the Visitor pattern for this problem, but in
languages like Java and C#, I have run into the problem of still
needing accessors so the visitor can extract the data and perform the
"visit". Are you suggesting that I should use the
package/internal/friend access modifier for those accessors and have
the visitor live in the same package/assembly as the domain object?

--- In domaindrivendesign <at> yahoogroups.com, Rickard Öberg
<rickardoberg@...> wrote:
>
> moffdub wrote:
> > 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?
> <snip>
> 
> Here's how you can do it with Qi4j: properties are first class objects 
> defined by methods in interfaces like this:
> interface Foo
> {
>    Property<String> name();
> }
> 
> A mixin in a Composite(=composed object) can cast itself to any of the 
(Continue reading)

Rickard Öberg | 20 Aug 12:55

Re: Re: Multiple Interfaces

moffdub wrote:
> 
> 
> I have considered using the Visitor pattern for this problem, but in
> languages like Java and C#, I have run into the problem of still
> needing accessors so the visitor can extract the data and perform the
> "visit". Are you suggesting that I should use the
> package/internal/friend access modifier for those accessors and have
> the visitor live in the same package/assembly as the domain object?

No, that's the other way round. What I'm suggesting is that the object 
itself is the visitor. I.e. if you have a form that needs populating 
with fields from an object, add "visitForm(Form)" to the object. The 
state is then internal to the object and the visitForm() method does all 
the mapping from state to form fields. Maybe "visitForm" is a bad name 
though; something like "populateForm" might be better.

/Rickard

------------------------------------

jasonmeckley | 20 Aug 14:09
Gravatar

Re: Multiple Interfaces

a domain object containing multiple interfaces isn't bad design in
itself. (Udi Dahan http://www.udidahan.com/) discusses Adaptive Domain
Models alot.
Example:
class JasonMeckley : IPerson, IMale, IHusband, IFather, IProgrammer
{
}
I have an object which has a single responsibility. Expressing myself.
I express myself in different contexts through different interface.

If I were to also implement IPersonTO or IPersonDO on the JasonMeckley
object I would now have multiple responsibilities.
1. express JasonMeckley
2. map JasonMeckley to a DTO
3. persist JasonMeckley to storage
This would break Single Responsibility and not adhere to Seperation of
Concerns.

So in the example listed above. I would opt for a unique object for
each interface.  However the Customer object could implement multiple
interfaces to express the domain.
Example:
class Customer: IPerson, IBusiness, IClient
{
}

--- In domaindrivendesign <at> yahoogroups.com, Rickard Öberg
<rickardoberg@...> wrote:
>
> moffdub wrote:
(Continue reading)

moffdub | 20 Aug 14:22
Favicon

Re: Multiple Interfaces

The TO and DO interfaces aren't meant to do anything except expose 
the domain object's state. I'm not suggesting that their 
implementations call a repository or UI.

I do see your point. However, short of either 

1) using a visitor-ish pattern discussed elsewhere in this thread, or 

2) making instance members package-private/friend/internal instead of 
private and putting your TO-Domain Object and DO-Domain Object 
mappers in the same scope as your domain model (which I'd argue is 
not the way to go), 

how would you avoid some form of accessor to convert between the 
unique objects for each?

______
The views expressed here are mine and do not reflect the official 
opinion of my employer or the organization through which the Internet 
was accessed.

--- In domaindrivendesign <at> yahoogroups.com, "jasonmeckley" 
<jasonmeckley@...> wrote:
>
> a domain object containing multiple interfaces isn't bad design in
> itself. (Udi Dahan http://www.udidahan.com/) discusses Adaptive 
Domain
> Models alot.
> Example:
> class JasonMeckley : IPerson, IMale, IHusband, IFather, IProgrammer
(Continue reading)

jasonmeckley | 20 Aug 14:48
Gravatar

Re: Multiple Interfaces

> how would you avoid some form of accessor to convert between the 
> unique objects for each?

I wouldn't. each interface has it's own set of members. using the
example of the JasonMeckley object above. I would never reference
JasonMeckley directly in code. I would access it through an interface.

IProgrammer programmer = Repository<IProgrammer>.Get(id);
programmer.ProgramIn(c#);
programmer.Use(VisualSutdio);
...

the Repository pulls the JasonMeckley object but for this context I
don't care.  i don't care if JasonMeckely inherits multiple
interfaces. I don't care if it has 20 public members. all I care about
, in this context, is I want a programmer with an id of X. I want to
set the programming language to c# and use VS. in this context nothing
else matters.

not sure if this answers your question or not.

If I need to map, say a programmer to SomeDTO. i would have a mapper
object.

interface IMapper<Input, Output>
{
   Output MapFrom(Input item);
}

class ProgrammerToSomeDTO : IMapper<IProgrammer, SomeDTO>
(Continue reading)

Rickard Öberg | 21 Aug 04:34

Re: Re: Multiple Interfaces

jasonmeckley wrote:
> a domain object containing multiple interfaces isn't bad design in
> itself. (Udi Dahan http://www.udidahan.com/ <http://www.udidahan.com/>) 
> discusses Adaptive Domain
> Models alot.
> Example:
> class JasonMeckley : IPerson, IMale, IHusband, IFather, IProgrammer
> {
> }
> I have an object which has a single responsibility. Expressing myself.
> I express myself in different contexts through different interface.
> 
> If I were to also implement IPersonTO or IPersonDO on the JasonMeckley
> object I would now have multiple responsibilities.
> 1. express JasonMeckley
> 2. map JasonMeckley to a DTO
> 3. persist JasonMeckley to storage
> This would break Single Responsibility and not adhere to Seperation of
> Concerns.

This is one of the main reasons Qi4j exist, with the Composite Oriented 
Programming principles behind it. Basically, I agree that an *object* 
can and should have as many interfaces as contexts it is being used in, 
but to implement these in one single class is clearly madness. 
Therefore, in COP/Qi4j the *object* implements as many interfaces as you 
want, but they are implemented by separate mixins, each having a single 
responsibility. This typically makes the mixins extremely reusable as 
well, if the interfaces are designed well.

/Rickard
(Continue reading)

moffdub | 20 Aug 14:16
Favicon

Re: Multiple Interfaces

OK, what you're suggesting is a definite way to completely do away 
with accessors. However, I'd like to try to avoid references to non-
domain-related objects, like a UI form, in domain objects. 
_______
The views expressed here are mine and do not reflect the official 
opinion of my employer or the organization through which the Internet 
was accessed.

--- In domaindrivendesign <at> yahoogroups.com, Rickard Öberg 
<rickardoberg@...> wrote:
>
> 
> No, that's the other way round. What I'm suggesting is that the 
object 
> itself is the visitor. I.e. if you have a form that needs 
populating 
> with fields from an object, add "visitForm(Form)" to the object. 
The 
> state is then internal to the object and the visitForm() method 
does all 
> the mapping from state to form fields. Maybe "visitForm" is a bad 
name 
> though; something like "populateForm" might be better.
> 
> /Rickard
>

------------------------------------

(Continue reading)

Carfield Yim | 20 Aug 19:04

Re: Multiple Interfaces

I think design the class with proper service method is more important,
otherwise ppl eventually cast to whatever they like and work on it

On 8/20/08, moffdub <moffdub <at> yahoo.com> wrote:
> 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();
(Continue reading)

Pat Maddox | 20 Aug 19:40

Re: Multiple Interfaces

On Wed, Aug 20, 2008 at 1:04 PM, Carfield Yim <carfield <at> gmail.com> wrote:
> I think design the class with proper service method is more important,
> otherwise ppl eventually cast to whatever they like and work on it

I think you only need to go so far in preventing people from shooting
themselves in the foot.  If I provide a service API and they want to
cast the reference to use its DTO API, they can't come crying to me.

Pat

------------------------------------


Gmane