Week 12 Introduction to Computer Science and Object-Oriented Programming COMP 111 George Basham

Week 12 Topics Choosing Classes Cohesion and Coupling Accessors, Mutators, and Immutable Classes Side Effects

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

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.

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.

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 class public class FileUtil { public static BufferedReader openInputFile(String fileName) { BufferedReader aReader = null; try {... // Example code BufferedReader inEmp = null; String empFileName = “employee.dat”; inEmp = FileUtil.openInputFile(empFileName);

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.

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.

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.

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.).

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 update public 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 2 nd Edition by Cay Horstmann Choosing Classes (section 9.1 in Big Java) Cohesion and Coupling (section 9.2 in Big Java) Accessors, Mutators, and Immutable Classes (section 9.3 in Big Java) Side Effects (section 9.4 in Big Java)