Design Philosophy: Object-Oriented Design

OO principles as thinking tools for code organization, module boundaries, and component relationships.

Core Premise

Object-oriented design is not about classes and inheritance. It is about managing the cost of change by localizing decisions behind stable interfaces. Every OO principle exists to answer one question: when a requirement changes, how many places in the code must change with it?

Good OO design means a single requirement change touches one or two files. Bad OO design means shotgun surgery across a class hierarchy that was supposed to make things "extensible."

The principles below are thinking tools, not commandments. Each one has a failure mode that is just as common as the problem it solves. Know both.

1. SOLID Principles

SOLID is a diagnostic framework. When code is hard to change, one of these principles usually explains why. But applying them prophylactically — before you feel the pain — produces the kind of over-abstracted architecture that makes senior engineers weep.

S — Single Responsibility Principle

The principle: A class should have one reason to change. "Reason to change" means one stakeholder or one axis of requirements evolution.

When it helps:

• A class mixes persistence logic with business rules. The database schema changes, and you're editing the same file that implements pricing. Split them.
• A module handles both HTTP serialization and domain validation. These change for completely different reasons and at different rates.

When it hurts:

• Taken too far, SRP produces dozens of anemic classes that each do one trivial thing, connected by a web of delegation that nobody can follow. You've traded one 200-line class for fifteen 20-line classes and a wiring problem.
• The question is never "does this class do more than one thing?" — everything does more than one thing at some level of abstraction. The question is: do these responsibilities change at the same time, for the same reasons? If yes, they belong together. Cohesion matters more than smallness.

The practical test: Look at your git history. If a class changes in every commit for unrelated reasons, it has too many responsibilities. If you're always changing three classes together in lockstep, they may have been split incorrectly — they share a responsibility.

O — Open/Closed Principle

The principle: Software entities should be open for extension but closed for modification. You should be able to add new behavior without editing existing, working code.

When it helps:

• You have a payment system and need to add new payment methods regularly. A strategy pattern or plugin architecture lets you add StripePayment, PayPalPayment without touching the payment processing core.
• Framework extension points: middleware chains, hook systems, event handlers. These are OCP applied well.

When it hurts:

• Premature openness. If you have one payment method and might add another someday, you don't need a PaymentStrategy interface with a factory and a registry. You need an if statement and the willingness to refactor later.
• Every extension point is a design commitment. It says "I expect variation here." If you're wrong about where variation will occur, you've added complexity at the wrong seams and the actual change still requires modification.

The practical test: You need OCP when you've added the third variant of something. The first is just code. The second might be an if/else. The third is when you extract the pattern. Not before.

L — Liskov Substitution Principle

The principle: If S is a subtype of T, then objects of type T can be replaced with objects of type S without altering the correctness of the program. Subtypes must honor the behavioral contract of their parent, not just the type signature.

When it helps:

…