Class design - a large heirarchy chain; How to?

Pawz posted on Tuesday, April 01, 2008

I've got a situation here I'm not really sure what would be a good way to design a proper set of classes around.

I've got a whole chain of 1:Many relationships:

ProductLine
ProductItem
Finish
Thickness
FasciaDetail
Sheet

Each successive table has a link to the previous via an ID (So, Each product line has many ProductItems, each Item has many finishes, each finish has many thicknesses, etc down the line).

Each one *must* have a parent ID filled in, but apart from that they don't depend on each other for validation.

What I'm stumped with is whether I should have a huge object with a successive chain all the way down to Sheet, or if I should break it down so each table has its own business object, and each business object just worries about its direct descendants. Actually, overall I'm just not really sure what to do!

ajj3085 replied on Tuesday, April 01, 2008

You don't design objects based on the data they will hold; design them based on use cases. So you need to figure out all the different ways a user will interact with your application, and design an object or set of objects for each case.  Finish, Thinkness and maybe FasciaDetail sound like they all describe a part of the product so it could be that they end up being properties of a product class.

JoeFallon1 replied on Tuesday, April 01, 2008

It may help to consider each screen in your app as a Use Case.

So if you have 1 gigantic screen where the user can edit everything then you should probably have 1 gigantic BO.

But hopefully you break down the screens into smaller pieces. In that case you should have a series of smaller BOs to handle the requirements for each screen.

Joe

 

Pawz replied on Wednesday, April 02, 2008

Thanks guys - that looks like its pretty much the way to go. Still having a hard time getting away from my database driven design philosophies of the past! .. and learning application development from start to finish on the way.

With the problem at hand, it is meant for one very large screen full of data, but I'm working on breaking it down into user controls that handle the data for each section.