OOP is shifting between domains, not disappearing

Original Article ↗ Hacker News Discussion ↗

Definition and scope of OOP

  • Many commenters argue “OOP” is now so overloaded it’s nearly meaningless.
  • Disagreement over whether OOP means: classes, inheritance hierarchies, message passing, encapsulation/ADTs, or just “methods on data”.
  • Examples used: prototype-based JS, Go’s methods/interfaces, closures vs objects, and message-passing/actor systems as “purer” OO.

Critiques of OOP and inheritance

  • Major pain points attributed to OOP: deep inheritance, shared hidden mutable state, and over-abstraction that makes code hard to reason about.
  • Several say inheritance is the uniquely harmful part; composition plus interfaces/traits are seen as safer.
  • Others defend OOP itself and blame cultural misuse (e.g., Java-style overengineering, GoF-pattern cargo culting) rather than the paradigm.

Functional programming and data-first design

  • Some report success replacing OOP with “plain data structures + functions”, keeping state centralized and mutations at the edges.
  • FP is framed as better for linear data processing and transformations; OOP better for simulations, GUIs, and complex state machines.
  • Disagreement over whether OOP is actually superior for CRUD/ORM work; ORMs are seen as convenient but also as performance traps and abstraction leaks.
  • Discussion dives into “pure functions/transformations” and how FP still relies on data structures, just with behavior decoupled.

Microservices vs OOP

  • Split between those who see microservices as “objects at the network layer” and those who insist they solve orthogonal (mostly organizational/scale) problems.
  • Many note microservices add latency, serialization overhead, failure modes, and operational cost, and are often used where a monolith would suffice.
  • Others argue they can be valuable for large, distributed teams and very high scale, but are widely misapplied.

Architecture bloat and higher-level OO

  • Some see today’s stacks (OpenAPI, Docker Compose, Kubernetes, service meshes) as re-implementing OO patterns—interfaces, factories, event loops—at infrastructure scale.
  • Interfaces and contracts are reframed as security/trust boundaries; loss of trust drives more rigid, tool-enforced separation.

Pragmatic/nuanced views

  • Several commenters emphasize that modularization, encapsulation, and separation of concerns predate OOP and remain valuable regardless of paradigm.
  • Consensus from multiple angles: any paradigm (OO, FP, microservices) becomes harmful when overused, misapplied, or treated as ideology rather than a tool.