RE: The problem of History Objects

["Jing Xue" <jxue01@cs.fiu.edu>]

>
> Well, the point is that the only difference between currentAddress and
> oldAddress is that you can have only one currentAddress and many
> oldAddresses. The difference lies in cardinality, not in behavior. Hence
> subclasssing Manager for currentAddress introduces a new class for the
> same behavior. In fact the iteration behavior is beign forced onto
> Manager1 though it does not belong there (though your suggestion of
> returning NULL is workable).

But cardinality should be reflected in behavior.  Actually if you go a
little bit lower in your design level, you will find you need to define the
interface of your classes to satisfy the cardinality constraints.

I don't feel that the iteration behavior is _forced_ onto Manager1, because
it just fits in.  The iteration behavior defined by the base class, or more
accurately, the interface, specifies a general cardinality of 1..m, which
does not excludes 1..1.  The key point here is that, Manager1 doe not
_redefine_ the interface, it just tries to have its own explain on the
behavior, of course without violating the interface contract.  I suppose
that is a general technique when doing OO design.

Your following model works well too, I believe.  Actually your Placement is
pretty close to my Manager1.

Jing
-----
Jing Xue
* #define QUESTION ((bb) || !(bb))
*                     -- William Shakespeare
*                            (Oops, should be "Bill Gatespeare")

>
> Consider the following model.....
> A Person has a one-to-many relationship with Placement(or Timer or
> Manager), which is actually a Collection of references and a one-to-one
> relationship with Timer called currentAddress. The cardinality
> is taken care of, alright. The constraint (there be only one
> currentAddress) is satisfied in the model. And the timeperiod is
> available too.
>
> As an aside, HomeAddress itself could have the TimePeriod, except that
> this HomeAddress object is not re-usable in models that do not care for
> the temporal aspect of Addresses. Besides, timeperiod is not a natural
> aspect of HomeAddress.
>
>
>  __________ 1 oldAddress m ___________________        ______________
>  |        |--------------- |Placement        |1      1|             |
>  | Person |                |                 |--------|HomeAddress  |
>  |        |----------------|                 |        |             |
>  ----------1 currentAddr 1 -------------------        ---------------
>                              |
>                              |
>                              |1...1
>                          ______________
>                          |            |
>                          | TimePeriod |
>                          |            |
>                          --------------
>

To unsubscribe send a note to majordomo@cs.fiu.edu with the body of the message
being: unsubscribe cadse-orb