Re: Long Life Objects

Responding to Timeisfire8...

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?

I want to get rid of [AddressType] as a first class object and use a model closer to the problem space structure like that above. I think one can do that for the DB caching problem. But managing defaults for the UI is a different problem than caching the DB. So the question is: can one deal with defaults using the model above?

To do that one needs to define what one wants to accomplish with defaults. For example, I am not sure what you mean by the notion of a default address type for 'delivery'. Does that mean the Address has a different format? Probably not. I suspect you mean that the "delivery" address will default to a specific flavor of address type (billing, shipping, etc.). What I have a hard time getting my mind around is why "delivery" isn't already one of those types (e.g., ShippingAddress).

So before I can speculate on an answer you are going to have to put some more words around what you want to do with defaults.


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

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

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
    ... Thanks for your continued detailed posts Lahman. ... customer in an AddressType dictionary. ... every object is clearly a problem space entity while ...
    (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)
  • Re: Long Life Objects
    ... Fowler's enterprise patterns are ... User loads the application for the first time and no address types ... 'Delivery 2'. ... 'isDefault' attribute of AddressType as it currently stands. ...
    (comp.object)