Determining classes.

[tyroTechie]

I have been assigned to develop an application for a roll maintenace shop in a hot rolling mill.

THE PROCESS:
ROLLS are used for rolling of hot slabs into coils, plates etc. Certain roll attributes are significant for the rolling process, such as
- Material
- Diameter
- Roughness
- Hardness
- Cylindricity
- Taper

They also have some commercial attributes like
- Manufacturer
- Purchase order number
- Date of Purchase
- Date of Receipt

Apart from these inherent attributes, as a result of rolling, they gain the following attributes which are important for analysis like
- Rolled length
- Rolled tonnage

Also, when maintenance tasks for these rolls are performed, it becomes important to record the timestamp and other attributes of such tasks.
- Inspection date
- Inspection operator
- Grinding date
- Grinding operator

THE PROBLEM:
Should all these attributes be clubbed together in one class for rolls eg. CRoll? If you think otherwise, please suggest on what lines should the classes be bifurcated so as to achieve a good object oriented design.?

Thanks in advance.

[Ezzaral]

The attibutes inherent to the roll should go into CRoll. Maintenance tasks should go into separate classes such that collections of these tasks can be related to (or owned by) a CRoll instance. Maintenance tasks may be able to share an interface if you can find common ground between them, such as the info on Inspection and Grinding.

[tyroTechie]

Thanks Ezzaral. That was really enlightening.

I was thinking if similarly, the commercial attributes can be moved to a class representing the "transaction". But still I am not very confident on it. Please comment.

Thanks again for the help.

[thekashyap]

What Ezzaral said is true that " The attibutes inherent to the roll should go into CRoll", but IMO in the given list there are no such attrs. All attrs are specific to different usecases.

An inherent attr would be something like a serial number (if there is such a thing for rolls), which is independent of usecase. In most cases the attr that identifies an object uniquely (e.g. name for CStudent, account number for CBankAccount, passport number for CDomesticPassport...) is the best example of such an attr.

Your CRoll class could/should have only the inherent attrs are members. Other attributes (rolling-process related, commercial, maintenance related etc) could be grouped in separate structures. E.g. CRollProcAttrGroup, CCommAttrGroup, CMaintAttrGroup.. (if you're using C/C++ these could be structures instead of classes).

Association/relation between CRoll and these AttrGroup could be done in many ways:
1. Inheritance. Not really correct as there is no "is a" relation between an AttrGroup and CRoll.
2. Containment/Aggregation: CRoll could have member variable(s) of type XXXAttrGroup. Given that one obj of CRoll in one usecase doesn't really need to have all AttrGroups, a space efficient solution would be to derive all XXXAttrGroup classes/structs from a BaseAttrGroup class/struct, and have a member variable of this type (BaseAttrGroup) in CRoll.
3. Leave it to client to keep teh association. :). Possible if it's okay from requirement point of view.