Hello,
when I say "properties" I mean properties in the C# sense : any field which
has public access (either directly or through get/set methods), which is, I
think the meaning you used in your original post.

In general I see no reason to expose the relationship between objects, I
rather try to hide this relationship as I don't want the rest of the system
to depend on the fact that a PartOrderSpec contains a PhysicalPart or three.

Also, since I base my design on behaviors, the relationships need a good
reason to exist, which is usually found in the implementation of
PartOrderSpec's operations : if no PartOrderSpec operation needs to
collaborate with PhysicalPart to accomplish its job then PhysicalPart won't
be a field of PartOrderSpec. It risks to never exist, if I find no good use
for it (which is not just containing data, but a useful behavior for the
rest of the system).

My way (of course I didn't invent it) to design software is, in short, the
following sequence of questions (and I provide sample answers for context) :

What does the customer want the system to do?  When the customer logs in the
system it shows the list of available products.

How does the system do it?  It tells the User to log in, if this works it
tells the Products to show up as a List.

So, I might have identified the role of the System, the User and the
Products. The User must know how to log in, the Products how to show up and
the System how to have them collaborate. Then I pass to ask myself the same
questions about the User and the Products and identify further roles and
responsibilities down the chain.

If I do it in tdd (this being the tdd list) I write down the first response
as a test, then I write the second response as an implementation to make the
test work and refactor to make sure the code is as simple as possible and
likely extract those roles and responsibilities.

Both ways, as you see, I don't care how any of the data is "structured" and
I certainly don't want to expose the fact that the system collaborates with
a User and Products by publishing them in the "properties" you mention as a
Microsoft idiom in classes.
The only case where I care about data being exposed is when I notice <it has
to get visible> as I wonder if that might mean I'm missing some role. But
there's no hard and fast rule and while this produces some distinctively
"tell don't ask" code, it might not enforce it everywhere.

Let me know if this sheds some light on how the "tell don't ask" stuff
works. This is by no means complete.

On Thu, Dec 30, 2010 at 11:15 PM, Alan Baljeu <alanbaljeu@...> wrote:

> It's interesting.  I hope to read from others who either agree or vary from
> this.
>
> But I find myself slightly confused by your answer.
> What I have in mind is not especially properties like "color" (though those
> also
> occur),
> but domain stuff like "PhysicalPart" "PartOrderSpec"and
> "PartCrossSectionDrawing",
> and exposing the relationship between these important objects.
>
>  Alan Baljeu
>
>
>
>
>
> ________________________________
> From: Carlo Bottiglieri <carlo.bottiglieri@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Mon, December 27, 2010 3:23:09 PM
> Subject: Re: [TDD] domain object models
>
>
> I really don't mind exposing properties or not. My issue with
> properties-based design is that it often is design of data structures and
> not objects. Personally I see precious few reasons to expose properties
> (one
> way or another) if the design is based on roles and responsibilities, thus
> I
> use the lack of exposition (and lack of its necessity) as an indicator of a
> design which is likely well centered on a model which properly represents
> the system's behavior.
>
> I don't know if this answer is interesting to you.
>
> On Mon, Dec 27, 2010 at 6:48 PM, Alan Baljeu <alanbaljeu@...> wrote:
>
> > Is there a consensus on the preferred way to design domain object models?
> > What's the general attitude towards Microsoft's approach of objects with
> > public
> > properties exposing the structure of the domain?
> >
> > It seems like a good approach to me, but talk here about Demeter and
> > friends
> > suggests there might be a different better way.  People here write about
> > "tell,
> > don't ask", etc.  I don't understand how that other way works or whether
> it
> > is
> > properly applied to domain modeling.
> >
> >  Alan Baljeu
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

Hi Alan,
    I'm reading Ayende Rahien's "DSLs in BOO" book. It adrresses the problem you
are talking about. In your case seems that you need a rule enginge which should
be your model. So why not trying to develop an Internal Domain Specific Language
to easily adapt to changing business rules?
With Boo and the framework Ayende provides, the developement of a DSL is a
matter of some hours...
    In this way you can specify the rules in Boo scripts, the parser and the
compiler is provided with Boo so you don't have to develop them yourself. Those
scripts sit over C# implementation so you are not dependending on them; you can
decide to script the rules or fluently write them from within your code.
    Another advantage is that your DSL, if well designed, can be read (or written
if you are luky) from the business people, so no misunderstandings on
requirements.
Hope this helps

alessandro di gioia


--- In testdrivendevelopment@yahoogroups.com, Alan Baljeu <alanbaljeu@...>
wrote:
>
> In our case the logic is complex, constantly changing, and interacts with many
> varied objects at once.  Think "business rules".  In this situation I suppose
> pushing logic into model objects doesn't work well.
>
>  Alan Baljeu
>
>
>
>
>
> ________________________________
> From: mallio <jmallinger@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Tue, December 28, 2010 10:43:09 AM
> Subject: [TDD] Re: domain object models
>
>
> A lot of times when we're reviewing usages of our domain models, we'll find
> instances where pushing that logic back into the model makes sense - usually
> those instances are when we're doing something other than simple data-binding
or
> mapping of data to another object.
>
>
> Something I read that I thought was worth a try was to experiment with not
> creating getters in your domain model and see how far that will take you.  I
> personally haven't tried this yet, but this post is a good reminder to give it
a
> shot :)
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

Thanks John.

Looking back, I'm not sure the example gave a very good case for "tell don't
ask" - maybe like mallio wrote:

"usually those instances (of using tell-don't ask - A.N) are when we're doing
something other than simple data-binding or mapping of data to another object."

- Avi


--- In testdrivendevelopment@yahoogroups.com, "Donaldson, John (GEO)"
<john.m.donaldson@...> wrote:
>
> Wow - clear example - thanks Avi!
> John D.
>
> -----Original Message-----
> From: testdrivendevelopment@yahoogroups.com
[mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of avinap77
> Sent: 28 December 2010 18:55
> To: testdrivendevelopment@yahoogroups.com
> Subject: [TDD] Re: domain object models
>
>
>
>
>
> AFAIK domain models with properties apply mostly to modeling entities, wheras
"tell don't ask" applies to modeling processes and interactions.
>
> For instance, a person migh be modeled like this using properties:
>
> class Person
> {
>  string Name;
>  int Age;
>  Person Soupse;
>  Person[] Siblings;
>  Person[] Children;
> }
>
> This models the entity itself.
> So The process of displaying a person on a profile page of a website might
look like this:
>
> class ProfilePage
> {
>  void Display(Person p)
>  {
>    this.txtName = p.Name;
>    this.txtAge = p.Age.ToString();
>    this.txtSpouseName = p.Spouse.Name;
>    this.txtNumberOfChildren = p.Children.Length;
>    ... etc
>  }
> }
>
> So in this type of modeling, the ProfilePage is told to display a person, and
it pulls ("asks") relevant info from the person object.
>
>
>
> Wheras in "tell don't ask", the person might be told to display itself on the
profilepage, like this:
>
>
>
>
>
> class Person
> {
>  private int _age;
>  private string _name;
>  private Person _spouse;
>  private Person[] _children;
>  ... etc;
>
>  void DisplayOn(Personable p)
>  {
>    p.SetAge(_age);
>    p.SetName(_name);
>    p.SetSpouse(_spouse);
>    p.SetChildren(_children);
>    ... etc
>  }
> }
>
>
> interface Personable
> {
>  void SetAge(int age);
>  void SetName(string name);
>  void SetSpouse(Person spouse);
>  void SetChildren(Person[] children);
> }
>
> class ProfilePage : Personable
> {
>  void SetAge(int age)
>  {
>   this.txtAge = age.ToString();
>  }
>
>  void SetName(string name)
>  {
>    this.txtName = name;
>  }
>
>  void SetSpouse(Person spouse)
>  {
>    spouse.DisplayOn(this.SpouseWidget);
>  }
>
>  void SetChildren(Person[] children)
>  {
>    this.txtNumberOfChildren = children.Length;
>  }
>
> }
>
>
> In fact, the person can be told to display itself on any class that implements
the Personable interface - like a PrintableProfilePage, a PeopleCatalog or even
another Person (for instance if one person needs to introduce him/herself to
another person).
>
> Notice it gets really interesting when applying child-objects, like in the
Spouse example above. The spouse is DisplayedOn a SpouseWidget, which might be
implemented in several different ways depending on the current display mode (it
might be configured to show only the spouse's name or the entire profile of the
spouse).
>
> Each object hides it's implementation and exposes only "Telling" interfaces.
>
> BTW the Person object itself could be an interface, with several different
types of people. I can't think of any good reason to do this right now... I
think the classic example for this is with Animals but I've already coughed up
the example, so you get the idea :)
>
>
> Personally I sometimes use one approach and sometimes use another.
**Sometimes** my tests tell me which approach to use - for instance a system
might start off with a simple Property-based approach and as it gets bigger I'll
find common abstractions and refactor to "tell don't ask".
>
> But all in all the Property approach is usually outgrown when there are too
many types of objects and you want to have them cohesively interact with each
other, swapping one type of object for another in a given context.
>
>
>
>
>
>
>
> --- In testdrivendevelopment@yahoogroups.com, Alan Baljeu <alanbaljeu@> wrote:
> >
> > Is there a consensus on the preferred way to design domain object models?
> > What's the general attitude towards Microsoft's approach of objects with
public
> > properties exposing the structure of the domain?
> >
> > It seems like a good approach to me, but talk here about Demeter and friends
> > suggests there might be a different better way.  People here write about
"tell,
> > don't ask", etc.  I don't understand how that other way works or whether it
is
> > properly applied to domain modeling.
> >
> >  Alan Baljeu
> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>

