/object-oriented-programmer

name: object-oriented-programmer
description: Object-oriented design principles, patterns, and practices. Use when working with object-oriented languages (Java, C#, C++, Python, Ruby, Swift, etc.) without language-specific skills available, or when applying OOP in multi-paradigm codebases.

Object-Oriented Programmer

Purpose

This skill provides guidance on object-oriented programming principles, design patterns, and practices. Object-oriented programming organizes code around objects that combine data and behavior, using encapsulation, inheritance, and polymorphism to manage complexity. This skill serves as a foundation when working with OO languages or applying object-oriented design in multi-paradigm codebases.

When to Use This Skill

Use this skill when:

• Working with object-oriented languages (Java, C#, C++, Python, Ruby, Swift) without language-specific skills available
• Designing systems with complex state and behavior
• Modeling domains with rich entity relationships
• Building frameworks or libraries with extension points
• Working with existing OOP codebases

**Note:** Language-specific skills (e.g., java-programmer, python-programmer) supersede this skill when available.

Core Philosophy

Objects as Encapsulated State and Behavior

Object-oriented programming bundles data (state) with the operations (behavior) that act on that data. An object presents a clean interface while hiding implementation details. This encapsulation creates boundaries that limit coupling and enable local reasoning.

**Quote to remember:** "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." — Linus Torvalds

Polymorphism Enables Abstraction

Polymorphism allows treating different types uniformly through shared interfaces. This enables writing code against abstractions rather than concrete types, making systems more flexible and extensible.

**Types of polymorphism:**

• **Subtype polymorphism** — Inheritance hierarchies (interfaces, abstract classes)
• **Parametric polymorphism** — Generics/templates
• **Ad-hoc polymorphism** — Method overloading

Inheritance as Code Reuse (Use Carefully)

Inheritance enables defining types in terms of other types, inheriting both interface and implementation. However, inheritance creates tight coupling between parent and child classes.

**The inheritance trade-off:** Inheritance is easy to add (create subclass) but hard to change (affects all subclasses). Composition is harder to add (requires more boilerplate) but easier to change (localized impact).

**Modern wisdom:** "Composition over inheritance" — prefer delegating to contained objects over inheriting from parent classes.

Fundamental Principles

Encapsulation Hides Complexity

Encapsulation bundles related data and behavior while hiding internal implementation. Objects expose interfaces; internals are private.

**Why encapsulation matters:**

• Limits coupling (changes don't ripple through codebase)
• Enables local reasoning (understand object in isolation)
• Protects invariants (object controls its own consistency)
• Provides flexibility (change internals without affecting clients)

**Encapsulation boundaries:**

• Private state, public interface
• Package-private for internal APIs
• Protected for inheritance hierarchies (use sparingly)

Abstraction Manages Complexity

Abstraction focuses on essential characteristics while hiding incidental details. Interfaces and abstract classes define contracts without specifying implementation.

**Why abstraction matters:**

• Program against interfaces, not implementations
• Enable substitution (Liskov Substitution Principle)
• Defer decisions (choose implementations later)
• Facilitate testing (mock interfaces easily)

**Abstraction levels:**

• Interfaces — Pure contracts (no implementation)
• Abstract classes — Partial implementation with extension points
• Concrete classes — Full implementation

Polymorphism Enables Flexibility

Polymorphism allows uniform treatment of different types. Write code once that works with many implementations.

**Why polymorphism matters:**

• Add new implementations without changing client code
• Strategy pattern (choose behavior at runtime)
• Plugin architectures (extend without modifying core)
• Testing (inject mocks/stubs through interfaces)

**Polymorphism trade-off:** Indirection obscures flow. Reading polymorphic code requires knowing what implementations exist and which is active. Balance flexibility against clarity.

<solid_principles>

SOLID Principles

SOLID provides guidelines for object-oriented design. These are heuristics, not laws—apply them where they improve code, not dogmatically.

<single_responsibility>

Single Responsibility Principle

A class should have one reason to change. Each class should do one thing well.

**Good indicators:**

• Can describe class purpose in one sentence without "and"
• Changes to requirements affect only one class
• Class has cohesive set of methods

**When to violate:**

• Very small classes (splitting increases complexity)
• Clearly related concerns (don't separate prematurely)
• Performance-critical hot paths (fewer objects, fewer allocations)

**Common mistake:** Confusing "single responsibility" with "one method." Classes can have multiple methods serving one coherent purpose. </single_responsibility>

<open_closed>

Open-Closed Principle

Open for extension, closed for modification. Add new behavior without changing existing code.

**Implementation strategies:**

• Inheritance — Extend base classes (classic OCP)
• Composition — Inject dependencies (modern preference)
• Strategy pattern — Plug in different algorithms
• Template method — Override specific steps

**When to violate:**

• Requirements fundamentally change (refactor rather than extend)
• Abstraction is speculative (YAGNI — You Aren't Gonna Need It)
• System is small and changes are cheap

**Staff insight:** OCP assumes fu