Prev: OO and Extending (Was: Is Procedural Paradigm a basis of OO Paradigm?)
Next: Applications of sequence diagrams
From: timeisfire8 on 26 Mar 2007 11:30
Hi all
Any help with this would be appreciated as I am going round in circles
as a relative newcomer to OO...

The problem lies with the creation of my design's long life objects.
They are virtually all Dictionary objects acting as 'look-ups' for
various 'type' data. For example, I have one for AddressType with
AddressTypeID as the Key for a corresponding AddressType object. An
AddressType object is contained as an attribute of an Address object.
As these dictionaries are used for the lifetime of the application, I
have decided to create them all at application start-up.

An extract of my start-up object creation is as follows (---
represents 'creates & contains'):

PlaceOrderHandler --- Company --- Dictionary<Customer> ---
Dictionary<Address>

--- Dictionary<Contact>
--- ServiceCatalogue
--- Dictionary<ServiceType>

Please note that Company is a single instance and represents the
organisation running the application.

Fine so far but the problem comes when trying to assign responsibility
for the creation and containment of Dictionary<AddressType>. I do not
wish to increase the coupling of Company by creating and containing it
there as it is supposed to be a lightweight start-up object and will
end up with many Dictionaries for classes throughout the model.

Dictionary<ServiceType> works nicely as it maintains a low
representational gap and allows code such as
serviceCatalogue.GetServiceByID(779). Conversely
company.GetAddressTypeByID(4) just seems like a poor object
responsibility choice.

I have thought about introducing a new 'Pure Fabrication' class
perhaps called something like 'SystemTypes' and assigning that
responsibility for all 'lookups' but I can't help thinking that is a
bit of a workaround. The code in this case would be something like
systemTypes.GetAddressTypeByID(4) or
systemTypes.GetDepartmentTypeByID(2).

How do you handle long life lookups that can't be contained in a
manner that obeys OO principles? Am I on completely the wrong track?

Thanks for reading this.

From: timeisfire8 on 26 Mar 2007 11:41

Oops, formatting messed up my start-up diagram so:

PlaceOrderHandler --- Company --- Dictionary<Customer>

Customer --- Dictionary<Address>
--- Dictionary<Contact>

Company --- ServiceCatalogue
ServiceCatalogue --- Dictionary<ServiceType>

From: H. S. Lahman on 27 Mar 2007 12:21
Responding to Timeisfire8...

> The problem lies with the creation of my design's long life objects.
> They are virtually all Dictionary objects acting as 'look-ups' for
> various 'type' data. For example, I have one for AddressType with
> AddressTypeID as the Key for a corresponding AddressType object. An
> AddressType object is contained as an attribute of an Address object.
> As these dictionaries are used for the lifetime of the application, I
> have decided to create them all at application start-up.
>
> An extract of my start-up object creation is as follows (---
> represents 'creates & contains'):
>
> PlaceOrderHandler --- Company --- Dictionary<Customer> ---
> Dictionary<Address>
>
> --- Dictionary<Contact>
> --- ServiceCatalogue
> --- Dictionary<ServiceType>
>
> Please note that Company is a single instance and represents the
> organisation running the application.

I am getting hung up on the terminology here (e.g., "Dictionary"). It
sounds very much like you are trying to emulate an RDB and the
Dictionaries are just surrogates for table indices. If so, that is not a
very OO way of doing things. So let's go back to basics.

What problem is the application trying to solve?

Is this what the problem space looks like?

1
[Company] ----------------------+
| 1 |
| |
| R1 | R4
| |
| has | references
| * | 1
[Customer] [ServiceCatalogue]
+ customerID | 1
| 1 |
| |
| R2 | R5
| |
| has | organizes
| 1 | *
[ContactInfo] [Service]
+ phoneNumber + serviceID
+ eMailAddress
| 1
|
| R3
|
| includes
| 1
[Address]
+ street
+ city
+ state



