Semester 3: Software Design & Patterns
Year 1 - Fundamentals | Phase 3 | Weeks 32-37 | 6 weeks
This semester turns "I can write code" into "I can shape code under change." The focus is not pattern trivia. The focus is learning to diagnose design pressure, refactor safely, choose patterns only when they earn their cost, and explain design decisions clearly in review.
Semester Goal
By the end of this semester, you should be able to:
- identify structural problems in medium-sized code without vague language
- protect refactors with tests and smaller, reviewable steps
- apply the core behavioral, structural, and creational patterns deliberately
- review code with evidence and tradeoff reasoning instead of taste
- produce design notes, ADRs, and PR summaries that another engineer can actually use
If you still reach for abstractions before you can name the change pressure, you are not done.
Prerequisites
Complete Semester 2 first. You should already be comfortable with:
- writing and debugging non-trivial code
- reading unfamiliar code without freezing on syntax
- basic testing habits
- complexity analysis and decomposition from the algorithms phase
Module Sequence
| # | Module | Why it matters |
|---|---|---|
| 1 | OOD Foundations & Code Smells | Learn the vocabulary of cohesion, coupling, encapsulation, naming, and smell recognition |
| 2 | Refactoring Techniques | Learn how to change code safely instead of performing risky rewrites |
| 3 | Behavioral Patterns | Learn how to model variation, actions, and notifications cleanly |
| 4 | Structural & Creational Patterns | Learn how to shape object construction, interfaces, and layered behavior |
| 5 | Applied Design & Code Review | Learn to integrate the semester into real review, documentation, and tradeoff decisions |
How to Work This Semester
Use each module in the same order:
- Read the module
index.mdand follow the concept sequence. - Complete the practice work before touching the quiz.
- Keep a running mistake log for smells misidentified, refactor steps skipped, and patterns misapplied.
- Add short design notes after every substantial exercise: what changed, why it changed, what pressure justified it, and what you deliberately did not abstract yet.
- Reuse one codebase across the semester when possible so the project work compounds instead of resetting every week.
Weekly Arc
| Week | Main outcome | Primary module focus |
|---|---|---|
| 32 | Diagnose design problems precisely | Module 1 |
| 33 | Refactor in safe, test-backed steps | Module 2 |
| 34 | Handle runtime variation and behavior composition | Module 3 |
| 35 | Control construction, wrapping, and adaptation | Module 4 |
| 36 | Review code and write design rationale | Module 5 |
| 37 | Finish the project, cumulative review, checkpoint, and exam | Semester-level assessments |
Core Deliverables
- one running smell-and-refactor log with concrete examples from your own code
- one pattern cookbook with short "when to use / when to avoid" notes
- one plugin-style or extension-oriented application evolved across the semester
- one set of code review notes using a rubric of correctness, clarity, design, and tests
- one small ADR or design memo attached to the semester project
The semester is complete only when the artifacts show judgment, not just completion.
Completion Contract
Do not advance to Semester 4 unless all of the following are true:
- you can point at a smell and name a likely refactor move without guessing
- you can explain why a pattern is warranted in a specific piece of code
- you can show tests or characterization checks that protected a non-trivial refactor
- you can critique code in writing without relying on "cleaner" or "better design" as empty phrases
- you can produce a project branch or commit history that shows deliberate, incremental design work
Semester Assessments
- Semester Project: one integrated refactor, pattern, and reviewable-delivery project
- Checkpoint Gate: readiness standard before moving into systems programming
- Cumulative Review: interleaved review across Semesters 0-3
- Semester Exam: closed-book reasoning on smells, refactors, patterns, and review judgment
Suggested Study Rhythm
- 4 days per week on module concepts and practice
- 1 day per week on project evolution
- 1 day per week on review, spaced repetition, and design notes
- 1 day per week on cumulative recall and cleanup of weak spots
Small, defensible steps matter more than marathon sessions. This semester rewards repeated contact with real code.
Capstone Throughline
Every semester must leave behind evidence that can survive into the final capstone defense.
- Artifact carried forward: refactor log and design review.
- What to preserve: Preserve before/after examples, smell diagnosis, review comments, and the reasoning behind each design improvement.
- Module threads: Module 1: OOD Foundations & Code Smells, Module 2: Refactoring Techniques, Module 3: Behavioral Patterns, Module 4: Structural & Creational Patterns, and Module 5: Applied Design & Code Review.
- Defense prompt: In Semester 10, explain how this semester's artifact changed a capstone decision, reduced a risk, or made the final system easier to defend.
Model Artifact Calibration
Use the refactor PR/writeup model artifact when preparing reviewable design-change evidence.