Phase 03: OOP & Design Patterns in Modern Java

Timeline: Months 4-5 (Weeks 13-20) Estimated Effort: 8 weeks at 10-15 hours/week (80-120 hours total)

Why This Phase Exists

You know Java syntax again. You can solve DSA problems. Now the question that separates a mid-level engineer from a senior one: can you shape a system so it survives change? OOP is not “use classes.” It’s a set of trade-offs about coupling, cohesion, and where you put the knobs.

This phase is honest about what has aged well and what has not. The 2004-era OOP orthodoxy — deep inheritance hierarchies, patterns applied for their own sake, “everything is an object” — is not how modern Java teams work. Java 21 has records, sealed types, and pattern matching, which quietly kill or diminish several classic Gang of Four patterns. Spring’s dependency injection kills Singleton. Functional interfaces kill Command. You need to know which patterns still earn their keep and why.

The rule for this phase: every pattern you learn, you must be able to name a case where you would NOT use it. Patterns are tools, not virtues.

What You’ll Cover

#

Topic

File

Focus

1

OOP first principles

01_oop_first_principles.md

Encapsulation, inheritance, polymorphism, abstraction — with composition-over-inheritance argued honestly

2

SOLID in practice

02_solid_in_practice.md

SRP, OCP, LSP, ISP, DIP with Java examples and the traps people fall into

3

GoF patterns — alive & dead

03_gof_patterns_alive_and_dead.md

Which patterns still matter in Java 21 and which are obsolete

4

Records, sealed, pattern matching

04_records_sealed_pattern_matching.md

Modern algebraic data types in Java, the killer combo

5

Refactoring & code smells

05_refactoring_and_code_smells.md

The 12 smells you’ll see in enterprise Java and the moves that fix them

6

Phase projects

projects.md

Refactor a smelly 400-line class, build a plugin system, model a real domain

Weekly Schedule

Week

Focus

Target

1

OOP first principles, immutability

Read file 01, write 5 small classes demonstrating each principle

2

SOLID

Read file 02, refactor one of your Phase 01 programs against SOLID

3

GoF patterns that still matter

Read file 03, implement Strategy, Builder, Adapter, Decorator from scratch

4

Records, sealed types, pattern matching

Read file 04, model a small ADT (Result type, tree of shapes)

5

Code smells and refactoring moves

Read file 05, take the starter smelly class and start refactoring

6

Project A: legacy refactor

Finish the before/after commit history in a public repo

7

Project B: plugin system with sealed interfaces

Working expression evaluator or command dispatcher

8

Project C: domain model

Library/hotel/e-commerce model — records, sealed types, 3+ patterns

What You’re Building Toward

By the end of Phase 03 you should be able to:

  • Take a 400-line God class and refactor it into a clean modular design in under 30 minutes without breaking behavior

  • Explain, for every GoF pattern, whether it’s still worth using in Java 21 — and why

  • Model a domain using records + sealed interfaces + pattern matching without reaching for inheritance

  • Write a class where every field is final, every collection returned is unmodifiable, and every constructor validates invariants

  • Read a class and identify the top 3 smells in it within 2 minutes

  • Apply the Strategy pattern (or its lambda equivalent) without over-engineering

  • Justify a design choice using SOLID as a decision aid, not as dogma

Exit Criteria

You’re ready for Phase 04 when:

  1. Refactoring speed: Given a smelly 300-500 line Java class, you can produce a cleaner design in under 30 minutes with tests still passing

  2. Pattern judgment: You can list at least 4 GoF patterns that are dead or diminished in modern Java, and explain what replaced them

  3. Modern idioms: Your code uses record, sealed interface, and switch pattern matching where they fit — you’re not still writing 40-line data classes

  4. SOLID as tool: You can point to real code and say “this violates OCP because ___” without sounding like a textbook

  5. Composition reflex: When you reach for extends, you pause. Nine times out of ten you rewrite it as composition

  6. Three projects shipped: The legacy refactor, the plugin system, and the domain model are all in your GitHub with README files that a hiring manager can read

Books & Resources

Primary — read cover to cover:

  • Effective Java, 3rd Edition (Joshua Bloch, 2018). Yes, it’s from 2018 and predates records/sealed types, but items 15-27 on classes and interfaces, and 42-48 on lambdas/streams, are still the canonical reference. Community verdict on Reddit and coderanch in 2025: still valid, just supplement with a Java 17/21 features guide.

  • Refactoring, 2nd Edition (Martin Fowler, 2018). The Java-in-JavaScript examples read fine as Java. This is the smell catalog.

For patterns — pick ONE, not both:

  • Head First Design Patterns, 2nd Edition (2020) — friendlier, more memorable, uses Java. Best if patterns are new to you.

  • Refactoring.Guru (refactoring.guru) — free, well-illustrated, cross-language. Better as a reference than a first read.

  • Skip the original Gang of Four book unless you enjoy academic prose. Its C++/Smalltalk examples don’t translate cleanly.

Modern Java data-oriented programming:

  • Brian Goetz, Data-Oriented Programming in Java (article on inside.java, 2022). Short. Read it twice.

  • Nicolai Parlog’s YouTube channel and Inside Java Newscast for Java 21+ idioms.

What Most People Get Wrong

  • They treat patterns as goals, not tools. Nobody hires you because you used Visitor. They hire you because your code is easy to change. If a pattern doesn’t make the code easier to change, skip it.

  • They over-decompose in the name of SRP. “One reason to change” becomes “one method per class.” That’s not SRP, that’s chaos. SRP is about cohesion, not size.

  • They still write JavaBeans. Getters, setters, no-arg constructor, mutable everything — because “Spring needs it.” Most Spring stacks in 2025 handle records fine. Stop writing 1990s Java.

  • They confuse inheritance with polymorphism. You can have polymorphism without inheritance (via interfaces or sealed types). The moment you extends AbstractFooBase, you’ve coupled to a hierarchy you’ll regret.

Return to ../README.md · Next: 01_oop_first_principles.md