Week 12

Introduction to Computer Science and Object-Oriented Programming

COMP 111

George Basham

Week 12 Topics

12.1.1 Choosing Classes

12.1.2 Cohesion and Coupling

12.1.3 Accessors, Mutators, and Immutable Classes

12.1.4 Side Effects

12.1.1 Choosing Classes• Designing classes is an art and a science• Remember that in general classes should

be nouns and methods should be verbs• One approach is to think of classes as

being one of four types:– Domain classes– Actors– Utility classes– Library classes

12.1.1 Choosing Classes Cont.

• Domain classes are typically extracted from the problem domain (what you are trying to solve). For example, for a payroll system, some classes could be Employee, TimeCard and PayCheck. Domain classes are entities that have well-defined properties. For example, one would expect to be able to withdraw and deposit money into a BankAccount class.

12.1.1 Choosing Classes Cont.

• Actors do some kind of work for you. For a payroll system, some actors could be CheckProcessor, TaxCalculator and CheckPrinter. Examples of Java API actors are the Scanner class and the Random class. As a rule of thumb, actors do things for or to a domain class and don’t have their own data. Typically, actors should end with an –er or an –or.

12.1.1 Choosing Classes Cont.

• You do not create objects from utility classes; they contains a collection of related static methods and constants. The Math class is a typical example. Remember that with a utility class you call methods on the class name, for example:

• double d = Math.sqrt(aValue);

// File Utility classpublic class FileUtil{ public static BufferedReader openInputFile(String fileName)

{ BufferedReader aReader = null; try { ...

// Example codeBufferedReader inEmp = null;String empFileName = “employee.dat”;inEmp = FileUtil.openInputFile(empFileName);

12.1.1 Choosing Classes Cont.

• Library classes contain reusable components that are used to assemble a program. The ArrayList Java API class is one example. You create objects from the ArrayList class (the objects have state, identity and behavior) and they are useful for many programs. There are many third-party library classes available also.

12.1.2 Cohesion and Coupling

• Cohesion is a measure of the degree to which a class models a single concept. The public interface (public methods and constants) should all be closely related to the real-world entity being modeled. High cohesion is desirable. A program that does everything in a single class would not be cohesive, but a program that is represented by a set of collaborative objects, each of which encapsulates a single concept, would be cohesive.

12.1.2 Cohesion and Coupling Cont.

• Coupling is a measure of the degree to which a class depends on other classes to work properly. A dependency (“A depends on B”) exists between classes A and B if objects of class A use objects of class B as instance fields, parameters, or temporary local variables. In general, the higher the degree of coupling a class has, the more difficult the class is to develop, test, and maintain because changes to class B affect class A; therefore, low coupling is desirable.

12.1.3 Accessors, Mutators, and

Immutable Classes

• Accessors and mutators are methods that are part of the public interface of a class. An accessor provides a way of extracting information from an object that has properly encapsulated its data. A mutator, on the other hand, alters the state of the object by changing instance fields. A class that has no mutators is called, appropriately, immutable. Immutable objects help minimize side effects. The most common immutable objects are the String class and the wrapper classes (Integer, Double, etc.).

12.1.4 Side Effects

• A mutator changes the state of an object by altering its instance fields, and the author of a class knows which methods are mutators and which are accessors. However, consider that another programmer who uses such a mutable object may not be aware of the change. Calling a mutator method has an externally visible change on the object called a side effect. Some side effects may not be expected, for example, when the change happens to a parameter to a method in another class.

// Example of an explicit parameter updatepublic class BankAccount{ public void transfer(double amount, BankAccount other)

{ balance = balance – amount; other.balance = other.balance + amount;

} ...

The update of the passed-in object is a side effect. The rule of thumb is to minimize side effects to explicit parameters and to document all mutator methods.

Reference: Big Java 2nd Edition by Cay Horstmann

12.1.1 Choosing Classes (section 9.1 in Big Java)12.1.2 Cohesion and Coupling (section 9.2 in Big Java)12.1.3 Accessors, Mutators, and Immutable Classes (section 9.3 in Big Java)12.1.4 Side Effects (section 9.4 in Big Java)