The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Seeking circular association object design adv.

I have 3 types, say Customer, Order and Product.

When the user sees the objects from the context of Customers:

The instance customer1 can have a list of  order1, order2 and
order1  can have a list of product11, product12 ...


When the user wants to see the objects from the context of Products:

The instance Product1 can have a list of Order1..Order2 and a list Customer1,Customer 2...

The same repeats when user sees from the context of Orders.

In other words, the objects nest within parents objects depending on the context in which data is queried and displayed.

What is a good way to tackle this? I was thinking of giving each of these objects an enumerable property of the type of other two. And then populate depending on the query context and display if count>0. Is there any specific that I should be looking at while designing this?
Thanks.
Black Adder Send private email
Sunday, April 27, 2008
 
 
Is there any specific design pattern that helps solve this?
Black Adder Send private email
Sunday, April 27, 2008
 
 
How can an instance of Order have more than one Product or Customer?
Q
Sunday, April 27, 2008
 
 
That's a real brain puzzler.

:-/

You might want to get an introductory book on database design and start at page one. The object associations are trivial.
my name is here Send private email
Sunday, April 27, 2008
 
 
I basically agree with "here".

The problem you describe, involving customers, products, and orders,  is a classic one for database design.  If you were asking for a design pattern involving the relational model of data,  I would refer you to many sources, some on the web, that show a good design of exactly that pattern. 

I do not know how to design objects so that they will capture the power and simplicity of relational tables.  Heavy duty object designers and heavy duty database designers seem to generally talk at cross purposes when it comes to subjects like this.  Those discussions are often unproductive.

Perhaps someone who understands both objects and relations will be kind enough to give you a response that can meet your needs.
Walter Mitty Send private email
Monday, April 28, 2008
 
 
Classic "many-to-many" relation situation.

The "classic" solution to this in relational database terms is a couple of "link tables".

One links (by having multiple records) Customer foreign Keys to Order foreign keys.  One links Order foreign keys to Product foreign keys.

And the Structured Programming approach to this is to pick one direction that you'll use most of the time, and implement that.

Usually, you don't care exactly WHO has ordered Gizmo X, you only care how MANY people have ordered Gizmo X.  So usually you don't have a "Gizmo X" to "People who have ordered me" link.  Instead, you 'infer' that by traversing the people records -- or actually maintain a 'count' field for Gizmo's.
AllanL5
Monday, April 28, 2008
 
 
You pretty much have to pick one way or the other and then work around your choice for the other scenario. The common way is to have orders at the top and have customers be subordinate to orders.
uggh
Monday, April 28, 2008
 
 
Agreed.  Usually the 'top level' is the Order.  Each Order then 'has a' Customer (who wants the Order) and 'has-a' one-or-more Products which are being Ordered.
AllanL5
Monday, April 28, 2008
 
 
Thanks everybody.
I am looking for a solution from the OO perspective.
I also cannot choose one object over another and traverse in that direction. Depending on the context , I need to nest one object inside another and so on.
Black Adder Send private email
Monday, April 28, 2008
 
 
I don't understand why you need to "nest" one object inside the other. Isn't that just semantics?
dood mcdoogle
Monday, April 28, 2008
 
 
Re-read my post.  All those "Has-A" relationships mean (in OO speak) that your "Order" object 'has-a' property which is a link to a 'Person' object, and 'has-a' property which is a link to a list of "Product" references.

I suppose each 'Person' object could also 'have-a' property which is a linked list of all the 'Order' objects he's 'Ordered'.

The principle here is "map your OO objects to match reality, because that tends to react better to change".

I'd expect you'd keep a "Person_Index" list of "Person" objects, an "Order_Index" of Orders, and a "Product_List" list of available Products.

Then, depending on what report you wanted, you start at whatever "top level Index" class is appropriate.  And traverse your classes and their properties as needed for your report.
AllanL5
Monday, April 28, 2008
 
 
I think a key part of making this solution work is a careful separation between an INSTANCE of an object, and pointers or references to that object.

So, your Index could hold the INSTANCE of an Order object, and that instance could have properties which held REFERENCES to the appropriate other objects (Person, list of Products).

The actual instances of the other objects would themselves be held in their own Person_Index and Product_Index.

This way, you don't HAVE to store your "Person" instances INSIDE an Order (which is not where they "belong") -- each Order simply implements a reference to the Person entry that ordered it.  And the Person implements a reference to the Orders it has ordered.
AllanL5
Monday, April 28, 2008
 
 
I doubt you really would want to keep all associations in memory. That is, Customer->Orders yes, Orders->Products yes but not Products->Customers nor Products->Orders nor Orders->Customers.

The last three are afterall derivable (don't store what you can derive).

A simple iteration/query would suffice.

I don't really recommend it, but depending on how live the result must be (e.g. how fast it must be shown), you could consider keeping a list (or table) of another instance which holds references to the Customer, Order and Product for each Product in Order of Customer.
Marck Send private email
Thursday, May 01, 2008
 
 
No offense, but isnt this the perfect case of Polymorphism?

I think I know what you are trying to do. You have three types that need to do different things when they are related in different ways. But you want to abstract or simplify these objects, right?

Why cant you abstract the 3 types out as one "generic" type thats derived from interfaces, and which your 3 types derive? Because all the types now share a parent type, they can transform themselves and return data based on shared members and types.
Ranger Send private email
Thursday, May 15, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz