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