Software Design
What this domain tests
Design questions ask whether you can decompose a system into modules that are cheap to change and test, and whether you can justify a structure against quality attributes rather than fashion. Expect architectural styles, modularity metrics, interface contracts, and information hiding.
Core rules and concepts
- Cohesion is how strongly the responsibilities inside one module belong together. Best to worst: functional, sequential, communicational, procedural, temporal, logical, coincidental. The target is high cohesion.
- Coupling is how much modules depend on each other. Best to worst: data, stamp, control, common, content. The target is low coupling; content coupling (one module reaching into another's internals) should be eliminated entirely.
- Information hiding (Parnas): each module hides the design decision most likely to change behind a stable interface. Modularity exists to absorb change, not just to split work.
- Architectural styles map to quality attributes: layered (modifiability), pipe-and-filter (reuse, streaming), client-server (centralized data), publish-subscribe (decoupling, latency), microservices (independent deployability, operational cost).
- Interfaces should be narrow, documented, versioned, and expressed as contracts rather than implementation detail.
Worked example
Two modules both read and write a shared global current_user object. Classify the relationship and refactor it.
Reasoning: shared mutable global state is common coupling, and it becomes content coupling if either module writes fields the other treats as its own. Failure modes: a type change to the global breaks every reader at once, tests must construct global state before running, and concurrent execution produces races.
Refactor: each module exposes get_user(id) returning an immutable value object, and callers pass the user as a parameter. The dependency becomes data coupling. Result: modules test in isolation, the change is localized to one file, and the interface survives internal rework.
Traps that cost marks
- Believing high cohesion and high coupling belong together; the target is high cohesion with low coupling.
- Judging a design by the pattern names it uses instead of by measurable quality attributes.
- Choosing an architecture without checking concurrency, security, and deployability drivers.
- Assuming a stamp parameter is data coupling when a whole record is passed for one field.