Skip to content

OOP Pillars — Notes#

Why these four (and not more)#

The "four pillars" framing is a teaching device, not a formal classification. Different communities slice OO into different sets — Alan Kay's original OO emphasises message-passing more than inheritance; modern functional-OO blends like Scala/Kotlin emphasise immutability + traits.

The four pillars survive because they're the operations a designer reaches for first when shaping a system in an OO language.

Practical rules of thumb#

  • Encapsulation: if a field is public, you've decided it's part of your forever-API. Default to private.
  • Abstraction: every dependency in your domain layer is an interface. Concretions live at the composition root.
  • Inheritance: limit hierarchies to 2 levels. Any deeper, refactor to composition.
  • Polymorphism: prefer it over if (type == ...) chains. The compiler tells you when you missed a case (with sealed types / exhaustive matches).

Common myths#

  • "OOP means inheritance." Inheritance is the least important pillar in modern code. Encapsulation and abstraction matter more.
  • "Encapsulation = getters and setters." No — getters and setters are usually a sign of leaked encapsulation. Methods should do things, not just expose state.
  • "Polymorphism is slow." On the JVM and modern C++, virtual calls are typically a single indirection; megamorphic call-site cost matters only in extreme hot loops.

Where OO falls short#

  • Highly concurrent designs lean on immutability and message passing more than on encapsulating mutable state.
  • Data-pipeline code reads cleaner as functions over immutable data than as objects.
  • Many "OO patterns" disappear in functional languages (Strategy = a function, Visitor = pattern matching).

Use the pillars as a default; abandon any of them when a more local style serves the code better.

Refs#

  • Object-Oriented Software Construction — Bertrand Meyer (1988).
  • Clean Architecture — Robert C. Martin.
  • Domain-Driven Design — Eric Evans (encapsulation by bounded context).
  • Effective Java — items on classes & interfaces (15–25).
  • Alan Kay's emails about what he meant by "object-oriented".