Unit 9: Designing Classes

9.0. Overview - Introduction to Class Design

This is a key point in the year. After learning about basic control structures—conditionals and loops—and some data structures—variables, classes, Arrays, and ArrayLists—we're going to pull back and talk about some big picture stuff.

For the next units we're going to be examining things that have less to do with Java and more to do with applied Computational Thinking. We'll be exploring these ideas from a Java-based context, of course, but the core of these ideas is much bigger than just Java.

We'll start by looking at Creating Classes, Cohesion & Coupling, and introducing the Unified Modeling Language (UML).

Let's get started!

1. Classes, Cohesion, Coupling
2. Methods, Immutability, Side Effects
3. Static Methods, Static Fields
4. Scope
5. Design Patterns

9.1. Classes, Cohesion, Coupling

9.1.1. Creating Classes

Writing a Java program up this point has consisted mostly of implementing a Public Interface—someone else has told us what instance variables to set up, what classes to create, what methods to develop. This is a great way to learn basic coding skills in Java.

We also need to be able to figure out our own classes, though, and that can be very challenging.

If you've studied other languages (Python, maybe?!) you may be familiar with the idea of writing functions to carry out actions. In object-oriented programming, however, these same actions are performed by methods, which usually belong to classes, which are are ways of classifying objects based on common properties. For example, the Car class has an instance (specific object) called myHighlander, which has certain attributes (double gasMileage, etc.) and methods (.drive() and .addFuel()).

Let's take a moment to look and see how we can identify classes when given a problem to solve.

9.1.2. Identifying classes

What classes have we worked with so far this year?

• Geometry → Point, Rectangle
• Math → Random numbers
• Business → BankAccount, Bank, CashRegister
• Simulations/Models/Games → Die, Board, Purse, Craps

Nouns that describe a concept make good classes.

Actors can make good classes as well; these usually end in -er or -or (Scanner).

Some classes have no objects, just a series of static methods and constants—these are sometimes called Utility classes. Static methods don't operate on an instance, they just provide functionality.

The Math class is a good example of a utility with static fields and static methods.

Although it's possible to write programs with lots of static methods, in good object-oriented program that practice is largely avoided.

9.1.3. Cohesion and Coupling

There are two useful criteria for assessing the quality of your class and its public interfaces. (Remember what the public interface is: the public features—methods, fields, nested types—of a class that are accessible to clients.)

9.1.3.1. Cohesion

So one thing that we want to do is write classes that maximize cohesion.

9.1.3.2. Coupling

The other thing that classes need to do is minimize coupling.

Coupling

Coupling refers to the dependencies there are for a class.

A Craps class may depend on a DiceRoll class (the roll of two dice), which in turn depends on a Die class. The greater the number of dependencies, the greater the degree of coupling.

 

Here's another example using the "RandomStudent" program I wrote in Java:

It's a good idea to minimize coupling between classes, because the effects of edits to a program are minimized if only one or two classes are affected. More coupling means that relationships are more complicated, small edits require changes to more parts of a program, and re-using code from one project in another will require bringing over more classes.

9.1.3.3. Cohesion vs. Coupling

Wait a minute. So do we want more cohesion, with more classes representing well-defined objects (and those objects necessitating coupling) or do we want less coupling, which means there have to be fewer classes?

Make up your mind!

It's not quite an either-or proposition. We absolutely do want cohesive classes that can be well defined and clearly described... and that is going to necessitate some greater degree of complexity. But it's possible to write our classes, too, so we reduce the number of connections they have with other classes. Where reasonably possible, we want to reduce the coupling, but not at the expense of our well-defined classes.

It's all about getting the balance right.

9.1.4. Dependencies

Here, with the two classes that we've been discussing, it's clear that the CashRegister class depends on the Coin class—we say that the Coin class is a dependent class. The diagram above, a screenshot from a BlueJ window, is actually a type of Unified Modeling Language (UML) class diagram, with the dashed line and open arrow pointing to the dependent class.

Does Coin depend on CashRegister? No. The Coin class knows nothing of the CashRegister class, and doesn't make use of it.

The number of interdependencies that classes have in a program is referred to as the degree of coupling. The same number of classes may be highly coupled if many classes uses many other classes, or they may have low coupling if there are a lesser number of dependencies.

