09 Classes and Class Design

Modeling Concepts with Classes

A Java class is a programmer-defined type that combines state and behavior. Fields store state, methods provide behavior, and an object is an instance of a class created at run time.

When modeling a concept such as BankAccount, Student, or Thermostat, identify:

• The important state that must be stored.

• The behavior the object should provide.

• The rules that must always remain true.

• The other objects it may need to use.

A bank account might store an account number and balance. Its methods could include deposit, withdraw, and getBalance. The class should enforce rules such as rejecting a negative initial balance and refusing a withdrawal that exceeds the available balance.

A strong design keeps clients focused on what the object can do rather than on how its data is stored.

Takeaway: Begin with a meaningful concept, then connect its state, behavior, rules, and collaborators.

Constructors and Object Initialization

A typical class uses fields for object state, a constructor to establish an initial valid state, and methods to provide behavior or controlled access to state.

A constructor has the same name as its class and no return type. It is called when an object is created with new. Constructors should validate arguments when necessary so that an object cannot begin in an invalid state.

A class may provide multiple constructors through constructor overloading. The constructors must have different parameter lists. One constructor can delegate to another by using this(...), which must be the first statement in the constructor.

Inside an instance method or constructor, this refers to the current object. It is especially useful when a parameter has the same name as a field, as in this.name = name.

Example: A Rectangle constructor can reject nonpositive dimensions, store the valid width and height, and let an area method calculate the rectangle's area.

Takeaway: Constructors establish valid initial state; methods define the operations that are allowed afterward.

Encapsulation and Access Control

Encapsulation protects an object's state by limiting direct access to its representation. Fields should usually be private, while public methods should expose only operations that make sense for the concept.

For example, a bank account should not expose a public balance field that any caller can replace with an invalid value. Instead, it can provide a deposit method that accepts only positive amounts and a withdraw method that checks both the requested amount and the current balance.

Access modifiers control visibility:

• private members are accessible only within the declaring class.

• Members with no modifier are accessible within the same package.

• protected members are accessible within the package and, subject to Java's protected-access rules, in subclasses.

• public members are accessible to other code.

A getter may provide read access without allowing arbitrary replacement. A setter should be added only when unrestricted replacement is appropriate. Choosing the most restrictive suitable access level also allows the internal representation to change without requiring changes from client code.

Takeaway: Hide data, expose meaningful operations, and make every operation preserve the object's rules.

Instance and Static Members

An instance member belongs to one particular object. Each Player object can have its own instance field such as name. A static member belongs to the class itself and is shared by all objects of that class.

Use a static field when a value describes the class as a whole, such as a count of all Player objects. Use a static method when an operation does not need a particular object's state, such as MathTools.square.

A static method cannot directly use instance fields, instance methods, or this because it has no particular object. It can directly use static members. Static members are normally accessed through the class name.

The combination static final is commonly used for a class-level constant. static means the member belongs to the class, while final means the field cannot be reassigned after initialization.

Takeaway: Choose instance members for object-specific state and behavior; choose static members for class-wide state or operations.

Responsibilities and Public Interfaces

The public interface of a class should be small, clear, and difficult to misuse. Decide which responsibilities belong to the class, which data must remain private, which operations should be public, and whether objects should be changeable after construction.

A cohesive class keeps related data and behavior together. The principle of single responsibility suggests that a class should generally have one central responsibility. For example, a PayrollCalculator should calculate payroll rather than also handling user-interface drawing, database connections, and file backups unless those responsibilities are deliberately part of its design.

A useful design process is:

1. Extract nouns that may become classes, such as Order, Customer, and Product.

2. Extract verbs that may become methods, such as addItem, cancel, and calculateTotal.

3. Assign each action to the object best suited to perform it.

4. List the state each object must store.

5. Identify invariants that must always remain true.

6. Hide the representation behind necessary operations.

7. Test normal, boundary, and invalid cases.

For an online order, separating Order, OrderItem, Product, and Customer gives each class a clearer responsibility and makes the design easier to test and change.

Takeaway: Good interfaces make valid use easy, invalid use difficult, and responsibilities easy to understand.

Inheritance and Composition

Inheritance expresses an is-a relationship. A Bicycle can extend Vehicle when a bicycle genuinely satisfies the meaning of being a vehicle. The subclass can use accessible behavior from the superclass and add behavior of its own.

A subclass constructor can call a superclass constructor with super(...). Constructors are not inherited, and private superclass members are not directly accessible to subclasses. A superclass should expose protected or public behavior only when that access is part of the intended design.

Composition expresses a has-a or uses-a relationship. A Car can contain an Engine object and delegate starting behavior to that engine. Composition often provides more flexibility because a class can work with different component objects without forming a rigid inheritance relationship.

Choose inheritance only when the subtype truly satisfies the superclass's meaning. Choose composition when the class mainly needs another object's functionality.

Takeaway: Use inheritance for a genuine is-a relationship and composition for assembled or delegated behavior.

• invariant