*************
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
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info(a)pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



From: timeisfire8 on 27 Mar 2007 16:45
Hi Lahman
Thanks for responding. I enjoy reading your posts and understand at
least 9% of them with my current knowledge :-)

> What problem is the application trying to solve?

It is a warehouse application that includes a basic contact management
element. One Use Case extract might be "A Customer Contact phones the
Company to order a next day delivery Service for a stored pallet of
goods."


> I am getting hung up on the terminology here (e.g., "Dictionary"). It
> sounds very much like you are trying to emulate an RDB and the
> Dictionaries are just surrogates for table indices.

So I am. One of your other posts taught me the valuable lesson of
solving the problem without considering RDB persistence, which should
be handled in isolation. Before this I would drive the design from the
database and I now see how this is a poor approach. I suppose that the
reason I have unwittingly created an application RDB is because my
thought process for the implementation of the Use Case above, for
example, is:

1) I will need the Customer, Contact and Service(next day delivery)
objects for this problem.
2) All entities are persisted in my RDB using a surrogate key of type
int which is also used as the materialised entity's ID, i.e.
CustomerID = 87.
3) These entities are rarely updated but frequently read so I will
place them all into a Domain layer Dictionary at application start-up
using the ID for the key, i.e Dictionary<87, customer>.
4) I can now contain these Dictionaries in the application's start-up
object (Company) without hitting the RDB until a change is notified in
some way at which point I can refresh.


> Is this what the problem space looks like?
>
> 1
> [Company] ----------------------+
> | 1 |
> | |
> | R1 | R4
> | |
> | has | references
> | * | 1
> [Customer] [ServiceCatalogue]
> + customerID | 1
> | 1 |
> | |
> | R2 | R5
> | |
> | has | organizes
> | 1 | *
> [ContactInfo] [Service]
> + phoneNumber + serviceID
> + eMailAddress
> | 1
> |
> | R3
> |
> | includes
> | 1
> [Address]
> + street
> + city
> + state
>

Almost. Each Customer has many Contacts which are physical people.
Each Customer has many Addresses. A contact belongs to one Address.
ServiceCatalogue is spot on.

1
[Company] ----------------------+
| 1 |
| |
| R1 | R4
| |
| has | references
| * | 1
[Customer] [ServiceCatalogue]
+ customerID | 1
| 1 |
| |
| R2 | R5
| |
| has | organizes
| * | *
[Contact] [Service]
+ phoneNumber + serviceID
+ eMailAddress



From: topmind on 27 Mar 2007 18:17
On Mar 27, 1:45 pm, timeisfi...(a)hotmail.com wrote:
> Hi Lahman
> Thanks for responding. I enjoy reading your posts and understand at
> least 9% of them with my current knowledge :-)
>
> > What problem is the application trying to solve?
>
> It is a warehouse application that includes a basic contact management
> element. One Use Case extract might be "A Customer Contact phones the
> Company to order a next day delivery Service for a stored pallet of
> goods."
>
> > I am getting hung up on the terminology here (e.g., "Dictionary"). It
> > sounds very much like you are trying to emulate an RDB and the
> > Dictionaries are just surrogates for table indices.
>
> So I am. One of your other posts taught me the valuable lesson of
> solving the problem without considering RDB persistence, which should
> be handled in isolation.


Well, you have been taught bullsh8t from excessive OOP zealots. And
RDB's are not just about "persistence". They standardize and package
common attribute-management and collection-oriented idioms, AKA
"reuse".


> Before this I would drive the design from the
> database and I now see how this is a poor approach. I suppose that the
> reason I have unwittingly created an application RDB is because my
> thought process for the implementation of the Use Case above, for
> example, is:

[snip]

>

-T-
oop.ismad.com

 |  Next  |  Last
Pages: 1 2 3 4
Prev: OO and Extending (Was: Is Procedural Paradigm a basis of OO Paradigm?)
Next: Applications of sequence diagrams