The Designer’s Toolbox
SENG 365 — Software Engineering
2026-11-03
Using the Toolbox
What Is a Tool?
A tool is a design principle you can pick up and apply to a decision.
The Tools
Hide and Protect (M2)
| Tool | Ask |
|---|---|
| Hide design decisions | If this decision changes, which clients must change too? |
| Minimize contact points | Could clients do their work through a narrower interface? |
| Make illegal values unrepresentable | Can a type rule out values that mean nothing in the domain? |
| Don’t let references escape | Can a caller mutate state through something I returned or was given? |
Depend on Abstractions (M3)
| Tool | Ask |
|---|---|
| Minimize coupling | How many other parts must I understand to change this one? |
| Program to an interface | Does the client need the concrete class, or just a behaviour? |
| Inject, don’t construct | Who chooses the implementation, and can a test choose differently? |
| Keep interfaces cohesive | Does each client depend only on the operations it uses? |
| Wait for real variation | What evidence says a second implementation will exist? |
See also: YAGNI, Interface Segregation Principle, Single Responsibility Principle
Control State and Identity (M4)
| Tool | Ask |
|---|---|
| Minimize meaningful states | Which states explain behaviour? |
| Prevent illegal transitions | What event must never be accepted in this state? |
| Make dependencies visible | Does global access hide who relies on this object? |
Design for Testability (M5)
| Tool | Ask |
|---|---|
| Isolate nondeterminism | Can a test force the random, timed, or external case? |
| Test through the public interface | Am I weakening visibility just to reach a private method? |
Compose Structure (M6)
| Tool | Ask |
|---|---|
| Prefer composition to inheritance | Will subclasses multiply for every combination of features? |
| Treat parts and wholes uniformly | Must every client branch on whether it has one thing or a group? |
| Talk only to your neighbours | Does this message chain couple me to distant structure? |
See Law of Demeter
Reuse and Inherit (M7)
| Tool | Ask |
|---|---|
| Preserve substitutability | Can every client of the base type use this subtype without surprises? |
| Don’t remove base operations | Does the subtype refuse or hide anything the base promises? |
| Close what you don’t extend | Is extension part of the design, or only an accident of visibility? (final) |
See also Open-Closed Principle, Liskov Substitution Pr.
Course home · Neil Ernst ©️