Hi all,

After trying out Ruby for a while, I decided to go back and do the
Game of Life exercise in C++ again to see what the difference would
be.

The result is available here: http://bit.ly/eI3xku

Happy 2011

/Joakim

twitter: jhkarlsson
web: http://jkarlsson.com

In a dedicated programmable rules system.  The rules operate across many model
objects of varied types simultaneously, so they don't belong within a single
model class.

Alan Baljeu



________________________________
From: George Dinwiddie <lists@...>
To: testdrivendevelopment@yahoogroups.com
Sent: Thu, December 30, 2010 5:54:04 PM
Subject: Re: [TDD] Re: domain object models


Alan,

On 12/30/10 5:21 PM, Alan Baljeu wrote:
> In our case the logic is complex, constantly changing, and interacts with many
> varied objects at once.  Think "business rules".  In this situation I suppose
> pushing logic into model objects doesn't work well.

Why not?  That's where I find the most value in pushing the business
rules into the domain model.  Where else would you express them?

- George

--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------






[Non-text portions of this message have been removed]

Since I have a poor grasp of behavior-oriented design, and I will have to study
the other parts of your letter a few times to understand the implications of
this approach.



As for the below, I think this is in error.  You don't expose that a
PartOrderSpec contains a PhysicalPart.  You simply make it that give a
PartOrderSpec you can locate the PhysicalPart object it specifies.  Which for
this particular example seems quite justified.  What does a PartOrderSpec
represent except a means to obtain a part?  The converse is equally true: Given
a PhysicalPart it could know how one can be ordered in real life, and thus bring
you the corresponding PartOrderSpec.

Who owns What is not announced.

Alan Baljeu




________________________________
From: Carlo Bottiglieri <carlo.bottiglieri@...>
To: testdrivendevelopment@yahoogroups.com
Sent: Sat, January 1, 2011 3:55:29 AM
Subject: Re: [TDD] domain object models


In general I see no reason to expose the relationship between objects, I
rather try to hide this relationship as I don't want the rest of the system
to depend on the fact that a PartOrderSpec contains a PhysicalPart or three.






[Non-text portions of this message have been removed]

I've read this through and it looks like a promising approach.  Mostly it seems
like the same UML class diagram would represent the model whether going by
properties or behaviors.  That is, each object still directly connects to the
same objects, but the connections aren't available to their users.

One question has been nagging me:
Given a class Parts, and a class Drawings, where each individual Drawing
contains multiple PartDrawing objects which each represents a Part.


If I create a new Drawing and want to create/include some PartDrawings, what is
the typical way this comes together?
I guess Drawings creates a Drawing.  But how does it get the PartDrawing objects
built?  Doesn't somebody need to gather some Part objects, and isn't that
contrary to the notion of Parts keeping them to itself?  Or else if Part creates
PartDrawings, it will need to be given a Drawing and that's contrary to the idea
that Drawings keeps them to itself.

Confounded,
Alan Baljeu



________________________________
From: Carlo Bottiglieri <carlo.bottiglieri@...>
To: testdrivendevelopment@yahoogroups.com
Sent: Sat, January 1, 2011 3:55:29 AM
Subject: Re: [TDD] domain object models


Hello,
when I say "properties" I mean properties in the C# sense : any field which
has public access (either directly or through get/set methods), which is, I
think the meaning you used in your original post.

In general I see no reason to expose the relationship between objects, I
rather try to hide this relationship as I don't want the rest of the system
to depend on the fact that a PartOrderSpec contains a PhysicalPart or three.

Also, since I base my design on behaviors, the relationships need a good
reason to exist, which is usually found in the implementation of
PartOrderSpec's operations : if no PartOrderSpec operation needs to
collaborate with PhysicalPart to accomplish its job then PhysicalPart won't
be a field of PartOrderSpec. It risks to never exist, if I find no good use
for it (which is not just containing data, but a useful behavior for the
rest of the system).

My way (of course I didn't invent it) to design software is, in short, the
following sequence of questions (and I provide sample answers for context) :

What does the customer want the system to do?  When the customer logs in the
system it shows the list of available products.

How does the system do it?  It tells the User to log in, if this works it
tells the Products to show up as a List.

So, I might have identified the role of the System, the User and the
Products. The User must know how to log in, the Products how to show up and
the System how to have them collaborate. Then I pass to ask myself the same
questions about the User and the Products and identify further roles and
responsibilities down the chain.

If I do it in tdd (this being the tdd list) I write down the first response
as a test, then I write the second response as an implementation to make the
test work and refactor to make sure the code is as simple as possible and
likely extract those roles and responsibilities.

Both ways, as you see, I don't care how any of the data is "structured" and
I certainly don't want to expose the fact that the system collaborates with
a User and Products by publishing them in the "properties" you mention as a
Microsoft idiom in classes.
The only case where I care about data being exposed is when I notice <it has
to get visible> as I wonder if that might mean I'm missing some role. But
there's no hard and fast rule and while this produces some distinctively
"tell don't ask" code, it might not enforce it everywhere.

Let me know if this sheds some light on how the "tell don't ask" stuff
works. This is by no means complete.

On Thu, Dec 30, 2010 at 11:15 PM, Alan Baljeu <alanbaljeu@...> wrote:

> It's interesting.  I hope to read from others who either agree or vary from
> this.
>
> But I find myself slightly confused by your answer.
> What I have in mind is not especially properties like "color" (though those
> also
> occur),
> but domain stuff like "PhysicalPart" "PartOrderSpec"and
> "PartCrossSectionDrawing",
> and exposing the relationship between these important objects.
>
>  Alan Baljeu
>
>
>
>
>
> ________________________________
> From: Carlo Bottiglieri <carlo.bottiglieri@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Mon, December 27, 2010 3:23:09 PM
> Subject: Re: [TDD] domain object models
>
>
> I really don't mind exposing properties or not. My issue with
> properties-based design is that it often is design of data structures and
> not objects. Personally I see precious few reasons to expose properties
> (one
> way or another) if the design is based on roles and responsibilities, thus
> I
> use the lack of exposition (and lack of its necessity) as an indicator of a
> design which is likely well centered on a model which properly represents
> the system's behavior.
>
> I don't know if this answer is interesting to you.
>
> On Mon, Dec 27, 2010 at 6:48 PM, Alan Baljeu <alanbaljeu@...> wrote:
>
> > Is there a consensus on the preferred way to design domain object models?
> > What's the general attitude towards Microsoft's approach of objects with
> > public
> > properties exposing the structure of the domain?
> >
> > It seems like a good approach to me, but talk here about Demeter and
> > friends
> > suggests there might be a different better way.  People here write about
> > "tell,
> > don't ask", etc.  I don't understand how that other way works or whether
> it
> > is
> > properly applied to domain modeling.
> >
> >  Alan Baljeu
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]






[Non-text portions of this message have been removed]

Hello Alan,

On Mon, Jan 3, 2011 at 3:15 PM, Alan Baljeu <alanbaljeu@...> wrote:

>
> As for the below, I think this is in error.


You are probably right, I had to presume the meanings in the domain you
sketched and of course I was biased by you introducing the topic of defining
models through properties. But now I know some more, so let's discuss this
further if you like.


> You don't expose that a
> PartOrderSpec contains a PhysicalPart.  You simply make it that give a
> PartOrderSpec you can locate the PhysicalPart object it specifies.  Which
> for
> this particular example seems quite justified.  What does a PartOrderSpec
> represent except a means to obtain a part?


Well, this is probably the core of the issue. If PartOrderSpec is just a
means to obtain a part, then what good is it? Give me the PhysicalPart and
forget about the PartOrderSpec. Or maybe PartOrderSpec produces a
PhysicalPart? If so, then why do we need the factory of our PhysicalPart to
keep a registry of all the PhysicalPart(s) it produced?
But we shouldn't ignore that we are not talking about properties (those I
treat with get and set) anymore but a rather more complex functionality such
as a registry of produced objects.
Even if we are not discussing access to simple composition anymore the key
question is always what for? What that registry is for?


> The converse is equally true: Given
> a PhysicalPart it could know how one can be ordered in real life, and thus
> bring
> you the corresponding PartOrderSpec.
>
>
Fine. Who needs to know it? Why? Maybe we are speaking about buying a copy
of PhysicalPart, but, why do we need to extract its spec to obtain a clone?


> Who owns What is not announced.
>
> Alan Baljeu
>
>
>
>
> ________________________________
> From: Carlo Bottiglieri <carlo.bottiglieri@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Sat, January 1, 2011 3:55:29 AM
> Subject: Re: [TDD] domain object models
>
>
> In general I see no reason to expose the relationship between objects, I
> rather try to hide this relationship as I don't want the rest of the system
> to depend on the fact that a PartOrderSpec contains a PhysicalPart or
> three.
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

Hello,

On Mon, Jan 3, 2011 at 8:56 PM, Alan Baljeu <alanbaljeu@...> wrote:
[snap]

>
> One question has been nagging me:
> Given a class Parts, and a class Drawings, where each individual Drawing
> contains multiple PartDrawing objects which each represents a Part.
>
>
> If I create a new Drawing and want to create/include some PartDrawings,
> what is
> the typical way this comes together?
> I guess Drawings creates a Drawing.  But how does it get the PartDrawing
> objects
> built?  Doesn't somebody need to gather some Part objects, and isn't that
> contrary to the notion of Parts keeping them to itself?  Or else if Part
> creates
> PartDrawings, it will need to be given a Drawing and that's contrary to the
> idea
> that Drawings keeps them to itself.
>
>
Does this look fine to you?