Reducing coupling

Both of these craps programs do the same thing, but one was written so that it directly depends on Die and DiceRoll, while the other depends only on DiceRoll. Reducing dependencies allows us to reduce coupling, which reduces the amount of code we have to manage, especially important if we have to make changes to some of the code.

Another example of decoupling/minimizing dependencies:

9.2. Methods, Immutability, Side Effects

9.2.1. Accessors, Mutators, and Immutable Classes

We've looked at three aspects of the public interface: constructors, accessor methods, and mutator methods. In the BankAccount class, the .deposit() and .withdraw() methods both caused a change in the state of a BankAccount object, so they were considered mutators, while .balance() only checked the money in the object (an accessor), and didn't change the state of the object.

Some classes are designed so that none of their methods can change the state of an object of that class. The String class, for example, has no mutator methods. You can construct a String, but once it's constructed, it can't be changed. There are methods that manipulate a version of that string and return it in a different form, it's true—"Richard".toUpperCase() or studentName.toUpperCase(), for example—but they leave the original String object unaltered.

Classes that are designed without any "setters," and with no way to alter the state of the class are called immutable classes; no mutations of the class are possible. An immutable class has the advantage that reference to it may be freely given out to other objects, because no methods can unexpectedly modify the state of any object of that class.

Compare this with the BankAccount class, where you know that if you make it available to other objects, they are able to use the .deposit() and .withdraw() methods, and may alter the state of any BankAccount.

So, a Date class might consist of four instance variables: month, date, year, and dayOfWeek. For a given date, none of those instance variables is going to change. Once a Date has been constructed, we should be able to access the different fields via accessor methods. We should not be able to change any of those values for that given Date.

9.2.2. Side Effects

So when we use a method, we have this "accessor-mutator" question. Mutator methods manipulate data within the method certainly, and because they modify the object so that it is observable outside of the method, we say that they produce a side effect, in this case the modification of the implicit parameter (the object whose method is being called).

What happens in this situation, however?

Updating an explicit parameter as a side effect should be avoided whenever possible, because it produces changes in the state of another object that may be unexpected.

Is using other.deposit(amount) instead of other.balance = other.balance + amount a better way of writing the .transfer() method? No, because we're still modifying the explicit parameter.

So how should we write this?

The solution to this is that a larger class—the Bank class in this case—needs to manage the transfer:

9.2.3. Other types of Side Effects

Output produces side effects as well, and you should be aware of challenges that can arise from that.

We've discussed in here the fact that a method might print a value or it might return a value to code that calls it. For example, in the BankAccount class, if we want to be able to print out the value of the balance we could do it in one of two ways:

• Write a printBalance() method for the BankAccount class:
  public void printBalance() { System.out.println("The balance is now $" + balance); }
• Write a getBalance() method that returns a value that can be printed by the caller:
  public double getBalance() { return mySavings.getBalance(); }

It is preferable to return a value rather than just print it. Why?

First of all, you wouldn't want to NOT have a .getBalance() method, because sometimes you really do just want to get the balance for some purpose, and not print it out.

Secondly, having this statement in your class assumes that the person using the program is speaking English and using dollars ($), and that may not be the case.

Also, this extra method couples our bank account to the System and PrintStream classes when it really isn't necessary. We want to reduce coupling if possible.

It's better to write these methods using the return statement.

9.2.4. Call by Value and Call by Reference

In Java, parameters that are included in a method call have their values copied into variables for that method at the time the method starts, a system known as call by value. Let's see how that works using a simple example.

This process of passing parameter values into a method is known as pass-by-value or call-by-value.

Here's another example.

We can't exchange the contents of primitive values, but we can change the state of an object. We can update the state of a BankAccount balance, for example. And if we send in the two values in some kind of object—a small Array will do it—then we can exchange the values that way.

There's another possibility that some languages (not Java) allow for, and that's allowing parameters to be call-by-reference. In these systems, some variables are allowed to be modified by method. And Java actually does allow for the modification of objects that are passed as parameters, in something that looks like call-by-reference.

Let's see how that works.

9.2.5. PreConditions, Assertions, and PostConditions

