Smalltalk and Object Orientation: an Introduction - Free

19.3.2.4 Identify attributes of objects
OMT suggests that attributes correspond to nouns followed by possessive phrases, such as “the color of
the car” or “the position of the cursor” in the problem statement. Although the authors do admit that
attributes are less likely to be fully described in the probl em statement and that you must draw on your
knowledge of the application domain and the real world to find them. If you have already used a method
such as OOA you may already have identified the key attributes. Luckily attributes can (usually) be
easily added to objects as and when they are identified - it is rare that the addition of a new attribute will
cause the structure of the system to become unstable.
An important point to note is that you should only be trying to identify application domain attributes.
This means that attributes which will be needed during the implementation of the system should not be
included at this stage. However, link attributes (which might appear to be implementation attributes)
should be identified at this stage as they have an impact on the systems structure. A link attribute is a
property of the link between two objects, rather than being a property of an individual object. For
example, the many to many association between Stockholder and Company has a link attribute of
“number of shares”.
Having identified the set of candidate attributes for each object you should then challenge these
attributes using the following criteria:
Should the attribute be an object? For example, earlier we said that a telephone call should not be an
object, however if you are constructing a telephone call billing system, then it is probable that it should
be an object. You therefore need to think carefully about the domain when deciding whether something
is an attribute or an object. Don’t worry ab out getting it wrong (there may be no correct answer) you
can come back to it later and refine the model.
Is an attribute really a name ? Names are often actually selectors used to identify a unique object
from a set of objects. In such situations a name should really be a qualifier.
Is an attribute an identifier ? Here identifier relates to a computer based identifier and is an
implementation issue and not part of the application domain. For example, objectId is an identifier
which is probably not in the applications domain.
Is an attribute really a link attribute ? Link attributes are often mistaken for object attributes. Link
attributes are most easily identified when it becomes difficult to identify which of two (or more) classes
the attribute should belong to. In such situations it is an attribute of the link between the two classes.
Does the attribute represent an internal state of the object which is not visible outside the object ? If
it does remove the attribute. It is an internal implementation issue and not part of the domain problem.
Does the attribute represent fine detail? If the attribute represents some aspect of the object which is
relatively low level then omit it. It will not help with the overall understanding of the domain and will
increase the complexity of the object model.
Are any of the attributes unlike the others in their class ? Such discordant attributes may either be
misplaced (this may indicate that one class should actually be two or more) or that the attribute is not
part of the current application (although it may be part of the overall domain).
19.3.2.5 Organize and simplify object classes using inheritance
The next step is to refine your classes using inheritance. This can be done in both directions, that is,
either by grouping common aspects of existing classes into a superclass from which the existing classes
inherit or by specializing an existing class into a number of more specialized subclasses which serve
specific purposes. Again if you have used an analysis method such as OOA, some o f this may already
have been performed. Note that you are not doing this with a view to implementing the class hierarchy
being generated, rather you are trying to understand the commonalities in the domain.
Identifying potential superclasses is easier tha n identifying specialized subclasses. To find potential
superclasses, you should examine the existing classes looking for common attributes, operations or
associations. Any common patterns you find may indicate the potential for a superclass. If such a
situation is found, then the superclass should be defined with an appropriate name (i.e. one that
encompasses the generic roles of the class which will inherit from it). Then move the attributes,
associations and operations which are common up into this super class. Do not try to force unrelated
classes to become subclasses of a superclass just because they happen to have similar attributes (or
associations or operations). Attempt to make sure that when you do group a set of classes together under
a superclass, that grouping makes sense in the application domain. For example, grouping the classes
160