Delegation vs classical inheritance

Linked objects, not copies

In JavaScript, an object can have a hidden link to one other object. That other object is called its prototype. When you ask an object for a property it doesn't have, JavaScript follows the link and asks the prototype. Nothing is copied. The first object only keeps the link.

You met these links in the earlier lessons of this module:

• The prototype chain showed how JavaScript walks from one object to the next.
• F.prototype & constructors showed how new links a new object to a prototype.
• Built-in prototypes showed where array and function methods live.
• Object.create & null-prototype objects showed how to pick an object's link yourself.

This lesson puts those ideas together. It shows how to use the links to share methods between objects, and when another way works better.

const shared = { label: "shared" };
const user = Object.create(shared);
user.name = "Asha";
console.log(user.name);
console.log(user.label);

• Line 1 makes an object called shared.
• Line 2 makes user with Object.create(shared). This links user to shared, but copies nothing.
• Line 3 gives user its own name. An own property is one stored on the object itself.
• Line 4 prints Asha, because user has its own name.
• Line 5 prints shared. user has no label, so JavaScript follows the link and finds label on shared.

Object-oriented programming (OOP) is a way to write code where each object keeps its data and the functions that work on that data together. There are two common ways to share those functions between objects:

• Class-based: first you describe groups, called classes. For example, a general Widget class, and a more specific Button class built on it. Then you make objects from the classes.
• Prototype-based: you link objects straight to other objects. An object asks its linked object for anything it doesn't have.

JavaScript can do both. The class keyword gives you the class style. But underneath, JavaScript has always shared methods through prototype links.

The step-through below builds the same feature three ways. A widget has a render() method that returns some HTML. A button adds a clickLabel() method. You can switch between three styles:

• Constructor functions with a prototype object.
• class extends, the class style.
• OLOO, which links plain objects with Object.create. You'll learn the name later in this lesson.

All three print the same two lines. Only the links between the objects are different.

1const Widget = {Run2  init(name) {3    this.name = name;4  },5  render() {6    return "<button>" + this.name + "</button>";7  },8};9 10const Button = Object.create(Widget);11Button.setup = function (name, label) {12  this.init(name);13  this.label = label;14};15Button.clickLabel = function () {16  return this.label + " clicked";17};18 19const button = Object.create(Button);20button.setup("Save", "Save");21console.log(button.render());22console.log(button.clickLabel());

The table compares the three styles. Read each row as: this is how the style shares methods, this is when it helps, and this is what to watch out for.

You'll learn classes in the next module: first Class basics, then Mixins & composition and OOP principles in JavaScript. This lesson doesn't teach class syntax in depth. It shows the prototype links first, so classes make sense when you get there.

When you call a method, JavaScript may find it on a linked object. But the method still works on the object you called it on. That object is the one before the dot, and it becomes this inside the method. This is why one shared method can read each object's own data.

const shared = { label: "shared" };
const user = Object.create(shared);
user.label = "own";
console.log(user.label);
console.log(Object.hasOwn(user, "label"));

Line 3 gives user its own label. Now line 4 finds the own property first and prints own. We say the own property shadows (hides) the label on shared.

Line 5 uses Object.hasOwn(user, "label"). It asks: is label stored on user itself? It prints true. The link to shared is still there, and shared.label is still "shared".

In the playground below, task links to TaskActions, and TaskActions links to Formatter. Pick a method name. You'll see which objects JavaScript checks, in order, and which one has the method.

1const Formatter = {2  formatStatus() {3    return this.done ? "done" : "todo";4  },5};6 7const TaskActions = Object.create(Formatter);8TaskActions.describe = function () {9  return this.title + " is " + this.formatStatus();10};11TaskActions.complete = function () {12  this.done = true;13};14 15const task = Object.create(TaskActions);16task.title = "Write tests";17task.done = false;18 19console.log(task.describe());20task.complete();21console.log(task.describe());

const actions = {
  greet() {
    return "Hi, " + this.name;
  },
};
const user = Object.create(actions);
user.name = "Asha";
console.log(user.greet());

• Lines 1 to 5 put a greet method on actions.
• Line 6 links user to actions.
• Line 7 gives user its own name.
• On line 8, JavaScript finds greet on actions. But user is before the dot, so this is user. The method reads user.name and returns Hi, Asha.

You can follow any lookup by hand, one step at a time:

1. Start with the object before the dot.
2. Look for the property on that object itself.
3. If it isn't there, follow the link to the prototype.
4. Repeat until you find the property.
5. If the links end at null first, the result is undefined.

If you then try to call that undefined as a function, JavaScript throws a TypeError. That error means a value was the wrong type for what you tried to do with it.

OLOO: objects linked to other objects

OLOO stands for Objects Linked to Other Objects. Kyle Simpson made this name popular in his book series You Don't Know JS. The idea is not that classes are bad. The idea is that JavaScript already works by linking objects to objects. So sometimes you can skip classes and link plain objects directly.

1const Widget = {2  init(name) {3    this.name = name;4  },5  render() {6    return "<button>" + this.name + "</button>";7  },8};9 10const Button = Object.create(Widget);11Button.setup = function (name, label) {12  this.init(name);13  this.label = label;14};15Button.clickLabel = function () {16  return this.label + " clicked";17};18 19const button = Object.create(Button);20button.setup("Save", "Save");21console.log(button.render());22console.log(button.clickLabel());

