A Philosophy of Software Design Part 3 - Information Hiding
Protects Design Decisions A Philosophy of Software Design treats
software design less as architectural theater and more as the
daily work of managing complexity.
This part covers Chapter 5 Information Hiding (and Leakage) and
Chapter 6 General-Purpose Modules are Deeper.
It uses only short key phrases from the source and turns the
reading into summary, interpretation, and application.
The guiding question is: What must a module hide in order to
become deep?
How to use this note This is part 3 of a ten-part reading of A
Philosophy of Software Design.
The scope is Chapter 5 Information Hiding (and Leakage) and
Chapter 6 General-Purpose Modules are Deeper.
The operating principle remains: book notes are storage; insight
cards are currency.
L0 · Entry Core sentence: Information hiding is not the act of
concealing code; it is the act of concealing design decisions
likely to change.
Why read this: As AI tools and automation make code faster to
produce, I want sharper standards for code that remains
understandable and changeable.
Initial hypothesis: If encapsulation is reduced to field access
control, module boundaries become shallow.
This section shows that the hidden thing is often a decision,
not merely data.
Author context: John Ousterhout is a computer scientist known
for work in operating systems, distributed systems, Tcl/Tk, and
software design education at Stanford.
Scope: Chapter 5 Information Hiding (and Leakage) and Chapter 6
General-Purpose Modules are Deeper L1 · Captures Short phrase ·
design "information hiding" This principle moves change-prone
decisions inside a module.
If I do not ask what may change, I cannot know what to hide.
Short phrase · design "information leakage" This names the state
where one decision spreads across several modules.
Leakage expands the scope of edits and blurs the scope of tests.
Short phrase · design "general-purpose" This points toward APIs
not tied too tightly to one caller.
Generality is useful when it helps information hiding, not when
it predicts imaginary futures.
Copyright boundary This public note does not reproduce long
source passages.
It uses chapter-level concepts and short phrases as anchors,
then provides transformative summary and commentary.
L2 · Map Range Summary Main claim --- ------ ---------
------------ 1 Information hiding Keeps important decisions and
details inside a module Users can keep using the module while
knowing less 2 Information leakage Spreads the same knowledge
across several locations Change becomes expensive in proportion
to leaked knowledge 3 Temporal decomposition Splitting by task
order can leak information Process steps are not always good
module boundaries 4 General-purpose API A somewhat more general
interface can make a module deeper Caller-specific code often
widens the interface 5 Over-generalization Designing for
imagined futures can add complexity Generality must still be
validated by present needs Argument in one paragraph:
Information hiding is not the act of concealing code; it is the
act of concealing design decisions likely to change.
If encapsulation is reduced to field access control, module
boundaries become shallow.
This section shows that the hidden thing is often a decision,
not merely data.
In practice, this moves review questions from "does it work?"
toward "what must the next reader know in order to change it
safely?" Design is not a separate ceremony; it is embedded in
names, boundaries, exceptions, comments, layers, and performance
choices.
L3 · Insight Cards A Philosophy of Software Design - I3.1
Information hiding asks which decision may change, not merely
which field is private A Philosophy of Software Design - I3.2
Information leakage is duplicated knowledge, often quieter than
duplicated code A Philosophy of Software Design - I3.3 Useful
generality comes from simplifying the current interface, not
from predicting every future L4 · Production Board Outputs Blog
draft: Part 3 as "Information Hiding Protects Design Decisions"
Code review question: What must a module hide in order to become
deep?
Insight card: Information hiding asks which decision may change,
not merely which field is private L5 · Review Connections: This
connects directly to Parnas-style module decomposition:
decisions likely to change become candidates for module
boundaries.
Open questions: Where does this part's red flag appear most
clearly in my current codebase?
What check would an AI coding agent need in order to apply this
principle reliably?
Final takeaway: A good module is not a wall around code; it is a
workbench that gathers change-prone decisions in one place.