Subclassing or Defining Types

Another area where a modelling decision needs to be made is whether to add a property to a class to define a subtype or to specify a subclass. Consider, for example, the telephones supported by a small PBX that you are modelling. Assume that there are three types of telephone: a conventional handset with 5 programmable buttons, a conventional handset with 10 programmable buttons and an IP handset (i.e., a handset which, instead of being attached to a conventional telephone socket, is instead connected to a Local Area Network and which sends and receives speech as IP packets). There are probably sufficient differences between the IP and conventional handsets (e.g., the presence of an IP address in addition to the extension number) to define these as two different subclasses of a Telephone class; see Figure 10.2.

Figure 10.2: Possible Models of Telephones

However, would it be better to model the two types of conventional telephones by creating a further level of hierarchy as shown in Technique A or would it be better simply to add a property to the ConventionalTelephone class specifying the number of programmable buttons (Technique B)?

When making this type of decision, consider whether the 5-button telephones and the 10-button telephones will have different associations and different subclasses. If so, then it is probably better to subclass (Technique A); otherwise to use a property. Assuming that there are no differences between the telephones other than the number of buttons, using a property would be better.

Examples of this type of decision can be found throughout the core and common models. The class CIM_OSPFArea, for example, has a property called AreaType which specifies whether the area is normal, a stub or a not-so-stubby -area (NSSA!) (it does not matter what these mean ”for the purposes here they are just types of OSPFArea). It would have been possible to subclass CIM_OSPFArea into classes such as CIM_OSPFStubArea, CIM_OSPFNSSAArea and CIM_OSPFNormalArea but the decision was made instead to use a type property. A comment is placed into CIM_OSPFArea's description to annotate this decision: "This class has a 'Type' property, which distinguishes between the different area types. This approach was chosen , because it provides a simpler way to indicate the type of an area, and additional subclassing is not needed at this time."