Module 1: OOD Foundations & Code Smells

Primary texts: Clean Code (Martin), Refactoring (Fowler), Head First Design Patterns (Freeman & Robson)
Selective support: Good Code, Bad Code (Hansen) and Object-Oriented Analysis, Design and Implementation (Dathan & Ramnath) for pragmatic and academic framings; Design Patterns (GoF) and SICP for abstraction vocabulary only where it sharpens a concept

This guide is the primary teacher. You do not need to read the source books front-to-back to complete this module. You do need to become operationally strong at naming, decomposing, encapsulating, and reasoning about change pressure in object-oriented code.

---

Scope of This Module

This module is not a tour of Clean Code quotes or a SOLID poster. It is where "this class is a mess" becomes a diagnosis with a name, a cause, and a next move.

What it covers in depth:

• cohesion and coupling as the two primary structural forces in OO code
• encapsulation as information hiding, not as "use private fields"
• the SOLID principles as lenses that name specific change-pressure problems
• Liskov substitution as a contract question, not an inheritance trivia question
• naming and function decomposition as first-class design acts
• when comments clarify, when they lie, and when they mask a naming failure
• Fowler's canonical code smell catalog at the method, class, and system level
• bloaters (long method, large class), couplers (feature envy, data clumps), and change-spreading smells (shotgun surgery, divergent change)
• primitive obsession and repeated switches as inputs to polymorphism
• judgment: when a principle actively hurts, and how YAGNI limits speculative generality

What it deliberately does not try to finish here:

• refactoring mechanics step-by-step (Module 2)
• the design pattern catalog (Modules 3-4)
• testing strategy as a separate discipline (Track A continues)
• performance tradeoffs and language-specific OO idioms

This is a vocabulary-and-judgment module. If you can recite "single responsibility" but cannot point at a class and say which responsibility is the second one, you are not done.

---

Before You Start

Answer these closed-book before starting the main path:

1. Name two different reasons the same class might need to change. Would you call that one responsibility or two?
2. Why does "has getters and setters" not, by itself, make a class encapsulated?
3. What is the difference between an abstract class and an abstraction?
4. When can a longer, duplicated block of code be a better choice than a shared helper?
5. Why is a comment that explains what the code does usually a smell?

Diagnostic Interpretation

4-5 solid answers

• You are ready for the full path.

2-3 solid answers

• Continue, but slow down in Cluster 2 (SOLID) and Cluster 3 (naming/functions). The vocabulary will feel familiar; the judgment will not be.

0-1 solid answers

• Work through Cluster 1 and Cluster 3 twice before attempting the SOLID cluster. Design vocabulary is meaningless without a sense of what breaks when structure is bad.

---

What This Module Is For

Software design is how code holds up under change. The rest of Semester 3 assumes you can say things like:

• "This class is doing two unrelated jobs, so every pricing change breaks the reporting test."
• "This subclass violates the superclass's contract, so polymorphism is actively hurting us."
• "This switch repeats in four places; next time a new case arrives, we will miss one."
• "Adding that interface now is speculative; we have one caller and no evidence of a second."

This module builds the language and judgment needed for:

• reading unfamiliar code and identifying structural risk in minutes, not days
• choosing refactor targets based on change pressure instead of aesthetics
• reviewing pull requests with specific, principled feedback
• recognizing when a pattern or principle would add ceremony without removing pain

---

Concept Map

---

How To Use This Module

Work in order. Later clusters assume you have internalized cohesion, coupling, and encapsulation as lenses you can actually apply to code.

Cluster 1: Cohesion, Coupling, and Encapsulation

Order	Concept	Type	Focus
1	Cohesion: A Class Does One Thing Well	PRIMARY	What "related responsibilities" means and why low cohesion is expensive
2	Coupling: Minimize What a Module Needs to Know	PRIMARY	Kinds of coupling and how they propagate change
3	Encapsulation and Information Hiding as Design Goals	PRIMARY	Hiding decisions, not just hiding fields

Cluster mastery check: Can you look at a class and say, in one sentence, what information it hides and from whom?

Cluster 2: The SOLID Principles

Order	Concept	Type	Focus
4	Single Responsibility Principle: Reasons to Change	PRIMARY	Responsibility as "who asks for changes," not "what the code touches"
5	Open-Closed Principle: Extend Without Modifying	PRIMARY	Designing for new behavior without editing stable code
6	Liskov Substitution: Subtype Contracts	PRIMARY	When inheritance lies and why substitutability is a contract, not a rule
7	Interface Segregation: Small, Role-Based Interfaces	SUPPORTING	Clients should not depend on methods they do not use
8	Dependency Inversion: Depend on Abstractions, Not Concretions	PRIMARY	Inverting compile-time dependencies to protect policy from detail

Cluster mastery check: Can you point at a concrete violation in real code and name the letter, the symptom, and a candidate move?

Cluster 3: Naming, Functions, and Readability

