Reference and Selective Reading
You do not need to read the source books front-to-back for this module. Use the concept pages and practice pages first. Open these local chunks only when you need alternate exposition, more worked examples, or the canonical move for a specific refactor.
Source Roles
| Source | Role | Why it is here |
|---|---|---|
| Clean Code (Martin) | Primary teaching source | Best arc for naming, functions, comments, classes, and the alternate smell catalog |
| Refactoring, 2nd ed. (Fowler) | Primary teaching source | Canonical smell catalog and refactoring moves; read the chunk that matches the move, not whole chapters |
| Head First Design Patterns (Freeman & Robson) | Primary / approachable OO principles | Best first pass on OCP, loose coupling, and SRP with worked examples |
| Good Code, Bad Code (Hansen) | Selective support | Pragmatic second opinion on interfaces, DI, comments, and cross-class coupling |
| Object-Oriented Analysis, Design and Implementation (Dathan & Ramnath) | Selective support | Academic framing of cohesion, coupling, ISP, and LSP with contract-style reasoning |
| Design Patterns (GoF) | Reference only | Introduction chapters for design-for-change vocabulary; pattern catalog is Modules 3-4 |
| SICP | Background only | Use only for abstraction-barrier vocabulary when encapsulation is not clicking |
Read Only If Stuck
Cohesion, Coupling, and Encapsulation
- Clean Code: Maintaining cohesion
- OOAD: Cohesion and coupling
- OOAD: Modular design and encapsulation
- Head First: The Power of Loose Coupling
- Refactoring: Encapsulate Variable
- Refactoring: Encapsulate Collection
- Refactoring: Encapsulate Record (Part 1)
- Clean Code: Data abstraction
- Design Patterns: Decoupling senders and receivers
- Good Code, Bad Code: Classes (Part 1)
The SOLID Principles
- Clean Code: Single Responsibility Principle
- Head First: The Single Responsibility Principle
- Head First: The Open-Closed Principle
- Design Patterns: Designing for change (Part 1)
- OOAD: Why Pixel is not SolidRectangle / LSP
- OOAD: The Interface Segregation Principle
- Good Code, Bad Code: Interfaces
- Good Code, Bad Code: Class inheritance can be problematic
- Good Code, Bad Code: Design with Dependency Injection in mind
- Clean Code: Systems / Dependency Injection
Naming, Functions, and Readability
- Clean Code: Meaningful Names -- introduction
- Clean Code: Pronounceable names
- Clean Code: Interfaces and implementations (naming)
- Clean Code: Add meaningful context
- Clean Code: Functions -- Small, blocks and indenting
- Clean Code: Functions -- Do one thing, top-to-bottom
- Clean Code: Functions -- Switch statements and arguments
- Clean Code: Functions -- Side effects and error handling
- Clean Code: Functions -- Don't repeat yourself
- Clean Code: Comments -- do not make up for bad code
- Clean Code: Comments -- redundant to scary noise
- Clean Code: Comments -- use a function instead
- Good Code, Bad Code: Comments are a poor substitute for names
- Good Code, Bad Code: Use comments appropriately
- Good Code, Bad Code: Functions
- Refactoring: Extract Function (Part 1)
- Refactoring: Extract Function (Part 2)
- Refactoring: Inline Function
- Refactoring: Change Function Declaration
- Refactoring: Mysterious Name smell
Method- and Class-Level Smells
- Refactoring: Long Function to Long Parameter List
- Refactoring: Global Data to Mutable Data
- Refactoring: Divergent Change to Feature Envy
- Refactoring: Data Clumps to Repeated Switches
- Refactoring: Loops to Message Chains
- Refactoring: Middle Man to Alternative Classes
- Refactoring: Data Class and Comments
- Refactoring: Replace Primitive with Object
- Refactoring: Extract Class
- Refactoring: Introduce Parameter Object
- Refactoring: Replace Conditional with Polymorphism (Part 1)
- Refactoring: Replace Conditional with Polymorphism (Part 2)
- Clean Code: Smells -- G5 to G11
- Clean Code: Smells -- G12 to G18
- Good Code, Bad Code: Caring too much about other classes
System-Level Smells and Design Judgment
- Refactoring: Divergent Change to Feature Envy
- Refactoring: Move Function (Part 1)
- Refactoring: Move Function (Part 2)
- Refactoring: Combine Functions into Class
- Refactoring: Extract Superclass and Collapse Hierarchy
- Refactoring: Replace Subclass with Delegate (Part 1)
- Refactoring: Refactoring, Architecture, and YAGNI
- Refactoring: Problems with Refactoring (Part 2)
- Refactoring: When Should We Refactor (Part 1)
- Good Code, Bad Code: When layers get too thin
Optional Deep Dive
- Design Patterns: Putting reuse mechanisms to work
- Design Patterns: Delegation
- Design Patterns: Class versus interface inheritance
- OOAD: Polymorphism and dynamic binding (Part 1)
- SICP: Abstraction barriers
- SICP: Procedures as black-box abstractions
- Clean Code: Successive refinement (Args example)
Concept-to-Source Map
| Concept page | Best source if stuck | Why this source |
|---|---|---|
| Cohesion: A class does one thing well | Clean Code: Maintaining cohesion | Operational description of how cohesion interacts with class count |
| Coupling: Minimize what a module needs to know | Head First: The Power of Loose Coupling | Worked example that makes the kinds of coupling visible |
| Encapsulation and information hiding | OOAD: Modular design and encapsulation | Clearest information-hiding framing |
| Single Responsibility Principle | Clean Code: SRP | Most compact statement + bridge to cohesion |
| Open-Closed Principle | Head First: OCP | Shortest credible walkthrough with code |
| Liskov Substitution | OOAD: LSP and Pixel vs SolidRectangle | Strong non-Square example with contract reasoning |
| Interface Segregation | OOAD: ISP | Precise ISP statement in a small system context |
| Dependency Inversion | Good Code, Bad Code: Design with DI in mind | Pragmatic treatment that separates principle from mechanism |
| Names Reveal Intent | Clean Code: Meaningful Names -- introduction | Canonical rules, most directly usable |
| Functions Should Do One Thing | Clean Code: Functions -- Do One Thing | Operational statement + stepdown rule |
| Comments: when needed, when they lie | Clean Code: Comments do not make up for bad code | Best framing of comments as liability |
| Long Method, Large Class, Feature Envy, Data Clumps | Refactoring: Divergent Change to Feature Envy | Canonical catalog entries side-by-side |
| Primitive Obsession, Switch, Speculative Generality | Refactoring: Data Clumps to Repeated Switches | Three smells in one chunk with the move list |
| Shotgun Surgery, Divergent Change, Parallel Hierarchies | Refactoring: Divergent Change to Feature Envy | Side-by-side definitions; Fowler's original pair framing |
| YAGNI vs Premature Abstraction | Refactoring: Architecture, YAGNI, and refactoring | Most explicit local statement of the tradeoff |