object-oriented-programming

name: object-oriented-programming description: Enforces object-oriented programming principles including encapsulation, composition over inheritance, GRASP patterns, message passing, and CRC-driven design. Use when designing class hierarchies, assigning responsibilities to objects, evaluating cohesion and coupling, refactoring toward better OO design, or reviewing code for OOP anti-patterns like God Objects and Anemic Domain Models.

Object-Oriented Programming

Reference: Practical Object-Oriented Design (Metz), Object Thinking (West), Applying UML and Patterns (Larman)

When to Apply

• Designing new classes or assigning responsibilities to existing ones
• Evaluating whether inheritance or composition is appropriate
• Reviewing code for cohesion, coupling, or responsibility assignment
• Refactoring God Objects, Anemic Domain Models, or deep hierarchies
• Deciding between Tell Don't Ask and query-based approaches
• Modeling a problem domain with objects, roles, and collaborations

Core Design Principles

Message-Passing First

Objects are autonomous agents communicating via messages. Design starts with what messages are sent, not what data is stored. Alan Kay's definition: "OOP means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

• MUST design public interfaces (messages) before internal implementation
• MUST treat objects as black boxes — interact only through their public protocol
• SHOULD ask "what message should I send?" before "what data do I need?"

The Four Pillars — Applied

Responsibility Assignment — GRASP Patterns

When deciding which object should handle a responsibility, apply these patterns in order of priority (Larman):

• MUST apply Information Expert as the default responsibility assignment strategy
• MUST use Polymorphism instead of type-checking conditionals
• SHOULD evaluate Low Coupling and High Cohesion when choosing between alternative designs
• SHOULD introduce Pure Fabrication only when Expert creates cohesion problems

Composition vs Inheritance

Default to composition. Use inheritance only when ALL of these hold:

1. The relationship is genuinely, permanently "is-a" (not "has-a" or "behaves-like-a")
2. The subclass is a true specialization — it uses everything from the parent
3. Liskov Substitution holds: substituting the subclass for the parent breaks nothing
4. The hierarchy is shallow (SHOULD NOT exceed 2–3 levels)

Composition advantages:

• Black-box reuse — no exposure of internal implementation
• Runtime flexibility — swap collaborators without changing class structure
• Avoids the fragile base class problem — base changes don't silently break subclasses

Cohesion and Coupling

Cohesion (aim for the top)

Coupling (aim for the bottom)

• MUST NOT introduce content coupling — never reach into another object's internals
• MUST NOT use global mutable state as a communication channel between objects
• SHOULD prefer data coupling — pass only the specific values needed
• SHOULD eliminate control coupling by replacing flag parameters with polymorphism

Object Thinking — Tell, Don't Ask

Design objects as autonomous virtual persons (West). Command them to act rather than querying their state and deciding externally.

Tell, Don't Ask:

# BAD — Ask: querying state, deciding externally
if order.status == "paid" and order.items_in_stock():
    warehouse.ship(order)

# GOOD — Tell: the object decides internally
order.fulfill()  # Order knows its own rules

Law of Demeter — only talk to immediate collaborators:

• MUST NOT chain through intermediaries: a.getB().getC().doSomething()
• MUST send messages only to: self, parameters, instance variables, objects you create, or direct collaborators
• If you need to reach deep, the intermediate object is missing a responsibility

CRC Cards (Class-Responsibility-Collaboration):

Use when discovering object roles in design sessions. Each card lists:

• Class name — a noun representing a domain concept
• Responsibilities — what the object knows and does (verbs)
• Collaborators — other objects it needs to fulfill responsibilities

Walk through use cases, role-playing objects. Missing responsibilities reveal missing objects.

Anti-Patterns and Remedies

Modern OO — Multi-Paradigm Pragmatism

Pure OO dogma has given way to blending OO encapsulation with FP immutability and higher-order functions. Apply these guidelines:

• SHOULD prefer immutable value objects over mutable entities where possible
• SHOULD use traits/mixins/protocols for behavior sharing instead of inheritance
• SHOULD use higher-order functions (lambdas, closures) where Strategy or Command patterns add unnecessary ceremony
• SHOULD consider the Actor Model (Erlang, Akka, Swift concurrency) for concurrent message-passing systems

Checklist

Before finalizing an object-oriented design, verify:

• Responsibilities are assigned using Information Expert as the default
• Public interfaces are defined before internal implementation
• Inheritance is used only for stable, shallow "is-a" with Liskov Substitution
• Composition is used for "has-a", "behaves-like-a", and cross-cutting behavior
• No God Objects — every class has a single, focused purpose
• No Anemic Domain Models — objects contain behavior, not just data
• Law of Demeter is respected — no method chain trains
• No type-checking conditionals — polymorphism handles variation
• Value Objects replace primitive types for domain concepts
• Coupling is at the data or stamp level, never content or common

Key References