Fifty Shades of OOP
11 hours ago
- #Programming Paradigms
- #OOP
- #Software Design
- OOP (Object-Oriented Programming) lacks a clear, universally accepted definition, leading to unproductive debates.
- OOP can be viewed as a collection of interrelated ideas rather than a single paradigm.
- Classes extend structs/records with method syntax, information hiding, and inheritance, though prototypes (e.g., JavaScript) offer an alternative.
- Method syntax is widely accepted but has drawbacks like implicit 'this' and power imbalance between methods and functions.
- Information hiding (e.g., private members) protects invariants but can lead to boilerplate or abstraction inversion.
- Encapsulation bundles data with functions, but data-oriented design argues for coarser-grained approaches for performance.
- Interfaces (e.g., traits, type classes) provide polymorphism without inheritance, though they may have runtime costs.
- Late binding and dynamic dispatch enable runtime flexibility but come with performance trade-offs.
- Inheritance is iconic but often misused; it combines subtyping, polymorphism, and code reuse in a non-orthogonal way.
- Subtyping polymorphism (e.g., 'is-a' relationships) is often implemented via inheritance but can also be structural.
- Message passing, central to Alan Kay's OOP vision, has resurged in concurrent programming (e.g., actors in Erlang).
- Open recursion allows interdependent methods to be defined separately, enabling patterns like the decorator.
- OOP best practices (e.g., polymorphism over switches, private members) have trade-offs in readability, performance, and flexibility.