With classes, the way you design the scenario is: define a general parent (base) class like Task, defining shared behavior for all the "alike" tasks.
Let's say we have several similar tasks ("XYZ", "ABC", etc) that we need to model in our software. I'm going to walk you through some theoretical exercises first, then we'll look side-by-side at a more concrete example to give you practical context for your own code. You may need to try this mental exercise quite a few times to get the hang of this very different way of thinking. If you have done most or all of your programming in your education/career thinking in classes, this may be uncomfortable or feel unnatural. We need to try to change our thinking from the class/inheritance design pattern to the behavior delegation design pattern. For example, encapsulation is quite powerful, and is compatible (though not as common) with delegation. Note: Some principles of class-oriented design are still very valid, so don't toss out everything you know (just most of it!).
To properly focus our thoughts on how to use ] in the most straightforward way, we must recognize that it represents a fundamentally different design pattern from classes (see Chapter 4). That single observation is fundamental and critical to understanding the motivations and approaches for the rest of this chapter! Towards Delegation-Oriented Design In other words, the actual mechanism, the essence of what's important to the functionality we can leverage in JavaScript, is all about objects being linked to other objects.
This series of links between objects forms what is called the "prototype chain". In turn, if that object cannot fulfill the look-up, its ] is followed, and so on. In that case, the ] linkage tells the engine to look for the property/method on the linked-to object. This linkage is exercised when a property/method reference is made against the first object, and no such property/method exists. Let's now dig into how we could and should be thinking about the object ] mechanism in JS, in a much simpler and more straightforward way than the confusion of classes.Īs a brief review of our conclusions from Chapter 5, the ] mechanism is an internal link that exists on one object which references another object. I hope by now you're not content to just gloss over and leave such details to a "black box" library. Now that we've pulled back the curtain and seen just how dirty it all gets, it's not a surprise that most JS developers never dive this deep, and instead relegate such mess to a "class" library to handle it for them. It's a common reaction at this point to wonder why it has to be so complex to do something seemingly so simple. We explored variations of the "mixin" approach, which many people use to attempt to smooth over such rough areas. constructor resolution or ugly pseudo-polymorphic syntax). prototype littering the code), but the various gotchas (like surprising. We trudged through not only the fairly verbose syntax (. In Chapter 5, we addressed the ] mechanism in detail, and why it's confusing and inappropriate (despite countless attempts for nearly two decades) to describe it as "class" or "inheritance".
You Don't Know JS: this & Object Prototypes Chapter 6: Behavior Delegation