drawing = Drawing.empty();
drawing.add(palette.drawCircle());
drawing.add(palette.drawRectangle());

Here I interpreted your "PartDrawing" as shapes, correct me if I'm wrong,
but I would need a use case instead of a declaration of relationships to
really know what to propose as otherwise I must presume roles from names and
relations and that's ambiguous (just like a class diagram is ambiguous if
not coupled with interaction diagrams).

Following the interpretation of PartDrawing as a shape I named your "Parts"
as "palette". Even so I must ask myself what is the palette good for.
Missing a use case justifying the delegation of shape drawing to a class
different from the Drawing itself I must not that Drawing doesn't seem to
have a responsibility and would thus fall into a more direct :

drawing = Drawing.empty();
drawing.drawCircle().drawRectangle();

Maybe the drawing is adding shapes to itself with each command, but so far I
think that drawing's client doesn't need to know. It depends on what we
expect drawing to do.

Confounded,
> Alan Baljeu
>
>
>
> ________________________________
> From: Carlo Bottiglieri <carlo.bottiglieri@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Sat, January 1, 2011 3:55:29 AM
> Subject: Re: [TDD] domain object models
>
>
> Hello,
> when I say "properties" I mean properties in the C# sense : any field which
> has public access (either directly or through get/set methods), which is, I
> think the meaning you used in your original post.
>
> In general I see no reason to expose the relationship between objects, I
> rather try to hide this relationship as I don't want the rest of the system
> to depend on the fact that a PartOrderSpec contains a PhysicalPart or
> three.
>
> Also, since I base my design on behaviors, the relationships need a good
> reason to exist, which is usually found in the implementation of
> PartOrderSpec's operations : if no PartOrderSpec operation needs to
> collaborate with PhysicalPart to accomplish its job then PhysicalPart won't
> be a field of PartOrderSpec. It risks to never exist, if I find no good use
> for it (which is not just containing data, but a useful behavior for the
> rest of the system).
>
> My way (of course I didn't invent it) to design software is, in short, the
> following sequence of questions (and I provide sample answers for context)
> :
>
> What does the customer want the system to do?  When the customer logs in
> the
> system it shows the list of available products.
>
> How does the system do it?  It tells the User to log in, if this works it
> tells the Products to show up as a List.
>
> So, I might have identified the role of the System, the User and the
> Products. The User must know how to log in, the Products how to show up and
> the System how to have them collaborate. Then I pass to ask myself the same
> questions about the User and the Products and identify further roles and
> responsibilities down the chain.
>
> If I do it in tdd (this being the tdd list) I write down the first response
> as a test, then I write the second response as an implementation to make
> the
> test work and refactor to make sure the code is as simple as possible and
> likely extract those roles and responsibilities.
>
> Both ways, as you see, I don't care how any of the data is "structured" and
> I certainly don't want to expose the fact that the system collaborates with
> a User and Products by publishing them in the "properties" you mention as a
> Microsoft idiom in classes.
> The only case where I care about data being exposed is when I notice <it
> has
> to get visible> as I wonder if that might mean I'm missing some role. But
> there's no hard and fast rule and while this produces some distinctively
> "tell don't ask" code, it might not enforce it everywhere.
>
> Let me know if this sheds some light on how the "tell don't ask" stuff
> works. This is by no means complete.
>
> On Thu, Dec 30, 2010 at 11:15 PM, Alan Baljeu <alanbaljeu@...>
> wrote:
>
> > It's interesting.  I hope to read from others who either agree or vary
> from
> > this.
> >
> > But I find myself slightly confused by your answer.
> > What I have in mind is not especially properties like "color" (though
> those
> > also
> > occur),
> > but domain stuff like "PhysicalPart" "PartOrderSpec"and
> > "PartCrossSectionDrawing",
> > and exposing the relationship between these important objects.
> >
> >  Alan Baljeu
> >
> >
> >
> >
> >
> > ________________________________
> > From: Carlo Bottiglieri <carlo.bottiglieri@...>
> > To: testdrivendevelopment@yahoogroups.com
> > Sent: Mon, December 27, 2010 3:23:09 PM
> > Subject: Re: [TDD] domain object models
> >
> >
> > I really don't mind exposing properties or not. My issue with
> > properties-based design is that it often is design of data structures and
> > not objects. Personally I see precious few reasons to expose properties
> > (one
> > way or another) if the design is based on roles and responsibilities,
> thus
> > I
> > use the lack of exposition (and lack of its necessity) as an indicator of
> a
> > design which is likely well centered on a model which properly represents
> > the system's behavior.
> >
> > I don't know if this answer is interesting to you.
> >
> > On Mon, Dec 27, 2010 at 6:48 PM, Alan Baljeu <alanbaljeu@...>
> wrote:
> >
> > > Is there a consensus on the preferred way to design domain object
> models?
> > > What's the general attitude towards Microsoft's approach of objects
> with
> > > public
> > > properties exposing the structure of the domain?
> > >
> > > It seems like a good approach to me, but talk here about Demeter and
> > > friends
> > > suggests there might be a different better way.  People here write
> about
> > > "tell,
> > > don't ask", etc.  I don't understand how that other way works or
> whether
> > it
> > > is
> > > properly applied to domain modeling.
> > >
> > >  Alan Baljeu
> > >
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

1) PartOrderSpec and PhysicalPart are both valuable classes.  They have
different information.
Example:
PartOrderSpec xx = a 3/4" #10 Phillips head screw from ACME.  It's really a
database object.
PhysicalPart yy = a model of such a screw in an assembly, including information
about its context.

2) Each is important in different contexts.
3) The user interface will navigate from one to the other.  (Select a Part, show
me the Spec.  Select a Spec, locate the Part.)


yy uses and is derived from xx.  The system that designs yy uses xx.  Other
stuff (e.g. holes) are derived from yy and xx.


Alan Baljeu




________________________________
From: Carlo Bottiglieri <carlo.bottiglieri@...>
To: testdrivendevelopment@yahoogroups.com
Sent: Mon, January 3, 2011 3:53:20 PM
Subject: Re: [TDD] domain object models


Hello Alan,

On Mon, Jan 3, 2011 at 3:15 PM, Alan Baljeu <alanbaljeu@...> wrote:

>
> As for the below, I think this is in error.

You are probably right, I had to presume the meanings in the domain you
sketched and of course I was biased by you introducing the topic of defining
models through properties. But now I know some more, so let's discuss this
further if you like.

> You don't expose that a
> PartOrderSpec contains a PhysicalPart.  You simply make it that give a
> PartOrderSpec you can locate the PhysicalPart object it specifies.  Which
> for
> this particular example seems quite justified.  What does a PartOrderSpec
> represent except a means to obtain a part?

Well, this is probably the core of the issue. If PartOrderSpec is just a
means to obtain a part, then what good is it? Give me the PhysicalPart and
forget about the PartOrderSpec. Or maybe PartOrderSpec produces a
PhysicalPart? If so, then why do we need the factory of our PhysicalPart to
keep a registry of all the PhysicalPart(s) it produced?
But we shouldn't ignore that we are not talking about properties (those I
treat with get and set) anymore but a rather more complex functionality such
as a registry of produced objects.
Even if we are not discussing access to simple composition anymore the key
question is always what for? What that registry is for?

> The converse is equally true: Given
> a PhysicalPart it could know how one can be ordered in real life, and thus
> bring
> you the corresponding PartOrderSpec.
>
>
Fine. Who needs to know it? Why? Maybe we are speaking about buying a copy
of PhysicalPart, but, why do we need to extract its spec to obtain a clone?

> Who owns What is not announced.
>
> Alan Baljeu
>
>
>
>
> ________________________________
> From: Carlo Bottiglieri <carlo.bottiglieri@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Sat, January 1, 2011 3:55:29 AM
> Subject: Re: [TDD] domain object models
>
>
> In general I see no reason to expose the relationship between objects, I
> rather try to hide this relationship as I don't want the rest of the system
> to depend on the fact that a PartOrderSpec contains a PhysicalPart or
> three.
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]






[Non-text portions of this message have been removed]

Thanks for your feedback Carlo.
I see it's hard to communicate ideas without knowing all the details.  Trying to
keep things clear, we have two things: parts (e.g. nuts, bolts), and drawings.
Each part is shown in many (but not all) drawings.  Each drawing shows many (but
not all) parts.

Shapes represent the part, and there's no use drawing a shape unless you have a
part.  And different drawings will draw different shapes for the same part
(front view, side view, etc.).

We could do
     dowelPart.DrawSelf(drawing); // draw part in given drawing.  If it's a side
drawing, draw rectangle.  If top drawing, draw circle.

but this takes us back to the question.  In an tell don't ask program, who has
access to both the Drawing and Part objects?


Use cases are:
- add drawing
- add part
- show part to drawing (making a PartDrawing object)
- delete part from drawing (destroy PartDrawing object)
- delete part (and delete from drawings)
- delete drawing

My scheme would make Parts and Drawings globally accessible objects, each Part
and each Drawing accessible from their containers, and PartDrawing accessible
from Drawing.


If instead we eschew public properties, how do we approach it?

Alan Baljeu




________________________________
From: Carlo Bottiglieri <carlo.bottiglieri@...>Hello,

Does this look fine to you?

drawing = Drawing.empty();
drawing.add(palette.drawCircle());
drawing.add(palette.drawRectangle());



[Non-text portions of this message have been removed]

