Re: A Question about Domain Object

Responding to Narke...

A definition (http://c2.com/cgi/wiki?DomainObject) about Domain Object
says domain objects should know how to  recognize which [of their]
references indicate aggregation and which ones indicate association.

I don't like that definition. It implies that the implementation of the object has a knowledge of context. Objects should abstract /intrinsic/ properties from the problem space entity that do not depend on the context. (One selects the properties to abstract based upon the needs of the problem in hand, but that is quite different than the object implementation knowing about its context.)

Generally relationships are implemented orthogonally to class semantics. (In fill code generators for OOA models the relationship implementation is code is very aspect-like in that it cross-cuts classes in a generic fashion.) So...


This definition leads me to think following questions:

1, How to understand the statement?

2, What is the real difference between aggregation and association?

Aggregation is an ordinary association that has special additional semantics. That semantics is that there is a Whole/Part relationship between the objects. That Whole/Part semantics implies that the life cycles of the objects are somehow tied together (e.g., the Part object might not conceptually exist without the Whole object being instantiated). That imparts a constraint on referential integrity that must be enforced during OOP is some fashion.

The most common way to enforce such a constraint is to embed the Part object in the Whole implementation. That ensures that the Part ceases to exist when the Whole ceases to exist. [There are other alternatives, depending upon the particular notion of Whole/Part means vis a vis referential integrity in the problem space.]

Thus an example in UML and C++:

        1            1
[Whole] -------------- [Part]   // simple association.

class Whole
{
private:
   Part* myPart;    // implement association
   ...
public:
   Whole (Part* p) {myPart = p;}  // instantiate association
   ...
   void doIt(){... mypart->doSomething();...}  // navigate
   ..
}
        1             1
[Whole] <>------------- [Part]  // aggregation.

        1             1
[Whole] <*>------------ [Part]  // composition.

class Whole
{
   Part myPart;     // implement & instantiate aggregation
   ...
public:
   Whole();
   ...
   void doIt(){... myPart.doSomething();...}  // navigate
   ...
}

[Alas, the semantics of aggregation in UML is "soft" in that it does not explicitly define a life cycle constraint. (The Composition association in UML does.) So as a practical matter there is virtually no difference between Aggregation and simple Association in UML (i.e., it has not direct affect on the way one implements during OOP). In effect, it just documents what the developer was thinking when constructing the model. To that extent my example of C++ aggregation is misleading. That would really only be a common implementation of Composition and the aggregation would usually be indistinguishable from simple association during OOP.]



Further, if a class A has a method which take another class B as its
parameter, in the case, does A gets an association with B? If this
method happens to be a contructor of A, does A gets an aggregation with
B in this case?

There are three different aspects to relationships: implementation, where one defines the mechanics; instantiation, where one defines the actual participation of objects; and navigation, where one uses the association to address collaboration messages to the right object.

Any time A and B collaborate, there is some sort of association between them. Thus A needs to navigate some relationship path to get to the right B to send a message. How that path is implemented and instantiated depends upon the context.

Basically there are three ways to implement an association. One can use a search of instances based on an explicit object identity (usually via a static Find method in the target class). This is the standard RDB approach but it is very rarely used in OO applications because the alternatives are usually much more efficient.

The second way to implement is via a reference. That was the approach used in my simple association example above. This is the most common form for implementation in OO applications. One reason is that one can easily "daisy-chain" relationship paths by "walking" a chain of references to get to the right object. If each relationship in the path enforces some business rule on participation, this is a very effective way to incorporate business rules so that collaborations always get to the right object. It also allows the rules for participation to be encapsulated in one place that is independent of the context of detailed collaborations.

The last way to implement is by passing an object reference in a messages (e.g., as an argument in a method call). This effectively implements, instantiates, and navigates an temporary association for only the duration of the message. Generally this is not a good idea precisely because of that multiple responsibilities. That is, the client sending the message must understand the ephemeral nature of the relationship (it is temporary), the context of collaboration (when the message must be sent) and the context of participation (who the message should go to). The application will usually be more robust if one separates those concerns in different objects.

So the answer to your first question is Yes, there is an association between them.

The second question inspires me to push back with: Why do you want to pass a constructor at all? I will bet that for any problem context you cite, I can provide an alternative that will not involve doing that. B-)


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: Table bloat in Linq-SQL
    ... I think this is done to be able to create queries at runtime properly ... table references). ... You need to create the context, but the context wouldn't need to ... actually instantiate anything else before any queries are executed. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Bipedal Orrorin?
    ... >> actual context shows otherwise. ... > of my statements to specific references as I can; ... Apes are more bipedal in any depth of water than they are ... Her number TWO reason for bipedality in chimps was moving on ...
    (sci.anthropology.paleo)
  • Re: When A Have a Collections of Bs -- a Design Question
    ... Robert C. Martin wrote: ... >>class Product { ... > *might* be aggregation, or it might just be association. ... Product.removePartmethod release all the references to the part and ...
    (comp.object)
  • Re: Christmas, but not a Merry-Christmasy, coincidence.
    ... footnote of a paper presented at an academic conference. ... discussant noted the 'wide range' of references in the paper.... ... what context you found for it?...r ... reflecting on included actions of the Anton Piller type (ex parte ...
    (alt.usage.english)
  • Re: Christmas, but not a Merry-Christmasy, coincidence.
    ... footnote of a paper presented at an academic conference. ... discussant noted the 'wide range' of references in the paper.... ... what context you found for it?...r ... reflecting on included actions of the Anton Piller type (ex parte ...
    (alt.usage.english)
Loading