Java Reference
In-Depth Information
13.10.1 Cohesion
A class should describe a single entity, and all the class operations should logically fit together
to support a coherent purpose. You can use a class for students, for example, but you should not
combine students and staff in the same class, because students and staff are different entities.
A single entity with many responsibilities can be broken into several classes to separate
the responsibilities. The classes
String
,
StringBuilder
, and
StringBuffer
all deal with
strings, for example, but have different responsibilities. The
String
class deals with immuta-
ble strings, the
StringBuilder
class is for creating mutable strings, and the
StringBuffer
class is similar to
StringBuilder
except that
StringBuffer
contains synchronized meth-
ods for updating strings.
coherent purpose
separate responsibilities
13.10.2 Consistency
Follow standard Java programming style and naming conventions. Choose informative names
for classes, data fields, and methods. A popular style is to place the data declaration before the
constructor and place constructors before methods.
Make the names consistent. It is not a good practice to choose different names for
similar operations. For example, the
length()
method returns the size of a
String
, a
StringBuilder
, and a
StringBuffer
. It would be inconsistent if different names were
used for this method in these classes.
In general, you should consistently provide a public no-arg constructor for constructing a
default instance. If a class does not support a no-arg constructor, document the reason. If no con-
structors are defined explicitly, a public default no-arg constructor with an empty body is assumed.
If you want to prevent users from creating an object for a class, you can declare a private
constructor in the class, as is the case for the
Math
class.
naming conventions
naming consistency
no-arg constructor
13.10.3 Encapsulation
A class should use the
private
modifier to hide its data from direct access by clients. This
makes the class easy to maintain.
Provide a getter method only if you want the data field to be readable, and provide a setter
method only if you want the data field to be updateable. For example, the
Rational
class
provides a getter method for
numerator
and
denominator
, but no setter method, because a
Rational
object is immutable.
encapsulate data fields
13.10.4 Clarity
Cohesion, consistency, and encapsulation are good guidelines for achieving design clarity.
Additionally, a class should have a clear contract that is easy to explain and easy to understand.
Users can incorporate classes in many different combinations, orders, and environments.
Therefore, you should design a class that imposes no restrictions on how or when the user can
use it, design the properties in a way that lets the user set them in any order and with any com-
bination of values, and design methods that function independently of their order of occurrence.
For example, the
Loan
class contains the properties
loanAmount
,
numberOfYears
, and
annualInterestRate
. The values of these properties can be set in any order.
Methods should be defined intuitively without causing confusion. For example, the
substring(int beginIndex, int endIndex)
method in the
String
class is somewhat
confusing. The method returns a substring from
beginIndex
to
endIndex - 1
, rather than to
endIndex
. It would be more intuitive to return a substring from
beginIndex
to
endIndex
.
You should not declare a data field that can be derived from other data fields. For exam-
ple, the following
Person
class has two data fields:
birthDate
and
age
. Since
age
can be
derived from
birthDate
,
age
should not be declared as a data field.
easy to explain
independent methods
intuitive meaning
independent properties
public class
Person {
private
java.util.Date birthDate;
Search WWH ::
Custom Search