Dough rosenberg and math stephan have published a book recently name :Design
driven testing :
http://community.sparxsystems.com/whitepapers/test-management/design-driven-test\
ing-sample-chapter-design-javaflex-hotel-mapping-gis.as they showed in figure
6-9 chapter 6 ,enterprise architect has a built in flexunit functionality but I
encounter a problem while I was applying it ,please read the following ,may be
you can help me.


  I have installed Agile/ICONIX add-in for EA ,when I want to start transforming
the test cases into test classes by right click on test case and choose
transform ,the Model Transform dialog box appear ,I want to choose
iconix_FlexUnit as the... (Design Driven Testing: Test Smarter, Not Harder
figure 6-9 chapter 6) .but there isn't any iconix_FlexUnit in Transformations
section(just there are iconix_JUnit and iconix_NUNit.Please help me.
Thank you very much for your attention

Ok,
is it correct if I say that the only client that needs to navigate from a
Part and its Spec is the GUI?

Carlo

On Mon, Jan 3, 2011 at 10:44 PM, Alan Baljeu <alanbaljeu@...> wrote:

> 1) PartOrderSpec and PhysicalPart are both valuable classes.  They have
> different information.
> Example:
> PartOrderSpec xx = a 3/4" #10 Phillips head screw from ACME.  It's really a
> database object.
> PhysicalPart yy = a model of such a screw in an assembly, including
> information
> about its context.
>
> 2) Each is important in different contexts.
> 3) The user interface will navigate from one to the other.  (Select a Part,
> show
> me the Spec.  Select a Spec, locate the Part.)
>
>
> yy uses and is derived from xx.  The system that designs yy uses xx.  Other
> stuff (e.g. holes) are derived from yy and xx.
>
>
> Alan Baljeu
>
>
>
>
> ________________________________
> From: Carlo Bottiglieri <carlo.bottiglieri@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Mon, January 3, 2011 3:53:20 PM
> Subject: Re: [TDD] domain object models
>
>
> Hello Alan,
>
> On Mon, Jan 3, 2011 at 3:15 PM, Alan Baljeu <alanbaljeu@...> wrote:
>
> >
> > As for the below, I think this is in error.
>
> You are probably right, I had to presume the meanings in the domain you
> sketched and of course I was biased by you introducing the topic of
> defining
> models through properties. But now I know some more, so let's discuss this
> further if you like.
>
> > You don't expose that a
> > PartOrderSpec contains a PhysicalPart.  You simply make it that give a
> > PartOrderSpec you can locate the PhysicalPart object it specifies.  Which
> > for
> > this particular example seems quite justified.  What does a PartOrderSpec
> > represent except a means to obtain a part?
>
> Well, this is probably the core of the issue. If PartOrderSpec is just a
> means to obtain a part, then what good is it? Give me the PhysicalPart and
> forget about the PartOrderSpec. Or maybe PartOrderSpec produces a
> PhysicalPart? If so, then why do we need the factory of our PhysicalPart to
> keep a registry of all the PhysicalPart(s) it produced?
> But we shouldn't ignore that we are not talking about properties (those I
> treat with get and set) anymore but a rather more complex functionality
> such
> as a registry of produced objects.
> Even if we are not discussing access to simple composition anymore the key
> question is always what for? What that registry is for?
>
> > The converse is equally true: Given
> > a PhysicalPart it could know how one can be ordered in real life, and
> thus
> > bring
> > you the corresponding PartOrderSpec.
> >
> >
> Fine. Who needs to know it? Why? Maybe we are speaking about buying a copy
> of PhysicalPart, but, why do we need to extract its spec to obtain a clone?
>
> > Who owns What is not announced.
> >
> > Alan Baljeu
> >
> >
> >
> >
> > ________________________________
> > From: Carlo Bottiglieri <carlo.bottiglieri@...>
> > To: testdrivendevelopment@yahoogroups.com
> > Sent: Sat, January 1, 2011 3:55:29 AM
> > Subject: Re: [TDD] domain object models
> >
> >
> > In general I see no reason to expose the relationship between objects, I
> > rather try to hide this relationship as I don't want the rest of the
> system
> > to depend on the fact that a PartOrderSpec contains a PhysicalPart or
> > three.
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

As it stands, many many functions navigate from part to spec.  Most of these are
interested in both.  Whether hypothetically they could each be rewritten to not
go there, I don't know.  It would be awkward, and involve many pass-thru calls.
So this direction is definitely not GUI specific.

Very few functions care *only* about the order spec, though some do and we will
make more.  So far there is little need to go from spec to part aside from GUI.

  Alan Baljeu




________________________________
From: Carlo Bottiglieri <carlo.bottiglieri@...>
To: testdrivendevelopment@yahoogroups.com
Sent: Tue, January 4, 2011 5:12:20 AM
Subject: Re: [TDD] domain object models


Ok,
is it correct if I say that the only client that needs to navigate from a
Part and its Spec is the GUI?

Carlo

On Mon, Jan 3, 2011 at 10:44 PM, Alan Baljeu <alanbaljeu@...> wrote:

> 1) PartOrderSpec and PhysicalPart are both valuable classes.  They have
> different information.
> Example:
> PartOrderSpec xx = a 3/4" #10 Phillips head screw from ACME.  It's really a
> database object.
> PhysicalPart yy = a model of such a screw in an assembly, including
> information
> about its context.
>
> 2) Each is important in different contexts.
> 3) The user interface will navigate from one to the other.  (Select a Part,
> show
> me the Spec.  Select a Spec, locate the Part.)
>
>
> yy uses and is derived from xx.  The system that designs yy uses xx.  Other
> stuff (e.g. holes) are derived from yy and xx.
>
>
> Alan Baljeu
>
>
>
>
> ________________________________
> From: Carlo Bottiglieri <carlo.bottiglieri@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Mon, January 3, 2011 3:53:20 PM
> Subject: Re: [TDD] domain object models
>
>
> Hello Alan,
>
> On Mon, Jan 3, 2011 at 3:15 PM, Alan Baljeu <alanbaljeu@...> wrote:
>
> >
> > As for the below, I think this is in error.
>
> You are probably right, I had to presume the meanings in the domain you
> sketched and of course I was biased by you introducing the topic of
> defining
> models through properties. But now I know some more, so let's discuss this
> further if you like.
>
> > You don't expose that a
> > PartOrderSpec contains a PhysicalPart.  You simply make it that give a
> > PartOrderSpec you can locate the PhysicalPart object it specifies.  Which
> > for
> > this particular example seems quite justified.  What does a PartOrderSpec
> > represent except a means to obtain a part?
>
> Well, this is probably the core of the issue. If PartOrderSpec is just a
> means to obtain a part, then what good is it? Give me the PhysicalPart and
> forget about the PartOrderSpec. Or maybe PartOrderSpec produces a
> PhysicalPart? If so, then why do we need the factory of our PhysicalPart to
> keep a registry of all the PhysicalPart(s) it produced?
> But we shouldn't ignore that we are not talking about properties (those I
> treat with get and set) anymore but a rather more complex functionality
> such
> as a registry of produced objects.
> Even if we are not discussing access to simple composition anymore the key
> question is always what for? What that registry is for?
>
> > The converse is equally true: Given
> > a PhysicalPart it could know how one can be ordered in real life, and
> thus
> > bring
> > you the corresponding PartOrderSpec.
> >
> >
> Fine. Who needs to know it? Why? Maybe we are speaking about buying a copy
> of PhysicalPart, but, why do we need to extract its spec to obtain a clone?
>
> > Who owns What is not announced.
> >
> > Alan Baljeu
> >
> >
> >
> >
> > ________________________________
> > From: Carlo Bottiglieri <carlo.bottiglieri@...>
> > To: testdrivendevelopment@yahoogroups.com
> > Sent: Sat, January 1, 2011 3:55:29 AM
> > Subject: Re: [TDD] domain object models
> >
> >
> > In general I see no reason to expose the relationship between objects, I
> > rather try to hide this relationship as I don't want the rest of the
> system
> > to depend on the fact that a PartOrderSpec contains a PhysicalPart or
> > three.
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]






[Non-text portions of this message have been removed]

Hi George,