The highlighted lines show three objects and one call:

• Line 1 makes Widget, a plain object with the shared methods init and render.
• Line 10 makes Button, linked to Widget.
• Line 19 makes button, linked to Button.
• Line 21 calls button.render(). JavaScript checks button, then Button, and finds render on Widget.

const defaults = { theme: "light" };
const profile = Object.create(defaults);
profile.name = "Asha";
console.log(profile.theme);
console.log(profile.name);

profile has its own name. It has no theme, so it gets theme from defaults, and line 4 prints light. This is handy for default settings. Later, profile can get its own theme without changing defaults.

Look at how the methods are called. Every call starts with the object before the dot, like button.render(), so this is button. Now say you save the method on its own, with const show = button.render, and call show(). There is no object before the dot, so this no longer points at button. Call the method through its object instead, or use bind. bind makes a new function with this fixed to one object.

There is an old saying: "If it walks like a duck and quacks like a duck, treat it as a duck." In code, duck typing means you check whether a value can do the job you need. You don't check which constructor or class made it. For example:

• If your function needs to call quack(), check that quack is a function.
• If your function needs to loop over a value, check that it has a Symbol.iterator method. That is the method that for...of and spread, [...value], use to loop.

1function speakLikeDuck(candidate) {2  if (typeof candidate?.quack === "function") {3    return candidate.quack();4  }5  return "not a duck-like object";6}7 8function collectValues(candidate) {9  if (typeof candidate?.[Symbol.iterator] === "function") {10    return [...candidate].join(", ");11  }12  return "not iterable";13}14 15const robotDuck = { quack() { return "beep-quack"; } };16console.log(speakLikeDuck(robotDuck));17console.log(collectValues(new Set(["waddle", "quack"])));

function describe(value) {
  return typeof value?.save === "function" ? value.save() : "cannot save";
}
console.log(describe({ save() { return "saved"; } }));
console.log(describe({ name: "draft" }));

Line 2 uses two tools:

• value?.save reads save. If value is null or undefined, it gives undefined instead of an error. The ?. is called optional chaining.
• typeof gives the type of a value as a string, such as "function".

The first object has a save function, so line 4 prints saved. The second object only has a name, so line 5 prints cannot save instead of crashing. The check never asks which constructor made the object.

This is why many JavaScript functions accept any value you can loop over, not only arrays. TypeScript has a similar idea, called structural typing. TypeScript checks your code before it runs. A value fits a type when it has the properties the type needs. Which class made the value doesn't matter.

Inheritance asks: what family is this object in? Composition asks: what parts does this object have? Composition means building one object from small parts, where each part adds one ability. When abilities mix in many different ways, composition keeps your code flatter and easier to change.

The playground uses Object.assign. Object.assign(target, ...parts) copies each part's own properties onto the target object, from left to right. Turn abilities on and off to see which methods OtterBot gets.

1const canFly = {2  fly() {3    return this.name + " lifts off";4  },5};6const canSwim = {7  swim() {8    return this.name + " makes waves";9  },10};11const canSpeak = {12  speak() {13    return this.name + " says hello";14  },15};16 17function createCreature(name, abilities) {18  return Object.assign({ name }, ...abilities);19}20 21const otterBot = createCreature("OtterBot", [canSwim, canSpeak]);22console.log(otterBot.swim());23console.log(otterBot.speak());

const canSave = { save() { return "saved"; } };
const canLog = { save() { return "logged"; } };
const tool = Object.assign({}, canSave, canLog);
console.log(tool.save());

Both parts have a method called save. Object.assign copies canSave first and canLog second. The second save replaces the first, so line 4 prints logged.

When you combine parts, give their methods different names, or decide on purpose which one should win.

Composition also keeps each ability next to the feature that needs it. If a screen needs to save but not print, give it only the save part. Don't make it inherit from an object that has both.

Where you'll use this

You'll meet these ideas often, even if you never build your own object system:

• Arrays get methods like map from Array.prototype, through the link.
• Parts of a user interface often share methods through prototypes or class methods.
• A plugin, a small add-on to a bigger program, can take missing settings from a defaults object.
• Helper functions use duck typing so they work with arrays, Sets, Maps, strings, or any value you can loop over.

Keep shared objects stable. If you change a prototype later, every object linked to it sees the change, and bugs get hard to find. For your app's data, use objects you own. Don't change built-in prototypes such as Array.prototype. If you write a library, say in its docs whether a method still works when it is saved on its own, and which properties it expects on this.

Sort these cases by the style that fits best. No style is always right. Pick the one that matches how the objects in the problem relate.

Common misconceptions

For code questions, follow the lookup one step at a time. For design questions, ask how the objects in the question really relate.

Key takeaways

• A prototype is a link to another object. JavaScript finds methods through the link; it doesn't copy them.
• The class syntax is useful, but class methods still live on a prototype.
• OLOO links plain objects straight to each other with Object.create.
• Duck typing checks what a value can do, such as having quack() or Symbol.iterator.
• Composition builds an object from small parts, so you don't need a deep family tree for every mix of abilities.

Up next: Class basics. You'll learn the class syntax, and you'll already know the prototype links underneath it.