OO Design Confusion

monsi posted on Thursday, October 11, 2007

Hi all,

I'm just starting converting/improving a program I wrote a few years ago in vb6 to csla using proper OO design but there are a couple of areas that I'm not sure about.

The application is a simple mrp like system for our company, and the section I'm struggling with is implementing a partlist for a product. A product is made up of many parts, but these parts are comprised of brought in components, machined components, and sub assemblies (which have there own parts list) my idea is to have a editable root part which is then subtyped into brought out components, machined components and sub-assemblies.

Does this sound like the correct way to go? This is my first large OO design and I want to make sure its right.

Thanks

JonStonecash replied on Thursday, October 11, 2007

The most important question that you want to work through is what the application needs to do with this data.  It is likely that there will be several different uses of the data.  It may well be that each separate use of the data will needed a separate "view" of the data.  Let me take two very different views of the data.

First, there is the obvious, given thing X, what other things do I need to create an instance of thing X.  You could build the entire hierarchy or you could simply build a flattened list of the piece parts.  If it were important for the particular use case to know how things "nested within" other things, the hierarchy is the way to go.  If all you are interested in is ordering the parts or picking them from inventory, the flattened list would be the way to go.  Note that you might have both use cases; in that case you might end up building two separate sets of objects to support the two use cases.

Second, given thing Y, give me a list of the other things that use thing Y.  Again, I could build a hierarchically oriented list showing the relationships: thing Q uses thing R that uses thing S that uses thing X.  Or I could simply create a list of the other things without regard to the "distance" from thing X. 

It is possible that you might be able to share the same classes in each of these situations, but you should not assume that you can.  The data values that you need to store for each "thing" in each of these situations is almost certainly going to be different.  You do not want to create a single Thing class that gets used in all of the situations.  For example, the database row for each thing might have a number of columns that contain detailed specifications for the thing or even an embedded image of the thing.  You probably would not want to read thespecifications or the image data in to generate a simple warehouse pick-list of things needed to build a thing.

The really big "ah ha" moment is when you realize that the structure of the data on the database and the structure of the data in objects need not be the same. 

Jon

jeff replied on Thursday, October 11, 2007

Check out this thread http://forums.lhotka.net/forums/thread/11923.aspx

IMO, avoid these types of heirarchies if you can, especially in a business model. For it to be worth the trouble and to come out clean there would need to be a decent amount of truly common behavior which is rarely the case in a business model in my experience. Especially with a low number of preknown types. Just have them implement a common interface if you need  to deal with them generically. Otherwise you'll spend more time designing and refining the inheritance chain when you could have just made the 3 classes and an interface and gotten back to work.

monsi replied on Friday, October 12, 2007

Hi thanks for your replys,

After having a read through the post you linked to does this sound like a better solution

3 root objects (Brought in Component, Machined Component, and Finished Item) which all have the interface IPart

IPart will expose part number, revision, etc and also a collection of IPart objects

So..

Finished Item (Root) -> IParts Collection  -> Brought In Component
                                                                 -> Machined Component
                                                                 -> Machined Component