Java Reference
In-Depth Information
•
Does this attribute or method belong here?
If you find yourself specifying nearly identical methods in more than
one class, this should make you ask if the classes should have a common
base class from which they should inherit, or if there should be a new
unrelated class that they all share by composition.
If the functionality is the same for a set of classes, and the classes are
specific instances of a more general type, the method should be on the
general class. For example, a
changeName()
method should probably be
on Person, not on Employee or Customer, because the functionality is the
same for all three classes. By contrast, a
changeEmployeeNumber()
method should be only on Employee. It should not be on Person, because
not all Persons are Employees. There may also be methods that are com-
mon to both Employee and Customer types, but are radically different in
implementation. For example, a
changePassword()
method might
change a password in a system-wide LDAP server for an Employee, but
might just change a record in a Web site database for a Customer. This is
easily done by writing separate methods in each class.
But should you add a
changePassword()
method on Person? If you
want to be able to call the method when treating either a Customer or an
Employee as a Person, then you should. But you don't have to implement
the method on Person. You can declare
Person.changePassword
as ab-
stract, and then, if you call the method on a Person, it will call the correct
method based on what type of Person (Employee or Customer) the Person
is. Note that if a class contains any abstract methods, the class itself must
be declared abstract and it cannot then be instantiated. Also note that
this is often best accomplished not through abstract classes, but through
interfaces (see Eckel, pp. 321-322).
These are by no means the only considerations that come to bear on what
classes to create and how to arrange and implement them, but they do represent
a good start. They are a foundation on which you can build best practices out
of your own experience and environment.
Whole topics have been written on the topics of object-oriented analysis
and object-oriented design. CRC cards are only one part of an array of tech-
niques that can be applied to OOA/OOD. The Unified Modeling Language
(UML) is popular in many MIS circles. UML consists of a variety of different
diagrams which are used to model parts of an object-oriented design. They are:
