Re: Long Life Objects

Thanks for your continued detailed posts Lahman. The time and effort
is appreciated.

But even if the flavors of Address are more dynamically flexible you
could still do:

[Shipper] [Invoicer]
| 1 |
| |
| R1 | R2
| |
+----- [Customer] -----+
ships to 1 | 1 * bills for
|
| R3
|
| has
| *
[Address]
+ addressType

The Shipper and Invoicer now need to search the R3 set of addresses to
get the right type, but that set will be a whole lot smaller than the
total set of addresses one would need to search to find the right
customer in an AddressType dictionary. IOW, the R3 collection just
optimizes the search scope to the smaller set of individual customer
addresses rather than the larger scope of all addresses of a given type.

As an added bonus, every object is clearly a problem space entity while
the details of collections are abstracted as simple associations that
reflect existing relationships in the problem space. In contrast, in
your solution each Dictionary is a first class object in the OOA/D even
though it doesn't directly represent an entity in the problem space.
[Try talking to the warehouse foreman about AddressType entities. B-)]

Yes, your warehouse foreman statement is a great example of why these
'xxxType' objects do not feel right in my design. I use them when I
need to package data that does not seem to belong in its containing
class. So AddressType might also have a bool attribute 'isDefault'
that can be used, for example, in the GUI to prepare controls. Thus if
an admin user set 'Delivery' to be the default AddressType, any
delivery address created for any customer from that point on would be
their default. Would you suggest that 'isDefault' and any other
similar attributes are redesigned to be attributes of Address and do
away with [AddressType] completely?

.

Relevant Pages

  • Re: Long Life Objects
    ... (Your BillingAddress example below is an example.) ... So if there is exactly one mailing address per Customer or per Contact, one would usually just tuck the attributes like City there. ... my Address object currently contains an AddressType ... every object is clearly a problem space entity while the details of collections are abstracted as simple associations that reflect existing relationships in the problem space. ...
    (comp.object)
  • Re: Long Life Objects
    ... customer in an AddressType dictionary. ... every object is clearly a problem space entity while ... delivery address created for any customer from that point on would be ...
    (comp.object)
  • Re: Long Life Objects
    ... They are virtually all Dictionary objects acting as 'look-ups' for ... AddressTypeID as the Key for a corresponding AddressType object. ... As these dictionaries are used for the lifetime of the application, ... Is this what the problem space looks like? ...
    (comp.object)