problem with arranging the objects

[aagnezz]

Hello everyone
I have a question that maybe seems to be silly, but I'm trying to figure out the best solution for some time and need some help.

I am making a small web application for clothing company (it's my first independent project). It is supposed to handle info about how the products are designed (lengths, fabric, buttons and so on).
There is a need to define the sizes for every product as well as the attributes the product has, and then specify the values for each combination(ex: sleeve length for size S: 40 cm, and so on...).
So the attribute - like sleeve length - depends on the size and I'm not sure how to arrange the classes in order to correctly explain the relation: product-size-attribute.
1. should the product aggregate the size and size should aggregate attribute?
2. or maybe product should aggregate both size and attribute and then maybe I'll need one more object which will depend both on size and attribute?

Am I somewhere close to the good solution? :/
Please help

 

[stevexff]

I don't think the sleeve length depends on the size, it is independent. For example if I eat too much and have to go up to the next trouser size, I don't suddenly find that my legs have got longer. You probably need size to be an attribute (property) as well. You can probably get away with a few generic classes like Shirt, Trouser, Jacket, Skirt, Dress. And a Suit could be a composite containing a Jacket and a Trouser.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[aagnezz]

Thanks Steve

Well the thing is that the sleeve length, as well as the waist girth they are 2 out of many attributes which values differer from XS to XXXL sizes. It's like a table where rows represent attributes and columns represent sizes, and for every next cell the value changes.

 

[BobRodes]

Ok. I'm seeing this. You have a group of products, some of which are composed of other products. Each product has a size. The size is a combination of dimensions, which vary from product to product.

I'd say you need the following classes:

Product
Size
Dimension

Among other attributes, a Product class will have one and only one association with a Size class. It will also have zero or more composition associations with itself. A Size class will have a Name (40L, for example), and also an aggregate association with one or more Dimension classes. A dimension class will have a name (Sleeve, for example) and a value, perhaps one in cm and one in inches.

Based on this assessment, neither of your postulates are quite on the money. Product should have one size, but the size is indeed an aggregate of various dimensions. Also, the concept of attribute needs to be kept separate from this process as a more generic term. So, size is indeed an attribute of product, but then so are, say, material, color, name, style, and the like. Furthermore, name and dimension(s) are attributes of size, and perhaps name and value for dimension.

You might want to have a look at UML Class diagrams to model this out. They're not difficult to use and can help you crystallize your thinking about your class model.

HTH

Bob