[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: The problem of History Objects
>
> I would use the following design:
>
>
> __________ ____________________ _______________
> | | 1...1 |HomeAddressManager| 1...*| |
> | Person |--------------- | |--------|HomeAddress |
> | | | | | |
> ---------- -------------------- ---------------
> |
> |
> |1...1
> ______________
> | |
> | TimePeriod |
> | |
> --------------
>
> It is HomeAddressManager's responsibility to define, and maintain the
> relationship between Person and HomeAddress. To do that, HomeAddressManager
> provides the following services:
>
> HomeAddress getFirstValidAddress();
> HomeAddress getNextValidAddress();
>
> This couple of services allows the client to retrieve all available valid
> addresses of a Person. In you case, you might want to make a class deriving
> from HomeAddressManager, named, say, HomeAddressManager1, to implement the
> constraint that one Person can have only one current address.
> HomeAddressManager1 provides a service called
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).
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 |
| |
--------------
> HomeAddress getCurrentAddress();
> And overloads getFirstValidAddress() to use the return value
> getCurrentAddress(), and getNextValidAddress() to simply return null.
>
> Jing
> -----
> Jing Xue
> * Let's work the problem, people! Let's not make things worse by guessing.
> * -- Gene Kranz, "Apollo 13"
>
> >
> > __________ __________________ _______________
> > | | 1...* |HomeAddressTimer | 1...1| |
> > | Person |--------------- | |--------|HomeAddress |
> > | | | | | |
> > ---------- ------------------| ---------------
> > | |
> > | |
> > |1...1 |1...1
> > ______________ _____________
> > | | | |
> > | TimePeriod | | Valid |
> > | | | |
> > -------------- -------------
> >
>
>
To unsubscribe send a note to majordomo@cs.fiu.edu with the body of the message
being: unsubscribe cadse-orb