Transcript week1topics - Computing Sciences

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