Modular Design: Building Programs from Parts

Decomposing a problem into modules and classes

A module is a separate part of a program with one job. To decompose a problem:

1. Write what the whole program must do.
2. List the main things (nouns) in the problem: members, books, loans. Each can become a class that holds its data and its methods.
3. List the main jobs (verbs): add, search, issue, return. Each becomes a method or function.
4. Draw a structure chart (a tree): the program at the top, modules below, subprograms below them.

Two quality checks: high cohesion (everything in a module belongs to one job) and low coupling (modules depend on each other as little as possible).

Functional decomposition in subprogram design

Functional decomposition is top-down design: take a task and break it into smaller sub-tasks, then break those again, until each piece is small enough to write as one short subprogram (function, procedure or method).

issueBook(memberId, bookId)
  ├─ checkMember(memberId)
  ├─ checkAvailable(bookId)
  ├─ recordLoan(memberId, bookId, dueDate)
  └─ printSlip()

Each subprogram has clear parameters (inputs) and a return value (output). Good rules: one task per function, a name that is a verb, usually less than a screen long, and no hidden use of global variables.

Programmers also use stubs (empty placeholder functions) to test the top level before the lower parts are written.

Data encapsulation in program design

Encapsulation means putting data and the code that uses it together, and hiding the data from the outside. In most languages you mark fields private and give public methods (the interface).

class Account {
  private double balance;
  public void deposit(double x) { if (x > 0) balance += x; }
  public double getBalance() { return balance; }
}

Nobody outside can set the balance to −500, because the only way in is deposit(), which checks the value. Benefits: data stays valid, the inside can be changed later without breaking other code, and each module is easier to understand.

Reusability in program design

Reusability means writing a module once and using it in many places or programs. Ways to make code reusable:

• Use parameters instead of fixed values (a sort(list) that works for any list).
• Keep modules general and independent (low coupling).
• Put shared code in a library or package; use inheritance or composition for classes.
• Document the interface: what goes in, what comes out.

Reuse saves time, cuts bugs (tested code is used again), and keeps programs consistent. Almost every app uses library modules for things like dates, maths and networking.

Try it

Unplugged: write "Make breakfast" at the top of a page. Break it into 3 modules, then each into 2–3 steps. Circle any step you could reuse for "Make lunch".

In the 3D: press Split twice and count the pieces (1 → 3 → 6). Then press Encapsulate and Reuse.

Key formulas and definitions

• Module: a separate part with one job
• Functional decomposition: task → sub-tasks → subprograms (top-down)
• Encapsulation: private data + public methods (interface)
• Good design: high cohesion, low coupling
• Reusability: write once, use many times (libraries, parameters)
• Structure chart: a tree of modules and subprograms

Worked examples

Common mistakes

• Making one huge function that does everything. Split it so each function has one task.
• Using global variables to share data between modules. Pass parameters and return values instead.
• Making all fields public. That breaks encapsulation; keep data private and give methods.
• Splitting too far, into dozens of one-line functions with unclear names. Stop when each piece is clear and testable.