Basic Design Principles

• Modularity: software design should be modularized.
• Cohesion: software modules should aim for high cohesion.
• Coupling: software modules should aim for loose coupling.
• Encapsulation: software modules should encapsulate data and related operations.
• Information Hiding: software modules should hide implementation details from their clients.
• Separation of Concerns: software modules should separate different concerns into distinct modules such that each module addresses one concern.

Modularity

Modularity

---

The degree to which the components of a system are separated.

A modular design divides complex software into uniquely named components (modules), which supports the "divide and conquer" approach for solving a complex problem by breaking it into manageable modules.

Main mechanism for software modularization:

• methods/functions
• classes
• interfaces
• packages

Drawbacks to non-modularized code:

• inflexible to changes in requirements
• code snippets aren't reusable
• code isn't unit-testable

Primary concerns of modular design:

• decomposability
  • the extent to which the problem can be broken into sub-problems with simple relations
• composability
  • the extent to which the modular solutions to the sub-problems can be assembled as a solution to the whole problem
• adaptability
• reusability
• discontinuity
  • deletion of a module should not affect other modules
• continuity
  • a requirements change affects as few modules as possible

In general, a modular design should comply with the Open-Closed Principle. It should make modules testable and confine runtime exceptions and errors to very few modules from a QA perspective.

Modularity provides the foundation for each of the principles that follow.

Cohesion

Software modules are containers of elements

• a method is a container of statements
• a class is a container of
  • instance variables
  • class variables
  • constructors
  • methods

Cohesion

---

The degree to which the elements contained in a module belong together.

A module with high cohesion means that the module's elements have a high degree of connectedness.

Ideally, a cohesive method does one function or action. All statements in the method body work together to achieve the method's higher-level functionality.

A good code smell for low cohesion is the method name: if the statements in a method are not connected, it can be hard to find a concise name for the method.

• the doStuff() method

Cohesion focuses on the class interface, meaning the public constructors and methods.

• A cohesive class's public interface should justify is as an abstract data type.
• The public constructors/methods belong together and represent the essential properties of an object.

For example, a Stack<E> is defined by its last-in-first-out (LIFO) property. Thus, a cohesive design of stack might look like the following:

class Stack<E> {
    public Stack();
    public E push(E element);
    public E pop();
    public E peek();
    public boolean empty();
    public int search(E element);
}

Cohesion measurement must also consider inherited elements. This relates to the Stack<E> extends Vector<E> issue we keep coming back to. Since the Stack inherits methods from Vector that are not consistent with the defining property of a Stack (LIFO), the Stack class is not cohesive.

In general, a module with low cohesion is difficult to understand, test, maintain, and reuse.

A cohesive module is:

• more reusable for requirements change
• more testable for quality assurance

Note: perfect cohesion is not the goal of software design! Modules with a single atomic element are cohesive, but either hardly useful or tightly coupled to other modules. This means that cohesion should be balanced with module complexity and coupling.

Coupling

Coupling

---

The degree of interdependence between modules or the strength of the relationships between modules.

Good software design aims for loose coupling. The problem with tight coupling is that a module needs to be updated whenever one of its coupled modules has changed. The extent of change is relevant to the degree of dependency on the coupled module.

Tight coupling requires more effort to change, assemble, and test modules.

• testing a method requires all dependencies to be available
• when a failure occurs, tight coupling makes it difficult to locate the source of the fault

Measuring Coupling

• Size
  • measured by the number of connections between modules
  • a module with foo(a, b, c, d, e, f) is more tightly coupled than with bar(a)
  • consider classes Foo with 4 public methods and Bar with 100 public methods
    • a module would be more loosely coupled with Foo than with Bar
• Visibility
  • measured by the prominence of the connections between modules
    • positive: passing data in a parameter list
    • negative: modifying global data ("sneaky connection")
