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 (Tom Long) 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 and information hiding, including ownership beyond 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)
• a full performance course or language-specific OO catalogue; this module still records representation and boundary costs

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

Use the prerequisite diagnostic: trace objects and aliases, functions, exceptions and iterators. SOLID vocabulary and design judgment are learning outcomes here, not entry requirements. Repair the specific prerequisite that blocks you; the offline labs use Python 3.10+ and the standard library.

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."
• "This interface has no demonstrated testing, ownership or compatibility benefit; its carrying cost needs justification."

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 improve a name while preserving its contract, and decide which comments remain useful?

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 observed signal, a plausible cause, a candidate move and evidence for leaving it alone?

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?

Cluster 6: Contracts, Ownership, and Design Evidence

• State-Machine Contracts and Failure Atomicity
• Ownership, Aliasing, and Immutable Snapshots
• Composition, Functional Cores, and Extension Axes
• Compatibility and Evidence for Design Changes

Cluster mastery check: Can you preserve a public state-machine contract across two representations, explain snapshot ownership, and distinguish a refactor from an intentional behavior change?

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	Contract and boundary implementation tasks

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. Evaluate an extraction using public traces, failure behavior, mutation and iterator consumption.
7. Use smell vocabulary to form testable diagnoses and compare candidate moves with leaving code unchanged.
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.
11. Specify failure-state preservation and compare two representations against a public transition model.
12. Distinguish shallow copies, immutable snapshots and live views using an aliasing counterexample.
13. Compare functional composition and object boundaries under two extension axes.
14. Separate a behavior-preserving refactor from an intentional repair or compatibility migration.

---

Outputs

Keep one evidence notebook linking P01–P20, four runnable labs, three design experiments, A01–A10 independent attempts, and the project. Reuse the same valid artifact across competencies; do not manufacture mistakes, refactors, renames or comment deletions to meet quotas. Include contracts, before/after observations, rejected alternatives and assistance.

Completion Standard

Meet every C01–C10 gate in the assessment map, reproduce the labs and project, and defend a changed case after 7–14 days. Vocabulary, class counts, speed and aggregate percentages cannot substitute for missing behavioral evidence. Self-assessment and independent review must be labelled separately. The module is an authored candidate; independent review and learner pilots remain pending. It does not promise a percentile or professional rank.

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 Workload and Sequence

Plan 88–127 focused hours, an author estimate awaiting learner pilots.

Phase	Hours	Evidence
Diagnostic, original 19 lessons and selective reading	24–34	Contract traces and retrieval notes
Twenty practice tasks	16–22	Independent attempts and checked repairs
Four runnable labs	16–24	Implementations, bounded model checks and explanations
Three design experiments	6–9	Predictions, observations and limitations
Assessment, repair and delayed recheck	6–10	Every competency demonstrated
Bounded project and defense	12–16	Contract-preserving core plus declared migration
Construction/semantics clinic	8–12	Three new lessons, experiment, change task and DS1–DS4

Work through clusters 1–6, interleaving their practice and lab tasks. At ten hours weekly this is roughly 9–13 study weeks; delays, prerequisite repair and optional full-book reading add time. The former seven-day schedule is retired. Module 2 continues with refactoring mechanics; do not rush this gate to match legacy dates.

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

Construction and semantics continuation

Complete the construction clinic after cluster 6. Its DS1–DS4 evidence is required alongside existing C01–C10 gates; original labs remain. The 8–12 additional hours are explicitly included in the updated module/semester allocation.