While a method is technically not responsible for bad results if preconditions are not met, in reality one of two things usually happens:

1. The method can be written to check for violation of the condition and "throw an exception", with control of the program being transferred to an exception handler. (If there's no handler, the program just terminates.)
2. The method can just continue to work with the bad data, assuming that preconditions have been fulfilled. Any data corruption or errors are the fault of the instruction that called the method.

One way of trying to manage this is by using assertions, which are logical conditions in your program that you believe to be true.

For example:

So what happens? If assertion checking is enabled (and it is by default in BlueJ), and the assertion fails, the program terminates with an assertion error. Let's try it with the BankAccount.

[Demo]

There are a number of great things about assertions. One is that you can check all sorts of things with them, not just your preconditions.

Also, although they slow down your code execution when you enable them, if you compile your code *without* enabling them then they don't get included in the machine code; the assertions are automatically left out, like comments are, so the code runs super fast once it's working. (It's like having a word processor automatically clear all your rough draft scribbles off the paper you have to turn in.)

Sometimes it's nice to know what the postconditions are for a method: what does the method promise to leave you with, assuming the preconditions have been met. Looking at our deposit example again:

9.3. Static Fields, Static Methods

9.3.1. Static Methods

This is naturally confusing because objects are of a class, but some classes don't have objects. A better phrase for "static method" is "class method" ie. a method invoked on a class. (The reason it's not called a class method is complicated. Read about it in the book.)

Here's the header for a method of the BankAccount class...

...and we would call it by saying mySavings.deposit(100);

If we call a static method, however, there's no object to call the method on:

Here, Math is not an object—it's a class. So the .sqrt() method is a static method.

We can write our own static methods. They look like regular methods except they have to be declared as static. We can write out own square root method, for example:

Or, an example from book:

Because these static methods don't belong to a class, we need to place them somewhere. One way to do that is to make a class that will hold them, the way that the Math class in the Java library holds a bunch of math-related methods.

Then we can use it: System.out.println(Financial.percentOf(50, 30));

9.3.2. Static Fields

Just as static methods are methods that don't belong to a specific object, it's sometimes convenient to have static fields (static variables) that store values outside of any specific object.

[Just as we noted that static methods might be better referred to as "class methods" because they belong to a class and not an object, static fields might be better referred to as "class fields" for the same reason. They belong to a class and not a specific instance (object) of that class.]

Consider again the BankAccount class, the version where each account has an account number.

If we wanted to number the accounts sequentially starting from the number 1001, how we would implement that idea? Where are we going to store the numbers that we use to assign to accountNumber when we create a new BankAccount?

We'll use a static field (or a "class variable") to keep track of the assignedNumber for the entire class:

Every instance of the BankAccount class will now have its own balance and account number, but BankAccount.lastAssignedNumber exists separately, and is stored outside of any individual object.

Every method of a class can access its static fields. Now, what would the constructor look like for the BankAccount?

There are several different ways to initialize a static field.

1. Explicitly initialize it in the class declaration as we did above. That initialization is executed when the class is loaded.
2. Do nothing. The static field will then be automatically initialized to a default value, depending on its type: 0 for numbers, false for booleans, and null for objects.
3. Use a static initialization block. This isn't something that we'll do in this course.

As with instance fields, static fields should be declared as private so that other classes can't accidentally or purposely change their values. The only exception to this is a constant value which you may want to make available so that other classes can access them. You don't have to worry about security in this case because the value of the constant can't be changed.

Although static classes and static fields have their uses, if you find yourself using a lot of them it may mean that you need to reexamine the design of your program so that it works in a more object-oriented way.

9.4. Scope

Programs use variables, but there are lots of different parts of a program—the main method, classes, methods, etc.—and there are rules that govern which variables are allowed to be accessed in which regions.

The scope of a variable refers to that region of the program in which the variable can be accessed.

9.4.1. Local scope

Local variables are only accessible from the point where they're created to the end of their enclosing block.

Example from book:

9.4.2. Scope of Class Members

The members of a class refer to the fields and methods of a class. What scope do the fields and methods of a class have?

Private fields or methods have class scope: you can access all members in and from any methods in the class.

Public fields or methods may be accessed from outside the class but the name used must be a qualified name.

If you're inside a method, you don't need to qualify fields or methods that are from the same class. You can use an unqualified name.

9.4.3. Overlapping Scope

If you try to create two variables within the same class or method, the compiler won't even allow it, so that's pretty easy to avoid.

It's possible, however, to create a shadow problem, when a local variable "shadows" a field with the same name. Here are a number of ways to do this; which ones work correctly?

Above, the code won't even compile—there are two balance identifiers in the same block of code.

What about this?

Here, the local variable balance in the constructor shadows the instance variable balance—the instance variable balance is never referenced because local scope takes precedence. The instance variable is left with a null value.

Here, the variable balance in the constructor refers correctly to the instance field.

Here, the instance variable balance is qualified, which distinguishes that variable from the explicit parameter balance.

Solutions:

• use the this reference to assign a value to the instance variable
• use a different local variable name

9.5. Design Patterns

Writing code to solve problems can be an extraordinarily creative process. It's also true, however, that there are a number of common challenges that can be solved with a known code or algorithm strategy. By being able to recognize a few recurring patterns in some of the problems we're faced with, we'll be able to more easily apply a few known solutions.

Here are the most common problems, along with the strategies that one can use to solve them.

9.5.1. Counting Items

Counting is fundamental to computer programs:

• Incrementing your age each time you celebrate a birthday
• Counting the number of people who have RSVPed for a party
• Counting the number of female-identifying students in a class

Declaring a counter variable, initializing it to some value, incrementing the counter, and (at some point) resetting it to zero... these are such common processes that you'll often see many of them bundled together into a single line of code:

In other circumstances, you'll just increment a variable:

9.5.2. Summing Items / Keeping a Total

Rather than just incrementing a counter, you often will need to keep track of a total value:

• The amount of gas in a car
• The number of calories burned in a workout
• Depositing money in a bank account
• The points earned in a computer science course

9.5.3. Grouping Items

If you need to work with a collection of items, it's common to store them in an Array or an ArrayList whether they can be iterated through.

Sometimes you'll use an index variable to go through the loop:

...and other times you can use an "enhanced" for-each style loop to go through all the items without needing an explicit index:

9.5.4. Managing the state of an object

Object-oriented programming often involves the modeling of real-world objects. The state of the object, and its interaction with other objects in the model or simulation, is handled via methods that get and set the state of the instance variables.

9.5.4.1. Tracking the motion of an object

A moving object can be understood in terms of its position, its velocity, and (perhaps) its acceleration. We can do that in a single dimension—along the x-axis, say—or in two or three dimensions.

A class of physics problems involves projectiles, which move through the air in a parabolic arc called a trajectory.

What instance variables will we need to model a projectile object? What methods will be needed to interact with that projectile?

9.5.4.2. Modeling a finite number of states

An object will sometimes have a characteristic that can be described in terms of a binary state: a location in Conway's Game of Life may have a living cell there or not. To model that, we could have a variable isOccupied that has a value true or false depending on the state of that cell.

Likewise, in the BankAccount class we might have a boolean variable activeAccount that has a value of true or false. An active account is one that is currently being used by the client, while an account that has activeAccount set to false is one that has been closed. We'll still have a record of the account, but the client can't interact with it anymore.

It may be, however, that there are more than just two states for a characteristic. A Frog class, modeling a frog might want to describe its age as a sequence. At first the frog is an egg, then it's a tadpole, than it's a juvenile, then it's adult, and then it's dead. How can we describe this sequence of states?

One strategy is by mapping these states to int values:

In this example, the public static final int values each have a constant value that is a code for the corresponding age. Although they're int values, the numbers themselves aren't usually used for calculations. Rather the states are used like this:

9.5.4.3. Enumerated types

A slightly more advanced way of modeling the states of a variable without using the integer "codes" is by using an enumerated type. An enumerated type is a specialized, user-defined type that can only have a specific range of values.

The relationship status of a person, for example, might be described as "single", "married", "divorced", or "complicated". With that in mind, then an enumerated type of Status could be defined and used as follows:

Note that incrementing an enumerated type (as we did with the Frog's age above) is not supported by this strategy (although there are ways to work around that if needed).