java-oop-solid-design

# Java OOP & SOLID Design ## Overview Java is chosen precisely when the domain is rich (see java-vs-go-decision). That value is only realized if you model it with real objects that protect their invariants — not anemic data bags with a pile of setters and logic scattered in services. **Core principle:** Objects own their invariants. If a rule about an entity can be violated from outside the entity, the model is broken. ## SOLID, concretely - **S — Single Responsibility:** one reason to change per class. A class that parses HTTP, applies business rules, and writes SQL is three classes. - **O — Open/Closed:** extend behavior via new types/strategies, not by editing a growing `switch`. New payment method → new `PaymentMethod` implementation, not another `case`. - **L — Liskov:** a subtype must honor the supertype's contract. If `Square extends Rectangle` breaks `setWidth`, the hierarchy is wrong — prefer composition. - **I — Interface Segregation:** many small role interfaces over one fat one. A caller that needs `read` shouldn't depend on `write`. - **D — Dependency Inversion:** services depend on interfaces (ports), not concrete adapters. Inject the interface via the constructor. ## Encapsulation over anemic models ```java // ❌ anemic: invariant lives nowhere, anyone can break it class Task { public String title; // no bound enforced public Status status; } task.title = "x".repeat(500); // invalid state, no guard // ✅ rich: the entity enforces its own rule...