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.

Design pattern suggestion needed...

Hello All,
I am looking for an Design Pattern or Architectural design for the following (common) situation.

A Program that displays various 'Architectural Materials'(Paints, Wallcoverings, Carpet)

Each material has a few common properties (name, manufacturer, price etc)
Each 'subtype' has specific props (Paint=coverage & finish, Carpet=fiber & size)

What is the best way to deal with this in Objects, Database & GUI?

For Objects I could use a Decorator Pattern to make Paintable(material) or Wallcoverable(material)
Is that the best way to look at this?

For the db should I have a main Materials table then various PaintProps Table, CarpetProps table etc. (Rather then a Paints, Carpet table separately )

For the GUI I probably need a separate display form for each type of material (Paint, Carpet, Wallcovering) Is there a trick I need to know.

All input is greatly appreciated.
Thanks in advance
chris murray Send private email
Thursday, December 21, 2006
Personally, whenever I have to decide between paint colours, wallcoverings, and carpets I always use the Decorator Pattern.

Once the selections are made, I'm usually lazy enough to pay someone else to do the work, and I sit in the corner utilizing the Observer Pattern.
Thursday, December 21, 2006
Ok, *that* was funny!

Seriously, though, you're trying to balance structure vs. flexibility, and you do so based on an understanding of the objects in your system.

Object design - look at hierarchy and interfaces.  Chances are, you're going to find a pretty deep hierarchy if you let yourself do so.  "Badger Red" derives from "Sports Colors" derives from "Premium Interior" derives from "Interior" derives from "Latex Paint" derives from "Paint" derives from "Wall Coverings", etc.  Find the places in this hierarchy where there are really meaningful differences from object to parent in terms of the attributes possessed by that object.  Every single one of these objects, for instance, has a "color", but only "Sports Colors" have a sports team name associated with them.

Interfaces are found by understanding the interactions you need to have with your objects.  Use these to support polymorphic behavior, so that you can take a collection of objects and accomplish a task across these objects without knowing about differences in objects that are outside the scope of your interface.  An accounting or pricing interface, for instance, would be interested in price, quantity, SKU, and maybe description, right?

Database design needs to balance normalize data structures within reason.  If you're lucky (or good), you'll have natural alignment with your objects -- "Paints" for instance, probably all have enough in common with one another that you can put them in the same table, while "Floor Coverings" may end up in another one.  You'll have to make some decisions here based on common attributes.

Finally, if you have some "special" attributes (like "sports team name" above), you can either set those up as sparse columns in your database, or normalize them into a key-value type of table.  Either is an acceptable approach .  The key value approach is very flexible, but you've got to deal with extra joins and possibly some late-bound object values.

For GUI design, I'd look at whether there are places you can employ an interface principle to the UI -- for example, if you have a spot where you need to list materials, using a repeating section where each material displays the attributes that are interesting about itself rather than trying to force all materials into a grid with fixed attributes may give you more UI flexibility.
D. Lambert Send private email
Thursday, December 21, 2006
"'Paints' for instance, probably all have enough in common with one another that you can put them in the same table, while 'Floor Coverings' may end up in another one."

From practical experience, having a seperate table for each general category is the least painful way of actually building the database. This need for flexibility is one of the few known circumstances where you don't want to use 3rd Normal Form.

Consider it from this perspective - the ideal mechanism for storing a varying number of attributes in one location is actually a spreadsheet because you can color code cells (overlay additional meanings) or hide and show rows and columns based on the data in other rows, columns and cells. In this example, if we're talking carpet, we want to show attributes color, plush and stain resistance.If we're talking hardware floors, we want to show attributes color, hardness and assembly method.  If we're talking paint, we're concerned with color, texture and drying time.

It is possible to create one table and "null" the appropriate fields; carpet would have null values for hardness and assembly method. The business logic layer however has to do more work to determine which columns are relevant.

If you can break them up into seperate tables, you can write simple select all, and insert all style queries.
Thursday, December 21, 2006
+1 D. Lambert.

Don't go too crazy coming up with hierarchies.  Per GoF - favor composition over inheritance.

Colors can just be an attribute.  Material can be a base class & you can have Paint/Carpet/etc deriving off of it, but coming up with WallCoverable interface is probably overkill... if you do so, you might have to come up with RoofCoverable, CarCoverable, and any sort of Coverables that you can think of. 

I don't think Decorator pattern is going to gain you much.  It allows you to add behaviors to existing classes, which isn't really what you need.  What you are looking for is a composite pattern called MVC that will help you separate your UI from actual "biz objects".

Honestly, there are so many ways to do this that would work.  You can just start doing it and then apply refactoring to get it work better as you add more classes.

The biggest problem with these type of classes is data storage.  If you have a live database, then the conversion effort must be taken into account.  Given data is generally the only thing that would be persisted across versions, it's better to focus the consideration on data modeling instead of object design patterns.
Yin-So Chen Send private email
Sunday, December 24, 2006

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

Other recent topics Other recent topics
Powered by FogBugz