On 30/12/2010 10:49 AM, George Dinwiddie wrote:
> I see you started with Board.  At the Floyd Code Retreat
> (http://coderetreat.com/), I did 5 of the 6 sessions in Ruby.  For the
> most part, I went with whatever starting point my partner suggested.
> These included Board, Cell,&  Neighbor.  Then I tried a set-based
> approach suggested by GeePaw Hill, and a "stupidist thing that could
> possibly work" approach where everything was represented as an array of
> strings.  Great fun!

A few years back I was coaching in St. Louis and was able to attend one
of their XP group meetings.  Brian Button ran it, and I believe the
topic or theme was "what's the first test in TDD?".  We paired off and
our goal was to TDD the game of Blackjack.  IIRC there were 6 or 7
pairs, and after an hour we compared our progress.

Every pair had something working to an extent.  Every pair started in a
different place.  None of those places was "wrong".

I've referred back to that experience many times since.  User Stories,
and tasks to an extent, provide the overall goal of the development work
but there are many different ways to achieve that goal from a
programming and TDD perspective.
--
Dave Rooney
Westboro Systems
Web: http://www.WestboroSystems.com
Blog: http://practicalagility.blogspot.com
Twitter: daverooneyca

This sounds like a good idea to me.  How would you (anybody) recommend getting
there from here?  Currently we have mostly classes like the first kind of
Person.  I fear gradually switching over to the second style will result in a
royal mashup of classes with both types of interface, and really ugly code.
Perhaps a better approach is to keep the old Person unchanged and make


class NewPerson

{
private Person p;
public void DisplayOn(Personable pable);
}

Yay/nay?

Alan Baljeu





________________________________
-----Original Message-----

From: testdrivendevelopment@yahoogroups.com
[mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of avinap77
Sent: 28 December 2010 18:55
To: testdrivendevelopment@yahoogroups.com
Subject: [TDD] Re: domain object models

AFAIK domain models with properties apply mostly to modeling entities, wheras
"tell don't ask" applies to modeling processes and interactions.

For instance, a person migh be modeled like this using properties:

class Person
{
string Name;
int Age;
Person Soupse;
Person[] Siblings;
Person[] Children;
}

This models the entity itself.
So The process of displaying a person on a profile page of a website might look
like this:

class ProfilePage
{
void Display(Person p)
{
this.txtName = p.Name;
this.txtAge = p.Age.ToString();
this.txtSpouseName = p.Spouse.Name;
this.txtNumberOfChildren = p.Children.Length;
... etc
}
}

So in this type of modeling, the ProfilePage is told to display a person, and it
pulls ("asks") relevant info from the person object.

Wheras in "tell don't ask", the person might be told to display itself on the
profilepage, like this:

class Person
{
private int _age;
private string _name;
private Person _spouse;
private Person[] _children;
... etc;

void DisplayOn(Personable p)
{
p.SetAge(_age);
p.SetName(_name);
p.SetSpouse(_spouse);
p.SetChildren(_children);
... etc
}
}

interface Personable
{
void SetAge(int age);
void SetName(string name);
void SetSpouse(Person spouse);
void SetChildren(Person[] children);
}

class ProfilePage : Personable
{
void SetAge(int age)
{
this.txtAge = age.ToString();
}

void SetName(string name)
{
this.txtName = name;
}

void SetSpouse(Person spouse)
{
spouse.DisplayOn(this.SpouseWidget);
}

void SetChildren(Person[] children)
{
this.txtNumberOfChildren = children.Length;
}

}

In fact, the person can be told to display itself on any class that implements
the Personable interface - like a PrintableProfilePage, a PeopleCatalog or even
another Person (for instance if one person needs to introduce him/herself to
another person).

Notice it gets really interesting when applying child-objects, like in the
Spouse example above. The spouse is DisplayedOn a SpouseWidget, which might be
implemented in several different ways depending on the current display mode (it
might be configured to show only the spouse's name or the entire profile of the
spouse).

Each object hides it's implementation and exposes only "Telling" interfaces.

BTW the Person object itself could be an interface, with several different types
of people. I can't think of any good reason to do this right now... I think the
classic example for this is with Animals but I've already coughed up the
example, so you get the idea :)

Personally I sometimes use one approach and sometimes use another. **Sometimes**
my tests tell me which approach to use - for instance a system might start off
with a simple Property-based approach and as it gets bigger I'll find common
abstractions and refactor to "tell don't ask".


But all in all the Property approach is usually outgrown when there are too many
types of objects and you want to have them cohesively interact with each other,
swapping one type of object for another in a given context.

--- In testdrivendevelopment@yahoogroups.com, Alan Baljeu <alanbaljeu@...>
wrote:
>
> Is there a consensus on the preferred way to design domain object models?
> What's the general attitude towards Microsoft's approach of objects with
public
>
> properties exposing the structure of the domain?
>
> It seems like a good approach to me, but talk here about Demeter and friends
> suggests there might be a different better way.  People here write about
"tell,
>
> don't ask", etc.  I don't understand how that other way works or whether it is

> properly applied to domain modeling.
>
>  Alan Baljeu
>

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

Yahoo! Groups Links






[Non-text portions of this message have been removed]

We could argue about whether this is really TDD or not.  The tests I
write are at the REPL.  In any case, posting it here as a curiosity.

http://michaelfeathers.typepad.com/michael_feathers_blog/2011/01/the-string-calc\
ulator-kata-in-haskell.html

Kata description here: http://katas.softwarecraftsmanship.org/?p=80

Michael

Alan Baljeu
http://www.collaborative-systems.org
Intelligent software that works _with_ you.




________________________________
From: mfeathers256 <mfeathers@...>
To: testdrivendevelopment@yahoogroups.com
Sent: Tue, January 4, 2011 11:28:23 AM
Subject: [TDD] TDD Kata: String Calculator in Haskell


We could argue about whether this is really TDD or not.  The tests I
write are at the REPL.  In any case, posting it here as a curiosity.

http://michaelfeathers.typepad.com/michael_feathers_blog/2011/01/the-string-calc\
ulator-kata-in-haskell.html


Kata description here: http://katas.softwarecraftsmanship.org/?p=80

Michael






[Non-text portions of this message have been removed]

Hi,

Anybody knows how I can mock a Object Parameter in a void method?
I am using mockito 1.8.4 and powermock 1.3.8 (to static methods).

CODE:

...
ClassX.StaticClassX *param *= new ClassX();
param.setX(aaaaaaa);

ClassX.execute(x, param);  //already mocked

....

Here I manipulate the param

[/CODE]

I want to mock the object parameter "param"
because I use this object parameter on the method execution.

Thank´s

André


[Non-text portions of this message have been removed]

Hope that you may be interested in this ..

Reminder. January 7 is the last day for proposing sessions for XP2011 conference
in Madrid Spain on 10-13th May.

XP2011 is the 12th international conference on Agile Software Development and
will be hosted by Universidad Politécnica de Madrid in Spain. The conference
brings together both industrial practitioners and researchers in the fields of
information systems and software development, and examines latest theory,
practical applications, and implications of agile methods.

The conference has a strong research bias. We're looking for various session
types:- instructive tutorials, exploratory workshops, innovative demonstrations,
visible posters, industrial experiences, and more. Get the details on session
types at at http://www.xp2011.org/node/6

This conference is a non-commercial conference organised at a university by a
team of volunteers, we hope you understand that this limits the speaker
compensation package we are able to offer. There will be 1 free registration for
each tutorial or workshop that is accepted (hotel and travel costs are not
included). Presenters of other session types will be offered significant
registration discounts.

Please submit details of your session proposals online at
http://www.easychair.org/conferences/?conf=xp2011 by Jan 7.

.. and pass this reminder onto friends and colleagues too :-)

thanks,

Rachel Davies
General chair, XP2011 conference

Sorry for the delay.

Why all of these functions have to perform this navigation instead of
belonging to one or another object?

I'll answer the "drawing" part as well, just need some time, sorry.

Carlo

On Tue, Jan 4, 2011 at 2:45 PM, Alan Baljeu <alanbaljeu@...> wrote:

> As it stands, many many functions navigate from part to spec.  Most of
> these are
> interested in both.  Whether hypothetically they could each be rewritten to
> not
> go there, I don't know.  It would be awkward, and involve many pass-thru
> calls.
> So this direction is definitely not GUI specific.
>
> Very few functions care *only* about the order spec, though some do and we
> will
> make more.  So far there is little need to go from spec to part aside from
> GUI.
>
>  Alan Baljeu
>
>
>
>
> ________________________________
> From: Carlo Bottiglieri <carlo.bottiglieri@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Tue, January 4, 2011 5:12:20 AM
> Subject: Re: [TDD] domain object models
>
>
> Ok,
> is it correct if I say that the only client that needs to navigate from a
> Part and its Spec is the GUI?
>
> Carlo
>
> On Mon, Jan 3, 2011 at 10:44 PM, Alan Baljeu <alanbaljeu@...> wrote:
>
> > 1) PartOrderSpec and PhysicalPart are both valuable classes.  They have
> > different information.
> > Example:
> > PartOrderSpec xx = a 3/4" #10 Phillips head screw from ACME.  It's really
> a
> > database object.
> > PhysicalPart yy = a model of such a screw in an assembly, including
> > information
> > about its context.
> >
> > 2) Each is important in different contexts.
> > 3) The user interface will navigate from one to the other.  (Select a
> Part,
> > show
> > me the Spec.  Select a Spec, locate the Part.)
> >
> >
> > yy uses and is derived from xx.  The system that designs yy uses xx.
>  Other
> > stuff (e.g. holes) are derived from yy and xx.
> >
> >
> > Alan Baljeu
> >
> >
> >
> >
> > ________________________________
> > From: Carlo Bottiglieri <carlo.bottiglieri@...>
> > To: testdrivendevelopment@yahoogroups.com
> > Sent: Mon, January 3, 2011 3:53:20 PM
> > Subject: Re: [TDD] domain object models
> >
> >
> > Hello Alan,
> >
> > On Mon, Jan 3, 2011 at 3:15 PM, Alan Baljeu <alanbaljeu@...>
> wrote:
> >
> > >
> > > As for the below, I think this is in error.
> >
> > You are probably right, I had to presume the meanings in the domain you
> > sketched and of course I was biased by you introducing the topic of
> > defining
> > models through properties. But now I know some more, so let's discuss
> this
> > further if you like.
> >
> > > You don't expose that a
> > > PartOrderSpec contains a PhysicalPart.  You simply make it that give a
> > > PartOrderSpec you can locate the PhysicalPart object it specifies.
>  Which
> > > for
> > > this particular example seems quite justified.  What does a
> PartOrderSpec
> > > represent except a means to obtain a part?
> >
> > Well, this is probably the core of the issue. If PartOrderSpec is just a
> > means to obtain a part, then what good is it? Give me the PhysicalPart
> and
> > forget about the PartOrderSpec. Or maybe PartOrderSpec produces a
> > PhysicalPart? If so, then why do we need the factory of our PhysicalPart
> to
> > keep a registry of all the PhysicalPart(s) it produced?
> > But we shouldn't ignore that we are not talking about properties (those I
> > treat with get and set) anymore but a rather more complex functionality
> > such
> > as a registry of produced objects.
> > Even if we are not discussing access to simple composition anymore the
> key
> > question is always what for? What that registry is for?
> >
> > > The converse is equally true: Given
> > > a PhysicalPart it could know how one can be ordered in real life, and
> > thus
> > > bring
> > > you the corresponding PartOrderSpec.
> > >
> > >
> > Fine. Who needs to know it? Why? Maybe we are speaking about buying a
> copy
> > of PhysicalPart, but, why do we need to extract its spec to obtain a
> clone?
> >
> > > Who owns What is not announced.
> > >
> > > Alan Baljeu
> > >
> > >
> > >
> > >
> > > ________________________________
> > > From: Carlo Bottiglieri <carlo.bottiglieri@...>
> > > To: testdrivendevelopment@yahoogroups.com
> > > Sent: Sat, January 1, 2011 3:55:29 AM
> > > Subject: Re: [TDD] domain object models
> > >
> > >
> > > In general I see no reason to expose the relationship between objects,
> I
> > > rather try to hide this relationship as I don't want the rest of the
> > system
> > > to depend on the fact that a PartOrderSpec contains a PhysicalPart or
> > > three.
> > >
> > >
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

