Software Design Principles

Most programs are written to solve complex problems involving large amounts of intricate details. It is impossible to deal with all these details at the same time. The guiding principle of abstraction stipulates that we capture only details that are relevant to the current perspective or the task at hand.

Ignoring lower level data items and thinking in terms of bigger entities is called data abstraction.

Control abstraction abstracts away details of the actual control flow to focus on tasks at a simplified level.

Abstraction can be applied repeatedly to obtain progressively higher levels of abstractions.

Coupling is a measure of the degree of dependence between components, classes, methods, etc. Low coupling indicates that a component is less dependent on other components. High coupling (aka tight coupling or strong coupling) is discouraged due to the following disadvantages:

• Maintenance is harder because a change in one module could cause changes in other modules coupled to it (i.e. a ripple effect).
• Integration is harder because multiple components coupled with each other have to be integrated at the same time.
• Testing and reuse of the module is harder due to its dependence on other modules.

📦 In the example below, design A appears to have a more coupling between the components than design B.

X is coupled to Y if a change to Y can potentially require a change in X.

class Foo{
    ...
    new Bar().read();
    ...
}

class Bar{
    void read(){
        ...
    }
    
    void write(){
        ...
    }
}

Some examples of different coupling types:

• Content coupling: one module modifies or relies on the internal workings of another module  e.g., accessing local data of another module
• Common/Global coupling: two modules share the same global data
• Control coupling: one module controlling the flow of another, by passing it information on what to do  e.g., passing a flag
• Data coupling: one module sharing data with another module  e.g. via passing parameters
• External coupling: two modules share an externally imposed convention  e.g., data formats, communication protocols, device interfaces.
• Subclass coupling: a class inherits from another class. Note that a child class is coupled to the parent class but not the other way around.
• Temporal coupling: two actions are bundled together just because they happen to occur at the same time  e.g. extracting a contiguous block of code as a method although the code block contains statements unrelated to each other

Cohesion is a measure of how strongly-related and focused the various responsibilities of a component are. A highly-cohesive component keeps related functionalities together while keeping out all other unrelated things.

Higher cohesion is better. Disadvantages of low cohesion (aka weak cohesion):

• Impedes the understandability of modules as it is difficult to express module functionalities at a higher level.
• Lowers maintainability because a module can be modified due to unrelated causes  (reason: the module contains code unrelated to each other) or many many modules may need to be modified to achieve a small change in behavior  (reason: because the code realated to that change is not localized to a single module).
• Lowers reusability of modules because they do not represent logical units of functionality.

Cohesion can be present in many forms. Some examples:

• Code related to a single concept is kept together, e.g. the Student component handles everything related to students.
• Code that is invoked close together in time is kept together, e.g. all code related to initializing the system is kept together.
• Code that manipulates the same data structure is kept together, e.g. the GameArchive component handles everything related to the storage and retrieval of game sessions.

📦 The components in the following sequence diagram show low cohesion because user interactions are handled by many components. Its cohesion can be improved by moving all user interactions to the UI component.

While it is possible to isolate the functionalities of a software system into modules, there is no way to remove interaction between modules. When modules interact with each other, coupling naturally increases. Consequently, it is harder to localize any changes to the software system. The Open-Close Principle aims to alleviate this problem.

In object-oriented programming, OCP can be achieved in various ways. This often requires separating the specification (i.e. interface) of a module from its implementation.

📦 In the design given below, the behavior of the CommandQueue class can be altered by adding more concrete Command subclasses. For example, by including a Delete class alongside List, Sort, and Reset, the CommandQueue can now perform delete commands without modifying its code at all. That is, its behavior was extended without having to modify its code. Hence, it was open to extensions, but closed to modification.

ArrayList students = new ArrayList< Student >();
ArrayList admins = new ArrayList< Admin >();  	

The Dependency Inversion Principle states that,

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend on details. Details should depend on abstractions.

Example:

In design (a), the higher level class Payroll depends on the lower level class Employee, a violation of DIP. In design (b), both Payroll and Employee depends on the Payee interface (note that inheritance is a dependency).

Design (b) is more flexible (and less coupled) because now the Payroll class need not change when the Employee class changes.