Object-Oriented Design - Java Software Solutions: Foundations of Program Design - page 304

The user must be allowed to specify each product by
its primary characteristics, including its name and
product number. If the bar code does not match the
product, then an error should be generated to the
message window and entered into the error log. The
summary report of all transactions must be structured
as specified in section 7.A.
FIGURE 7.1 A partial problem description with the nouns circled
Remember that a class represents a group of objects with similar behavior. A
plural noun in the specification, such as products, may indicate the need for a
class that represents one of those items, such as Product . Even if there is only one
of a particular kind of object needed in your system, it may best be represented
as a class.
Classes that represent objects should generally be given names that are singular
nouns, such as Coin , Student , and Message . A class represents a single item from
which we are free to create as many instances as we choose.
Another key decision is whether to represent something as an object or as a
primitive attribute of another object. For example, we may initially think that
an employee's salary should be represented as an integer, and that may work for
much of the system's processing. But upon further reflection we might realize
that the salary is based on the person's rank, which has upper and lower salary
bounds that must be managed with care. Therefore the final conclusion may be
that we'd be better off representing all of that data and the associated behavior
as a separate class.
Given the needs of a particular program, we want to strike a good balance
between classes that are too general and those that are too specific. For example,
it may complicate our design unnecessarily to create a separate class for each type
of appliance that exists in a house. It may be sufficient to have a single Appliance
class, with perhaps a piece of instance data that indicates what type of appliance
it is. Then again, it may not. It all depends on what the software is intended to
accomplish.
In addition to classes that represent objects from the problem domain, we
likely will need classes that support the work necessary to get the job done. For
example, in addition to Member objects, we may want a separate class to help us
manage all of the members of a club.
Keep in mind that when producing a real system, some of the classes we iden-
tify during design may already exist. Even if nothing matches exactly, there may
be an old class that's similar enough to serve as the basis for our new class. The