Alan,

On 1/2/11 6:11 PM, Alan Baljeu wrote:
> In a dedicated programmable rules system.  The rules operate across many model
> objects of varied types simultaneously, so they don't belong within a single
> model class.

I suspect the issue is that your model objects tend to model the data
aspects, rather than behavior.  I think that I would tend to invert
that, and have the model objects delegate to rules as appropriate.

My understanding of your domain is quite abstract and fuzzy, though, and
I could be more precise were we pairing on the code.

   - George

>
> Alan Baljeu
>
>
>
> ________________________________
> From: George Dinwiddie<lists@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Thu, December 30, 2010 5:54:04 PM
> Subject: Re: [TDD] Re: domain object models
>
>
> Alan,
>
> On 12/30/10 5:21 PM, Alan Baljeu wrote:
>> In our case the logic is complex, constantly changing, and interacts with
many
>> varied objects at once.  Think "business rules".  In this situation I suppose
>> pushing logic into model objects doesn't work well.
>
> Why not?  That's where I find the most value in pushing the business
> rules into the domain model.  Where else would you express them?
>
> - George
>

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

>Why all of these functions have to perform this navigation instead of
>belonging to one or another object?

Why?  Because this ol' program ain't OOP.

I *imagine* I could create a new class.  <dream>In that class I put a dozen or
so of the fundamental computations which essentially [i.e. unavoidably] depend
on both objects.  Now these "many many" would take the Part, ask for this
special new interface, and be completely satisfied with that.</dream>

Alan Baljeu





________________________________
From: Carlo Bottiglieri <carlo.bottiglieri@...>
To: testdrivendevelopment@yahoogroups.com
Sent: Wed, January 5, 2011 2:58:47 PM
Subject: Re: [TDD] domain object models


Sorry for the delay.

Why all of these functions have to perform this navigation instead of
belonging to one or another object?

I'll answer the "drawing" part as well, just need some time, sorry.

Carlo

On Tue, Jan 4, 2011 at 2:45 PM, Alan Baljeu <alanbaljeu@...> wrote:

> As it stands, many many functions navigate from part to spec.  Most of
> these are
> interested in both.  Whether hypothetically they could each be rewritten to
> not
> go there, I don't know.  It would be awkward, and involve many pass-thru
> calls.
> So this direction is definitely not GUI specific.
>
> Very few functions care *only* about the order spec, though some do and we
> will
> make more.  So far there is little need to go from spec to part aside from
> GUI.
>
>  Alan Baljeu
>
>
>
>
> ________________________________
> From: Carlo Bottiglieri <carlo.bottiglieri@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Tue, January 4, 2011 5:12:20 AM
> Subject: Re: [TDD] domain object models
>
>
> Ok,
> is it correct if I say that the only client that needs to navigate from a
> Part and its Spec is the GUI?
>
> Carlo
>
> On Mon, Jan 3, 2011 at 10:44 PM, Alan Baljeu <alanbaljeu@...> wrote:
>
> > 1) PartOrderSpec and PhysicalPart are both valuable classes.  They have
> > different information.
> > Example:
> > PartOrderSpec xx = a 3/4" #10 Phillips head screw from ACME.  It's really
> a
> > database object.
> > PhysicalPart yy = a model of such a screw in an assembly, including
> > information
> > about its context.
> >
> > 2) Each is important in different contexts.
> > 3) The user interface will navigate from one to the other.  (Select a
> Part,
> > show
> > me the Spec.  Select a Spec, locate the Part.)
> >
> >
> > yy uses and is derived from xx.  The system that designs yy uses xx.
>  Other
> > stuff (e.g. holes) are derived from yy and xx.
> >
> >
> > Alan Baljeu
> >
> >
> >
> >
> > ________________________________
> > From: Carlo Bottiglieri <carlo.bottiglieri@...>
> > To: testdrivendevelopment@yahoogroups.com
> > Sent: Mon, January 3, 2011 3:53:20 PM
> > Subject: Re: [TDD] domain object models
> >
> >
> > Hello Alan,
> >
> > On Mon, Jan 3, 2011 at 3:15 PM, Alan Baljeu <alanbaljeu@...>
> wrote:
> >
> > >
> > > As for the below, I think this is in error.
> >
> > You are probably right, I had to presume the meanings in the domain you
> > sketched and of course I was biased by you introducing the topic of
> > defining
> > models through properties. But now I know some more, so let's discuss
> this
> > further if you like.
> >
> > > You don't expose that a
> > > PartOrderSpec contains a PhysicalPart.  You simply make it that give a
> > > PartOrderSpec you can locate the PhysicalPart object it specifies.
>  Which
> > > for
> > > this particular example seems quite justified.  What does a
> PartOrderSpec
> > > represent except a means to obtain a part?
> >
> > Well, this is probably the core of the issue. If PartOrderSpec is just a
> > means to obtain a part, then what good is it? Give me the PhysicalPart
> and
> > forget about the PartOrderSpec. Or maybe PartOrderSpec produces a
> > PhysicalPart? If so, then why do we need the factory of our PhysicalPart
> to
> > keep a registry of all the PhysicalPart(s) it produced?
> > But we shouldn't ignore that we are not talking about properties (those I
> > treat with get and set) anymore but a rather more complex functionality
> > such
> > as a registry of produced objects.
> > Even if we are not discussing access to simple composition anymore the
> key
> > question is always what for? What that registry is for?
> >
> > > The converse is equally true: Given
> > > a PhysicalPart it could know how one can be ordered in real life, and
> > thus
> > > bring
> > > you the corresponding PartOrderSpec.
> > >
> > >
> > Fine. Who needs to know it? Why? Maybe we are speaking about buying a
> copy
> > of PhysicalPart, but, why do we need to extract its spec to obtain a
> clone?
> >
> > > Who owns What is not announced.
> > >
> > > Alan Baljeu
> > >
> > >
> > >
> > >
> > > ________________________________
> > > From: Carlo Bottiglieri <carlo.bottiglieri@...>
> > > To: testdrivendevelopment@yahoogroups.com
> > > Sent: Sat, January 1, 2011 3:55:29 AM
> > > Subject: Re: [TDD] domain object models
> > >
> > >
> > > In general I see no reason to expose the relationship between objects,
> I
> > > rather try to hide this relationship as I don't want the rest of the
> > system
> > > to depend on the fact that a PartOrderSpec contains a PhysicalPart or
> > > three.
> > >
> > >
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]






[Non-text portions of this message have been removed]

Unfortunately it's quite impossible to clearly communicate the details of our
domain in this forum.  If you care to stop by and do some pairing, we're only
1000 miles down the road :-)

You are [inadvertantly] proposing a major paradigm shift here.  I'm not sure
whether I can make sense of your suggestion in this context.  Ours is not an
event-response type rule system.  It's a data calculation system.  How do you
take this rule:
Rule 1: a.x + b.y = c.z
and convert it into "object b delegates to rule 1" and not expose the data of
a,b, or c?  I can think of many ways to apply abstraction, but no ways to avoid
interfaces that expose properties with numerical values.

The rules operate like a spreadsheet on objects, where formulas compute new
values from other values in related objects.  Mathematical relations are
fundamental here.  The following example is not our domain, not our rules
system, but illustrates the concept.

http://www.genworks.com/downloads/customer-documentation/usage.txt

If anybody here can recast that example without public properties, I'm very
curious to see.



________________________________
From: George Dinwiddie <lists@...>
To: testdrivendevelopment@yahoogroups.com
Sent: Wed, January 5, 2011 11:32:55 PM
Subject: Re: [TDD] Re: domain object models


Alan,

On 1/2/11 6:11 PM, Alan Baljeu wrote:
> In a dedicated programmable rules system.  The rules operate across many model
> objects of varied types simultaneously, so they don't belong within a single
> model class.

I suspect the issue is that your model objects tend to model the data
aspects, rather than behavior.  I think that I would tend to invert
that, and have the model objects delegate to rules as appropriate.

My understanding of your domain is quite abstract and fuzzy, though, and
I could be more precise were we pairing on the code.

- George

