What is modules that do too much?

A module should have high cohesion (one clear job); a "do-everything" module is as hard to maintain as no modules at all.

What are leaky interfaces?

If callers depend on a module's internals, you cannot change those internals freely - keep the interface the only point of contact.

What is tight coupling?

Modules that depend heavily on each other's internals must change together, defeating the point; aim for low coupling.

SingaporeComputer ScienceSyllabus dot point

How do we break a large problem into manageable parts, and why does hiding detail make software better?

Apply decomposition, modularity and abstraction to structure software, explaining the benefits for maintenance and reuse

A focused answer to the H2 Computing outcome on decomposition and abstraction. Breaking problems into modules, the role of interfaces, information hiding through abstraction, and the benefits for maintainability and reuse.

Generated by Claude Opus 4.88 min answerUpdated 2026-06-06

Reviewed by: AI editorial process; not yet individually human-reviewed

Have a quick question? Jump to the Q&A page

Jump to a section

What this dot point is asking
The answer
Examples in context
Try this

What this dot point is asking

SEAB wants you to apply decomposition, modularity and abstraction to structure software, and explain why they help with maintenance and reuse. The central idea is that large problems become tractable only when split into small parts that hide their internal detail behind simple interfaces, so each part can be built, understood and changed independently.

The answer

Decomposition

Decomposition breaks a problem into smaller sub-problems, each simpler to solve. A program to "run a library" decomposes into manageable tasks - register members, search the catalogue, issue loans, calculate fines - which can be tackled one at a time. This is the first step in managing complexity.

Modularity

A module is a self-contained unit (a function, class or file) that performs one well-defined job. Building software from modules means each:

does one thing (high cohesion),
depends as little as possible on others (low coupling),
and is reached only through its interface.

The interface is the module's public contract: the inputs it takes, the outputs it gives, and the operations it exposes - how to call it, not how it works inside.

Abstraction and information hiding

Abstraction hides unnecessary detail, exposing only the essentials. Information hiding means a module keeps its internal data and implementation private, so callers depend only on the stable interface:

# You call sorted(data) knowing WHAT it does,
# not HOW (which sort algorithm it uses internally).
result = sorted(data)

You drive a car with a steering wheel and pedals without knowing the engine's internals; you call a library without knowing its code. Layered abstractions - hardware, operating system, libraries, application - are what make whole systems comprehensible.

Why it helps: maintenance and reuse

These principles pay off directly:

Maintainability - a fix or change is confined to one small module, understood and tested in isolation, not tangled through the whole program.
Reuse - a self-contained module can be used again in other programs.
Parallel development - different people can build different modules at once, agreeing only on interfaces.
Freedom to change internals - as long as the interface holds, a module's insides can be rewritten (a faster algorithm) without breaking callers.

Worked example

Restructure a single long script that reads orders, calculates totals and prints an invoice into a modular design, and state the benefit.

Step 1: Decompose into distinct responsibilities

The script does three jobs: read order data, calculate the total (with tax and discount), and format the invoice for output. Each becomes its own function or module.

Step 2: Define clear interfaces

read_orders(filename) returns a list of orders; calculate_total(orders) returns a number; format_invoice(orders, total) returns a string. Each is called only through these signatures.

Step 3: Hide internal detail

The caller of calculate_total does not see how tax or discounts are applied internally - only that it returns the total. The rule can change inside without touching the other modules.

Step 4: State the benefit

Each module can be tested in isolation (feed calculate_total known orders, check the total), reused elsewhere, and maintained independently. A change to the invoice layout touches only format_invoice, not the calculation or reading logic.

Examples in context

Example 1. The standard library. When you call a sorting or square-root function, you rely on its interface and ignore its implementation. This abstraction lets the language maintainers improve the algorithm in a new release without any change to the millions of programs that call it - the stable interface is the contract.

Example 2. A team building an app. A mobile app is split into modules for networking, storage, user interface and business logic, each with a defined interface. Four developers work in parallel, agreeing only on those interfaces, and a bug in storage is fixed without disturbing the user interface - decomposition and information hiding making the teamwork possible.

Try this

Q1. Define abstraction in the context of software. [1 mark]

Cue. Hiding unnecessary detail, exposing only the essential features needed to use something - what it does, not how.

Q2. Give two benefits of structuring a program into modules. [2 marks]

Cue. Easier maintenance (changes confined to one module) and reuse (self-contained modules used elsewhere); also parallel development and independent testing.

Q3. What is the interface of a module? [2 marks]

Cue. Its public contract - the inputs, outputs and operations it exposes for other code to call - without revealing its internal implementation.

Exam-style practice questions

Practice questions written in the style of SEAB exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.

Original6 marks(a) Define decomposition and abstraction. (b) A monolithic 500-line program is to be restructured into modules. Explain two benefits of doing so. (c) What is meant by the interface of a module?

Show worked answer →

(a) Decomposition is breaking a problem into smaller, more manageable sub-problems that can be solved separately. Abstraction is hiding unnecessary detail, exposing only the essential features needed to use something, so the user works at a simpler level.

(b) Two benefits of modularising the program:

Easier maintenance. A change or bug fix is confined to one small module, which can be understood, edited and tested in isolation, rather than reasoning about 500 interdependent lines.
Reuse and parallel work. A self-contained module can be reused in other programs and tested independently, and different developers can work on different modules at the same time.

(c) The interface of a module is the set of inputs, outputs and operations it exposes - how other code calls it (its function signatures or public methods) - without revealing how it works inside.

Markers reward correct definitions of decomposition and abstraction, two genuine modularity benefits, and the interface as the public contract hiding internal detail.

Original5 marksExplain how abstraction (information hiding) reduces complexity in a large system, using the example of a function or library that you call without knowing its internal implementation.

Show worked answer →

Abstraction lets you use a component through a simple interface while its internal workings are hidden. You only need to know what it does and how to call it, not how it achieves it.

Example: calling a built-in sorted(list) function. You provide a list and receive it sorted; you do not need to know whether it uses merge sort, quicksort or a hybrid internally. The complexity of the algorithm is hidden behind the simple interface "give me a list, get back a sorted list".

This reduces complexity because each part of the system can be understood and used in isolation. Changes inside the component (a faster sort) do not affect callers as long as the interface stays the same, and a programmer holds far less detail in mind at once. Layered abstractions (hardware, operating system, libraries, application) are what make large systems tractable.

Markers reward the what-not-how idea, a concrete example of calling something without knowing its implementation, and the benefits: reduced cognitive load and freedom to change internals behind a stable interface.