Prev: Polymorphism sucks [Was: Paradigms which way to go?]
Next: Object, thing, creature, and methods...???
From: srini on 18 Jun 2005 02:36
Hi

How can I identify the Association class while designing classes?. How
they are different from actual classes.

Thanks
Srinivas Ivaturi.

From: Phlip on 18 Jun 2005 08:58
srini wrote:

> How can I identify the Association class while designing classes?. How
> they are different from actual classes.

What happens if you get this wrong?

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand


From: H. S. Lahman on 18 Jun 2005 14:14
Responding to Srini...

> How can I identify the Association class while designing classes?. How
> they are different from actual classes.

Most of the time an Association class is just a placeholder that
abstracts the complexity of managing participation in a *:*
relationship. Generally one identifies Association classes with names
that describe something about the relationship itself:

[Registration]
+ StudentID
+ CourseName
|
|
* | *
[Student] --------------- [Course]
+ StudentID + CourseName

Here the [Registration] is a placeholder and the only relevant
properties are the identities of the participants. Usually one looks
for some concept in the problem space that characterizes the
relationship, even if it isn't directly related to the problem in hand
(i.e., the entity has no intrinsic properties that one needs to solve
the problem).

It may sometimes be helpful to think of the sort of practical OOP
reification one might have for the *:* relationship in terms of two 1:*
relationships:

* 1 1 *
[Student] --------------- [CourseRegistration] --------------- [Course]

A common mode of implementation for the *:* is for each participant to
have its own collection of its related participants. When one views it
this way, the notion of CourseRegistration seems like a clearer
description of what is going on, so one might name the Association class
that way for the *:* relationship (rather than simply Registration).

Of course there are situations where the Association object may also
abstract a real problem space entity with unique properties:

[Ticket]
+ TicketNumber
+ Date
|
|
* | 1
[Person] ------------------ [Movie]
+ PersonName + MovieName

In this context the identities of the participants are irrelevant and
[Ticket] has its own unique responsibilities. But one regards it as an
Association object because it is intimately related to the relationship
rather than exclusively to either participant. In this case one
identities the object based on the underlying problem space entity.
This sort of thing is normal when one is providing an Association class
for a relationship that is not inherently *:*, as in this case.


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

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



From: Robert C. Martin on 19 Jun 2005 08:37
On 17 Jun 2005 23:36:00 -0700, "srini" <srinivas.ivaturi(a)gmail.com>
wrote:

>Hi
>
>How can I identify the Association class while designing classes?. How
>they are different from actual classes.

Association classes *are* regular classes. They are used to
encapsulate or represent a relationship.

For example, we may have an Employer class, and an Employee class.
The relationship between them is defined by an EmploymentContract.


|Employer|---------->|Employee|
: *
:
|EmploymentContract|

This can be implemented in a variety of different ways.

1. You could have a table of EmploymentContract items that is keyed by
the Employee.

2. Every Employer instance contains a list of EmploymentContract
instances, each of which holds a reference to it's Employee.

|Employer|----->|EmploymentContract|------>|Employee|
*

3. Every Employer instance contains a list of Employee instances, each
of which hold a reference to the corresponding EmployeeContract.

|Employer|----->|Employee|------>|EmploymentContract|
*

4. You can probably think of many others.

The point is that an association class is really just a regular class
that manages a relationship.




-----
Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
From: Rebecca Wirfs-Brock on 19 Jun 2005 19:14


Robert C. Martin wrote:
> On 17 Jun 2005 23:36:00 -0700, "srini" <srinivas.ivaturi(a)gmail.com>
> wrote:
>
> >Hi
> >
> >How can I identify the Association class while designing classes?. How
> >they are different from actual classes.
>
> Association classes *are* regular classes. They are used to
> encapsulate or represent a relationship.
>

And the real question to ask yourself is this: when do you want to have
an association class instead of just having one or the other (or both)
objects know about the relationship? That is the hard decision to make.
If a person has dogs, pets, cars, etc.,etc., etc., show the person
object itself know about all these things? If you do create a design
this way, then you eventually end up with a bloated object. On the
otherhand, it is all too easy to slip in one relationship management
behavior into an object (ah, I won't create a dog-owner relationship
because I'll just have the person object keep track of the dogs he/she
owns)...this can lead you down a slippery slope to too many
relationship having to be managed by objects. (I once saw a Youth
object that had 500 attributes...a very difficult implementation to
maintain). So, if you can answer the question: "is this relationship
intrinsic to the behavior of that object" in the affirmative, then you
might want to consider modeling it in the class itself. But, if you
cannot answer that in the affirmative, then consider creating an
"association class" that structures the relationship (and has
responsibilities for knowing things about that relationship) and have
it know about the person and the dog, and when the purchase of the dog
was made, etc.

Rebecca

 |  Next  |  Last
Pages: 1 2
Prev: Polymorphism sucks [Was: Paradigms which way to go?]
Next: Object, thing, creature, and methods...???