>
> Alan Baljeu
>
>
>
> ________________________________
> From: George Dinwiddie<lists@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Thu, December 30, 2010 5:54:04 PM
> Subject: Re: [TDD] Re: domain object models
>
>
> Alan,
>
> On 12/30/10 5:21 PM, Alan Baljeu wrote:
>> In our case the logic is complex, constantly changing, and interacts with
many
>> varied objects at once.  Think "business rules".  In this situation I suppose
>> pushing logic into model objects doesn't work well.
>
> Why not?  That's where I find the most value in pushing the business
> rules into the domain model.  Where else would you express them?
>
> - George
>

--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------






[Non-text portions of this message have been removed]

I think this link has interesting thoughts on mocks and spies.

http://blogs.ugidotnet.org/luKa/archive/2011/01/06/tdd-with-mocks-or-spies.aspx

For some reasons he says there, I prefer to use JMock.

Abraços,
Josué
http://twitter.com/josuesantos


[Non-text portions of this message have been removed]

This question is *very* important to me.  I'm creating new classes to wrap
previous structs.  I like to move to more of "the class is responsible", but we
have LOTS of "the user is responsible" code.


For any class in this situation, which would you follow?
A) extend the class, and gradually eliminate the old style of usage
B) make a new wrapper class, and gradually eliminate use of the interior class

C) It really depends.  How then do I choose?
D) Don't bother.

Bear in mind that we'll probably never completely eliminate old stuff.



From: Alan Baljeu <alanbaljeu@...>
To: testdrivendevelopment@yahoogroups.com
Sent: Tue, January 4, 2011 9:25:40 AM
Subject: Re: [TDD] Re: domain object models


This sounds like a good idea to me.  How would you (anybody) recommend getting
there from here?  Currently we have mostly classes like the first kind of
Person.  I fear gradually switching over to the second style will result in a
royal mashup of classes with both types of interface, and really ugly code.
Perhaps a better approach is to keep the old Person unchanged and make

class NewPerson

{
private Person p;
public void DisplayOn(Personable pable);
}

Yay/nay?

Alan Baljeu

________________________________
-----Original Message-----

From: testdrivendevelopment@yahoogroups.com
[mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of avinap77
Sent: 28 December 2010 18:55
To: testdrivendevelopment@yahoogroups.com
Subject: [TDD] Re: domain object models

AFAIK domain models with properties apply mostly to modeling entities, wheras
"tell don't ask" applies to modeling processes and interactions.

For instance, a person migh be modeled like this using properties:

class Person
{
string Name;
int Age;
Person Soupse;
Person[] Siblings;
Person[] Children;
}

This models the entity itself.
So The process of displaying a person on a profile page of a website might look
like this:

class ProfilePage
{
void Display(Person p)
{
this.txtName = p.Name;
this.txtAge = p.Age.ToString();
this.txtSpouseName = p.Spouse.Name;
this.txtNumberOfChildren = p.Children.Length;
... etc
}
}

So in this type of modeling, the ProfilePage is told to display a person, and it

pulls ("asks") relevant info from the person object.

Wheras in "tell don't ask", the person might be told to display itself on the
profilepage, like this:

class Person
{
private int _age;
private string _name;
private Person _spouse;
private Person[] _children;
... etc;

void DisplayOn(Personable p)
{
p.SetAge(_age);
p.SetName(_name);
p.SetSpouse(_spouse);
p.SetChildren(_children);
... etc
}
}

interface Personable
{
void SetAge(int age);
void SetName(string name);
void SetSpouse(Person spouse);
void SetChildren(Person[] children);
}

class ProfilePage : Personable
{
void SetAge(int age)
{
this.txtAge = age.ToString();
}

void SetName(string name)
{
this.txtName = name;
}

void SetSpouse(Person spouse)
{
spouse.DisplayOn(this.SpouseWidget);
}

void SetChildren(Person[] children)
{
this.txtNumberOfChildren = children.Length;
}

}

In fact, the person can be told to display itself on any class that implements
the Personable interface - like a PrintableProfilePage, a PeopleCatalog or even
another Person (for instance if one person needs to introduce him/herself to
another person).

Notice it gets really interesting when applying child-objects, like in the
Spouse example above. The spouse is DisplayedOn a SpouseWidget, which might be
implemented in several different ways depending on the current display mode (it
might be configured to show only the spouse's name or the entire profile of the
spouse).

Each object hides it's implementation and exposes only "Telling" interfaces.

BTW the Person object itself could be an interface, with several different types

of people. I can't think of any good reason to do this right now... I think the
classic example for this is with Animals but I've already coughed up the
example, so you get the idea :)

Personally I sometimes use one approach and sometimes use another. **Sometimes**

my tests tell me which approach to use - for instance a system might start off
with a simple Property-based approach and as it gets bigger I'll find common
abstractions and refactor to "tell don't ask".

But all in all the Property approach is usually outgrown when there are too many

types of objects and you want to have them cohesively interact with each other,
swapping one type of object for another in a given context.

--- In testdrivendevelopment@yahoogroups.com, Alan Baljeu <alanbaljeu@...>
wrote:
>
> Is there a consensus on the preferred way to design domain object models?
> What's the general attitude towards Microsoft's approach of objects with
public
>
>
> properties exposing the structure of the domain?
>
> It seems like a good approach to me, but talk here about Demeter and friends
> suggests there might be a different better way.  People here write about
"tell,
>
>
> don't ask", etc.  I don't understand how that other way works or whether it is


> properly applied to domain modeling.
>
>  Alan Baljeu
>

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

Yahoo! Groups Links

[Non-text portions of this message have been removed]






[Non-text portions of this message have been removed]

Wouldn't this work?  Extract interfaces where needed.

public class A
{
  private int x;

  public void Write ( C c )
{
      c.Add( x );
}
}

public class B
{
  private int y;

public void Write( C c )
{
   c.Add( y );
}
}

public class C
{
private int z;

public void Add( A a, B b )
{
z = 0;
a.Write( this );
b.Write( this );
}

public void Add( int number )
{
  z += number;
}
}

On Thu, Jan 6, 2011 at 2:44 PM, Alan Baljeu <alanbaljeu@...> wrote:
> Unfortunately it's quite impossible to clearly communicate the details of our
> domain in this forum.  If you care to stop by and do some pairing, we're only
> 1000 miles down the road :-)
>
> You are [inadvertantly] proposing a major paradigm shift here.  I'm not sure
> whether I can make sense of your suggestion in this context.  Ours is not an
> event-response type rule system.  It's a data calculation system.  How do you
> take this rule:
> Rule 1: a.x + b.y = c.z
> and convert it into "object b delegates to rule 1" and not expose the data of
> a,b, or c?  I can think of many ways to apply abstraction, but no ways to
avoid
> interfaces that expose properties with numerical values.
>
> The rules operate like a spreadsheet on objects, where formulas compute new
> values from other values in related objects.  Mathematical relations are
> fundamental here.  The following example is not our domain, not our rules
> system, but illustrates the concept.
>
> http://www.genworks.com/downloads/customer-documentation/usage.txt
>
> If anybody here can recast that example without public properties, I'm very
> curious to see.
>
>
>
> ________________________________
> From: George Dinwiddie <lists@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Wed, January 5, 2011 11:32:55 PM
> Subject: Re: [TDD] Re: domain object models
>
>
> Alan,
>
> On 1/2/11 6:11 PM, Alan Baljeu wrote:
>> In a dedicated programmable rules system.  The rules operate across many
model
>> objects of varied types simultaneously, so they don't belong within a single
>> model class.
>
> I suspect the issue is that your model objects tend to model the data
> aspects, rather than behavior.  I think that I would tend to invert
> that, and have the model objects delegate to rules as appropriate.
>
> My understanding of your domain is quite abstract and fuzzy, though, and
> I could be more precise were we pairing on the code.
>
> - George
>
>>
>> Alan Baljeu
>>
>>
>>
>> ________________________________
>> From: George Dinwiddie<lists@...>
>> To: testdrivendevelopment@yahoogroups.com
>> Sent: Thu, December 30, 2010 5:54:04 PM
>> Subject: Re: [TDD] Re: domain object models
>>
>>
>> Alan,
>>
>> On 12/30/10 5:21 PM, Alan Baljeu wrote:
>>> In our case the logic is complex, constantly changing, and interacts with
> many
>>> varied objects at once.  Think "business rules".  In this situation I
suppose
>>> pushing logic into model objects doesn't work well.
>>
>> Why not?  That's where I find the most value in pushing the business
>> rules into the domain model.  Where else would you express them?
>>
>> - George
>>
>
> --
> ----------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>



--
thanks

cliff

Interesting, though more confusing to read than a + b = c.

But I'm talking about run-time programmability.  You've taken an external rule
and hard-coded it into fixed behavior of the classes.

Alan Baljeu





________________________________
From: cliff <POWERDUDE@...>
To: testdrivendevelopment <testdrivendevelopment@yahoogroups.com>
Sent: Thu, January 6, 2011 3:04:33 PM
Subject: Re: [TDD] Re: domain object models


Wouldn't this work?  Extract interfaces where needed.

public class A
{
private int x;

public void Write ( C c )
{
c.Add( x );
}
}

public class B
{
private int y;

public void Write( C c )
{
c.Add( y );
}
}

public class C
{
private int z;

public void Add( A a, B b )
{
z = 0;
a.Write( this );
b.Write( this );
}

public void Add( int number )
{
z += number;
}
}