Order	Concept	Type	Focus
9	Names Reveal Intent	PRIMARY	Names as compressed documentation and the cost of bad ones
10	Functions Should Do One Thing, at One Level of Abstraction	PRIMARY	Small, single-purpose functions and the stepdown rule
11	Comments: When Needed, When They Lie	SUPPORTING	Good comments, redundant comments, and comments as naming failures

Cluster mastery check: Can you rename a badly named method and delete its comment in the same move, and still produce clearer code?

Cluster 4: Code Smells -- Method and Class Level

Order	Concept	Type	Focus
12	Long Method, Large Class, Feature Envy, Data Clumps	PRIMARY	Bloaters and couplers in Fowler's catalog
13	Primitive Obsession, Switch Statements, Speculative Generality	PRIMARY	Type-code smells and the polymorphism move

Cluster mastery check: Can you name the smell and the refactoring move it implies, without looking anything up?

Cluster 5: System-Level Smells and Design Judgment

Order	Concept	Type	Focus
14	Shotgun Surgery, Divergent Change, and Parallel Inheritance Hierarchies	SUPPORTING	Change-spreading smells across modules
15	When NOT to Apply a Principle: YAGNI vs Premature Abstraction	PRIMARY	When SOLID hurts, and how to resist speculative design

Cluster mastery check: Can you describe one real situation where applying a SOLID letter would have made the code worse?

Then work these practice pages:

Order	Practice path	Focus
1	Cohesion, Coupling, and SOLID Lab	Structural reasoning and principle identification
2	Naming and Function Refactor Workshop	Rename, extract, and inline moves on real snippets
3	Smell Identification Clinic	Labeling, prioritizing, and proposing moves
4	Code Katas	Six before/after refactor katas

Use Module Quiz after the concept and practice path. Use Reference and Selective Reading and Learning Resources only for targeted reinforcement.

---

Learning Objectives

By the end of this module you should be able to:

1. Define cohesion and coupling, identify low/high examples in real code, and explain the change-cost consequences.
2. Distinguish encapsulation from "fields are private" and describe what decision a class hides.
3. State each SOLID letter in one sentence and point at a concrete violation in a real snippet.
4. Explain Liskov substitution as a contract claim and name at least one classic violation (e.g., Square extends Rectangle).
5. Rename a badly named method or variable and justify the change in terms of revealed intent.
6. Extract a function or class to reduce a long method or large class while preserving behavior conceptually.
7. Name at least 10 smells from Fowler's catalog and pair each with at least one refactoring move.
8. Recognize shotgun surgery, divergent change, and parallel inheritance hierarchies as change-pressure signals.
9. Argue against applying a principle when evidence for future change does not exist (YAGNI).
10. Write a short design critique of a ~200-line module that prioritizes fixes by cost of next change.

---

Outputs

• a smell catalog card deck with at least 15 smells, each paired with one refactoring move
• one SOLID critique of a real open-source or personal file, with at least one concrete violation per letter you find
• one before/after refactor note for a long method and a large class, written as a pull-request-style summary
• one annotated naming log: 10 renames with the reason each reveals more intent
• one "when not to" memo naming at least three situations where applying a principle would have hurt
• one mistake log with at least 12 tags such as mislabeled cohesion, private-is-not-encapsulated, OCP without a real extension pressure, or YAGNI violation: speculative interface
• one short memo connecting Module 1 vocabulary to Module 2 (refactoring) and Modules 3-4 (patterns)

---

Completion Standard

You have completed Module 1 when all of these are true:

• you can name the smell, the cause, and a candidate move on unfamiliar code in under two minutes per case
• you can distinguish private-field encapsulation from real information hiding in your own words
• you can cite a concrete SOLID violation instead of gesturing at "it violates SRP"
• you can defend not refactoring when the evidence for future change is weak
• you can write a rename that makes a three-line comment unnecessary

If the answer looks familiar but you cannot point at the code, the module is not complete.

---

Reading Policy

• Concept pages are the main path.
• Local book chunks are selective reinforcement, not a second syllabus.
• Read only if stuck means try the concept page, self-check, and drill first.
• Optional deep dive means additional nuance or exercise volume, not required progression.
• Because this module is judgment-heavy, written design critiques are required, not optional enrichment.

---

Suggested Weekly Flow

Day	Work
1	Concepts 1-3 and one cohesion/coupling critique of real code
2	Concepts 4-6 and three SOLID-violation labels on real code
3	Concepts 7-8 and one dependency-direction sketch for a current project
4	Concepts 9-11 and a naming log with at least 10 renames
5	Concepts 12-13 and a smell-hunt on a 200-line file
6	Concepts 14-15, practice pages 1-2, and one "when not to" memo
7	Practice pages 3-4, quiz, and mistake-log cleanup

---

Reference

If you need exact links into the local chunked books, use Reference and Selective Reading.

---

Rich Learning Pages

Worked Examples | Guided Labs | Case Studies | Mistake Clinic | Reading Guide | Capstone Thread