Skip to main content

Classical Inheritance is Obsolete: How to Think in Prototypal OO

Pure Code and JavaScript Continental 5
Average rating: ****.
(4.21, 24 ratings)

Classical Inheritance is Obsolete

“Those who are unaware they are walking in darkness will never seek the light.” —Bruce Lee

In “Design Patterns”, the Gang of Four recommend two important principles of object oriented design:

  1. Program to an interface, not an implementation.
  2. Favor object composition over class inheritance.

In a sense, the second principle could follow from the first, because inheritance exposes the parent class to all child classes. The child classes are all programming to an imple‐ mentation, not an interface. Classical inheritance breaks the principle of encapsulation, and tightly couples the child classes to its ancestors.

Why is the seminal work on Object Oriented design so distinctly anti-inheritance? Because inheritance causes several problems:

  1. Tight coupling. Inheritance is the tightest coupling available in OO design. Descendant classes have an intimate knowledge of their ancestor classes.
  2. Inflexible hierarchies. Single parent hierarchies are rarely capable of describing all possible use cases. Eventually, all hierarchies are “wrong” for new uses — a problem that necessitates code duplication.
  3. Complicated multiple inheritance. It’s often desirable to inherit from more than one parent. That process is inordinately complex and its implementation is inconsistent with the process for single inheritance, which makes it harder to read and understand.
  4. Brittle architecture. Because of tight coupling, it’s often difficult to refactor a class with the “wrong” design, because much existing functionality depends on the existing design.
  5. The Gorilla / Banana problem. Often there are parts of the parent that you don’t want to inherit. Subclassing allows you to override properties from the parent, but it doesn’t allow you to select which properties you want to inherit.
    These problems are summed up nicely by Joe Armstrong in “Coders at Work”, by Peter Siebel:

In this talk, you’ll see lots of examples demonstrating both the weaknesses of the classical OO style in JavaScript, as well as the strength and flexibility in prototypal alternatives, including:

  • Exemplar prototypes
  • Prototype mixins
  • Prototype-powered flyweights
  • Prototype-backed factory functions
Photo of Eric Hamilton

Eric Hamilton

Adobe

Eric Elliott is a veteran of JavaScript application development. He is currently a member of the Creative Cloud team at Adobe. Previous roles include JavaScript Lead at Tout (social video), Senior JavaScript Rockstar at BandPage (an industry leading music app), head of client side architecture at Zumba Fitness (the leading global fitness brand), and several years as a UX and viral application consultant. He lives in the San Francisco bay area with the most beautiful woman in the world.

Comments on this page are now closed.

Comments

Kunal Mehrotra
06/02/2013 4:55pm PDT

Can we please get the link to slides/presentation? Thanks!

Sponsors

For exhibition and sponsorship opportunities at Fluent conference, contact Sharon Cordesse at (707) 827-7065 or scordesse@oreilly.com

Download the Fluent Sponsor/Exhibitor Prospectus

For information on trade opportunities with O'Reilly conferences contact Jaimey Walking Bear at mediapartners
@oreilly.com

View a complete list of Fluent 2013 contacts