• Flexibility
  • measured regarding how easily the connections between modules can be changed
    • consider Stack<E> extends Vector<E>
    • too late to change because it would break many existing programs that use Stack with methods inherited from Vector

Loose coupling is often associated with high cohesion.

The goal is to minimize the number of modules affected by requirements change if feasible and reasonable, because it will make the modules mor reusable and testable.

Basic Example

Note: there's a whole section on refactoring to reduce coupling right here.

Consider the following code:

public class Client {
    public void bar(D d) {
        E e = d.getE();
        e.doTheThing();
    }
}

Here, bar(d) is coupled to both D and E. Through D, it "talks" to E. To reduce coupling, we can refactor D to handle the interaction with E itself so that bar(d) only needs to talk with D.

public class Client {
    public void bar(D d) {
        d.doTheThingOnE();
    }
}

This follows the guideline known as the Law of Demeter.

Law of Demeter

---

Only talk to immediate friends.

Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.

The Law of Demeter says that "a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents), in accordance with the principle of information hiding."

Remote Control Example

Consider the following example:

public class RemoteControl {
    private SamsungTV tv;
    public void turnOn() {
        tv.on();
    }
}

public class SamsungTV {
    public void on();
    public void off();
    public void tuneChannel(int channel);
}

Here, RemoteControl is tightly coupled with (and will be affected by changes to) SamsungTV. It also has no way to interface with other TV brands.

We can reduce coupling by introducing an interface TV and making SamsungTV implement the interface.

    public class RemoteControl {
        private TV tv;
        public void turnOn() {
            tv.on();
        }
    }

    public interface TV {
        public abstract void on();
        public abstract void off();
        public abstract void tuneChannel(int channel);
    }

    public class SamsungTV implements TV {
        public void on();
        public void off();
        public void tuneCHannel(int channel);
    }

With that refactoring, we've decoupled RemoteControl from SamsungTV. This gives us the freedom to implement new classes such as PhilipsTV without tightening the coupling of RemoteControl.

Encapsulation

Encapsulation provides a way to better modularization by coping with the areas of requirements likely to change. Encapsulating these areas facilitates conceptualizing the underlying problem at a higher level of abstraction so that clients only need to worry about the interface rather than implementation details.

For our purposes, we can think of encapsulation as a tool used to help achieve information hiding.

Encapsulation

---

1. the action of enclosing something as if in a capsule
2. the succinct expression or depiction of the essential features of something

In general, the operations associated with a data structure should be entirely confined to one module.

• for Tic Tac Toe, classes Move and GameState may be more appropriately contained within the Board class (diagram on p. 92)

Information Hiding

Information Hiding

---

The act of hiding information inside a module, i.e., making it invisible to the modules clients.

Good practice is for a class to make each instance variable private, setting a public accessor (getter) and, if necessary, mutator (setter).

Public instance variables (global variables) are notoriously difficult to debug. They also tend to change over time, requiring all clients to change.

A class's testability should be considered when decisions on getters and setters are made - a test may need a getter to verify that a variable has the right value.

Encapsulation can decrease the need for public instance variables - when all relevant methods are encapsulated within the same module, they all share a common visibility and access can be more appropriately restricted to the outside world.

Separation of Concerns

Separation of Concerns

---

Design principle for separating a program into distinct modules such that each module addresses a separate concern, facilitating module upgrade, reuse, and independent development.

Consider how web development separates concerns:

• HTML: organization of webpage content
• CSS: definition of content presentation style
• JavaScript: how the content interacts and behaves in response to user input

Despite our best efforts at modularization, some concerns crosscut many modules.

• logging
• error handling
• data persistence
• security checks

Crosscutting concerns cannot be not well-modularized and are referred to as "tangled" because they are necessarily intermixed with code that handles other concerns. These concerns follow inherently different rules for functional decomposition.

Aspect-Oriented Programming attempts to resolve this problem. AOP shouldn't be on the final, but if it is it's covered very briefly in the book on p. 96.

Footnotes