On Thu, Jan 6, 2011 at 2:44 PM, Alan Baljeu <alanbaljeu@...> wrote:
> Unfortunately it's quite impossible to clearly communicate the details of our
> domain in this forum.  If you care to stop by and do some pairing, we're only
> 1000 miles down the road :-)
>
> You are [inadvertantly] proposing a major paradigm shift here.  I'm not sure
> whether I can make sense of your suggestion in this context.  Ours is not an
> event-response type rule system.  It's a data calculation system.  How do you
> take this rule:
> Rule 1: a.x + b.y = c.z
> and convert it into "object b delegates to rule 1" and not expose the data of
> a,b, or c?  I can think of many ways to apply abstraction, but no ways to
avoid
> interfaces that expose properties with numerical values.
>
> The rules operate like a spreadsheet on objects, where formulas compute new
> values from other values in related objects.  Mathematical relations are
> fundamental here.  The following example is not our domain, not our rules
> system, but illustrates the concept.
>
> http://www.genworks.com/downloads/customer-documentation/usage.txt
>
> If anybody here can recast that example without public properties, I'm very
> curious to see.
>
>
>
> ________________________________
> From: George Dinwiddie <lists@...>
> To: testdrivendevelopment@yahoogroups.com
> Sent: Wed, January 5, 2011 11:32:55 PM
> Subject: Re: [TDD] Re: domain object models
>
>
> Alan,
>
> On 1/2/11 6:11 PM, Alan Baljeu wrote:
>> In a dedicated programmable rules system.  The rules operate across many
model
>> objects of varied types simultaneously, so they don't belong within a single
>> model class.
>
> I suspect the issue is that your model objects tend to model the data
> aspects, rather than behavior.  I think that I would tend to invert
> that, and have the model objects delegate to rules as appropriate.
>
> My understanding of your domain is quite abstract and fuzzy, though, and
> I could be more precise were we pairing on the code.
>
> - George
>
>>
>> Alan Baljeu
>>
>>
>>
>> ________________________________
>> From: George Dinwiddie<lists@...>
>> To: testdrivendevelopment@yahoogroups.com
>> Sent: Thu, December 30, 2010 5:54:04 PM
>> Subject: Re: [TDD] Re: domain object models
>>
>>
>> Alan,
>>
>> On 12/30/10 5:21 PM, Alan Baljeu wrote:
>>> In our case the logic is complex, constantly changing, and interacts with
> many
>>> varied objects at once.  Think "business rules".  In this situation I
suppose
>>> pushing logic into model objects doesn't work well.
>>
>> Why not?  That's where I find the most value in pushing the business
>> rules into the domain model.  Where else would you express them?
>>
>> - George
>>
>
> --
> ----------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--
thanks

cliff





[Non-text portions of this message have been removed]

Here's an approach I just used in a vaguely similar (but really different)
context. YMMV...

Create interface IOldPerson incorporating everything you now use out of
Person.
Create interface IPerson with the members you want to use in the future.

Make Person implement both interfaces, adding NYI new members as
needed to compile.

Switch all your client code to using IOldPerson rather than Person

At this point, you have made no real changes, so all tests should still
pass.

When you are ready to convert any client, switch it to use IPerson.

When nobody is using IOldPerson, remove both the interface and the
implementing methods in Person.

A variation - the one I used, in fact - is to develop IPerson incrementally,
adding functionality to it as you go. This will probably involve having
some methods on both interfaces initially.

Using interfaces to restrict what may be called is a powerful refactoring
tool.

Charlie

On Thu, Jan 6, 2011 at 12:03 PM, Alan Baljeu <alanbaljeu@...> wrote:

>
>
> This question is *very* important to me. I'm creating new classes to wrap
> previous structs. I like to move to more of "the class is responsible", but
> we
> have LOTS of "the user is responsible" code.
>
> For any class in this situation, which would you follow?
> A) extend the class, and gradually eliminate the old style of usage
> B) make a new wrapper class, and gradually eliminate use of the interior
> class
>
> C) It really depends. How then do I choose?
> D) Don't bother.
>
> Bear in mind that we'll probably never completely eliminate old stuff.
>
> From: Alan Baljeu <alanbaljeu@... <alanbaljeu%40yahoo.com>>
> To:
testdrivendevelopment@yahoogroups.com<testdrivendevelopment%40yahoogroups.com>
> Sent: Tue, January 4, 2011 9:25:40 AM
> Subject: Re: [TDD] Re: domain object models
>
> This sounds like a good idea to me. How would you (anybody) recommend
> getting
> there from here? Currently we have mostly classes like the first kind of
> Person. I fear gradually switching over to the second style will result in
> a
> royal mashup of classes with both types of interface, and really ugly code.
>
> Perhaps a better approach is to keep the old Person unchanged and make
>
> class NewPerson
>
> {
> private Person p;
> public void DisplayOn(Personable pable);
> }
>
> Yay/nay?
>
> Alan Baljeu
>
> ________________________________
> -----Original Message-----
>
> From:
testdrivendevelopment@yahoogroups.com<testdrivendevelopment%40yahoogroups.com>
>
[mailto:testdrivendevelopment@yahoogroups.com<testdrivendevelopment%40yahoogroup\
s.com>]
> On Behalf Of avinap77
> Sent: 28 December 2010 18:55
> To:
testdrivendevelopment@yahoogroups.com<testdrivendevelopment%40yahoogroups.com>
> Subject: [TDD] Re: domain object models
>
> AFAIK domain models with properties apply mostly to modeling entities,
> wheras
> "tell don't ask" applies to modeling processes and interactions.
>
> For instance, a person migh be modeled like this using properties:
>
> class Person
> {
> string Name;
> int Age;
> Person Soupse;
> Person[] Siblings;
> Person[] Children;
> }
>
> This models the entity itself.
> So The process of displaying a person on a profile page of a website might
> look
> like this:
>
> class ProfilePage
> {
> void Display(Person p)
> {
> this.txtName = p.Name;
> this.txtAge = p.Age.ToString();
> this.txtSpouseName = p.Spouse.Name;
> this.txtNumberOfChildren = p.Children.Length;
> ... etc
> }
> }
>
> So in this type of modeling, the ProfilePage is told to display a person,
> and it
>
> pulls ("asks") relevant info from the person object.
>
> Wheras in "tell don't ask", the person might be told to display itself on
> the
> profilepage, like this:
>
> class Person
> {
> private int _age;
> private string _name;
> private Person _spouse;
> private Person[] _children;
> ... etc;
>
> void DisplayOn(Personable p)
> {
> p.SetAge(_age);
> p.SetName(_name);
> p.SetSpouse(_spouse);
> p.SetChildren(_children);
> ... etc
> }
> }
>
> interface Personable
> {
> void SetAge(int age);
> void SetName(string name);
> void SetSpouse(Person spouse);
> void SetChildren(Person[] children);
> }
>
> class ProfilePage : Personable
> {
> void SetAge(int age)
> {
> this.txtAge = age.ToString();
> }
>
> void SetName(string name)
> {
> this.txtName = name;
> }
>
> void SetSpouse(Person spouse)
> {
> spouse.DisplayOn(this.SpouseWidget);
> }
>
> void SetChildren(Person[] children)
> {
> this.txtNumberOfChildren = children.Length;
> }
>
> }
>
> In fact, the person can be told to display itself on any class that
> implements
> the Personable interface - like a PrintableProfilePage, a PeopleCatalog or
> even
> another Person (for instance if one person needs to introduce him/herself
> to
> another person).
>
> Notice it gets really interesting when applying child-objects, like in the
> Spouse example above. The spouse is DisplayedOn a SpouseWidget, which might
> be
> implemented in several different ways depending on the current display mode
> (it
> might be configured to show only the spouse's name or the entire profile of
> the
> spouse).
>
> Each object hides it's implementation and exposes only "Telling"
> interfaces.
>
> BTW the Person object itself could be an interface, with several different
> types
>
> of people. I can't think of any good reason to do this right now... I think
> the
> classic example for this is with Animals but I've already coughed up the
> example, so you get the idea :)
>
> Personally I sometimes use one approach and sometimes use another.
> **Sometimes**
>
> my tests tell me which approach to use - for instance a system might start
> off
> with a simple Property-based approach and as it gets bigger I'll find
> common
> abstractions and refactor to "tell don't ask".
>
> But all in all the Property approach is usually outgrown when there are too
> many
>
> types of objects and you want to have them cohesively interact with each
> other,
> swapping one type of object for another in a given context.
>
> --- In
testdrivendevelopment@yahoogroups.com<testdrivendevelopment%40yahoogroups.com>,
> Alan Baljeu <alanbaljeu@...>
> wrote:
> >
> > Is there a consensus on the preferred way to design domain object models?
>
> > What's the general attitude towards Microsoft's approach of objects with
> public
> >
> >
> > properties exposing the structure of the domain?
> >
> > It seems like a good approach to me, but talk here about Demeter and
> friends
> > suggests there might be a different better way. People here write about
> "tell,
> >
> >
> > don't ask", etc. I don't understand how that other way works or whether
> it is
>
> > properly applied to domain modeling.
> >
> > Alan Baljeu
> >
>
> ------------------------------------
>
> Yahoo! Groups Links
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

Hi all,
I'm hosting a course in March at 8th Light in Chicago on acceptance testing. 
I'm posting the details here in case anyone is interested in attending.  You can
email me directly for more information.

Thanks,
Doug Bradbury
***************************************************************
What:  How Acceptance Testing Can Help You Make Great Software, a 3-Day Course
in Chicago with Doug Bradbury of 8th Light

When:  March 2-4, 2011.

Where:  8th Light Chicago (566 W Lake Street, Chicago, IL 60661)

Registration and more information:  http://bit.ly/realworldat



[Non-text portions of this message have been removed]