DEV Community: PabloHoudini

JS Inheritance - Part 2: Factory Functions vs. Classes

PabloHoudini — Sun, 09 Jun 2024 04:47:25 +0000

JS Inheritance - Part 2: Factory Functions vs. Classes

Introduction

Last time, we took a look at classes and prototypes in JavaScript. We compared constructor functions to classes and discussed how the class keyword introduced in ES6 aimed to simplify object-oriented programming in JavaScript. However, the introduction of classes did not solve all the problems associated with constructor functions. Today, we will explore different ways to declare an object in JavaScript and see if there is a need to use classes at all.

Different Ways to Declare an Object

Class

class ClassCar {
    drive() {
        console.log('Vroom!');
    }
}

console.log(typeof ClassCar); // function

const car1 = new ClassCar();
console.log(car1.drive());

Constructor Function

function ConstructorCar() {}

ConstructorCar.prototype.drive = function () {
    console.log('Vroom!');
};

console.log(typeof ConstructorCar); // function

const car2 = new ConstructorCar();
console.log(car2.drive());

Factory Function

const proto = {
    drive() {
        console.log('Vroom!');
    },
};

const factoryCar = () => Object.create(proto);

console.log(typeof proto); // object
console.log(typeof factoryCar); // function

const car3 = factoryCar();
console.log(car3.drive());

Each of these strategies stores methods on a shared prototype and optionally supports private data via constructor function closures. In other words, they have mostly the same features and could mostly be used interchangeably. The question now is: you can, but should you?

Factory Functions

We talked about constructor functions. We know that the new keyword is something that changes a regular function into a constructor function. If we want to free ourselves from the confines of the classical model, we have to embrace the prototypal model. In a prototypal model, objects inherit from objects. (Do you remember Object.prototype?) However, JavaScript lacks an operator that is responsible for such an operation. Instead, it has a new keyword that can produce a new object that inherits from Object.prototype. This was done on purpose to make it look familiar to classically trained programmers, but it failed miserably. It simply did not appeal to the classical crowd. Also, it obscured JavaScript from its real inheritance model.

Should You Use Factory Functions Instead of Classes?

Much like Array, class is not a language feature; it’s syntactic obscurantism. It tries to hide the prototypical inheritance model and the clumsy idioms that come with it, and it implies that JavaScript is doing something that it is not. So, by design, there are no classes. However, JavaScript has all the necessary features to implement OOP; there was no need to add classes in ES6. It was added just so Java or C# developers can feel comfortable.

To put a fine point on that, a child of a prototype isn’t a copy of its prototype, nor is it an object with the same shape as its prototype. The child has a living reference to the prototype, and any prototype property that doesn’t exist on the child is a one-way reference to a property of the same name on the prototype.

Most of the time, classes in JavaScript don’t serve a good purpose; they are not really useful.

Why We Should Not Use Classes

Most of the time, classes in JavaScript don’t serve a good purpose; they are not really useful.

Functional Programming for Life

In JavaScript, functions are first-class citizens. Functional programming is all about using functions to their fullest extent. Functional programming has come and gone and come back again. A couple of reasons why, in my humble opinion, we should try to understand the benefits of functional programming. One should just ask himself if factories are much more flexible than either constructor functions or classes, and they don’t lead people down the wrong path by tempting them with the extends keyword and deep inheritance hierarchies. There are many safer code reuse mechanisms you should favor over class inheritance, including functions and modules.

Some Code to Prove It

So we could start with something like this:

// class
class ClassCar {
    drive() {
        console.log('Vroom!');
    }
}

console.log(typeof ClassCar); // function

const car1 = new ClassCar();
console.log(car1.drive());

And a little refactor using modules:

// Car.js

export function drive() {
    console.log('Vroom!');
}
export function stop() {
    console.log('Stopping');
}

// app.js

import * as car from './Car';

car.drive();
car.stop();

So we got rid of two keywords here: new and class. As we see in the above example, we do not really need them to achieve what we want to achieve. Another example would be:

class Child extends Parent {}

// instead we could do

const fun = parent(child());

Here we also saw another keyword extends that has come and gone. Do we really need it? Answer: not really.

A real-life example utilizing such a programming style would be the Fastify framework for Node.js backend development.

Moreover, on the frontend, React has also ditched the old concept of React.Component and has moved towards functional components and hooks.

Summary

Classes in JavaScript make things look more familiar to classically trained developers. However, it is only a sugar coating, and when uncovered, it reveals JavaScript's true nature. And the true nature of JavaScript is prototypical inheritance. So, if you are not one of the developers coming from OOP programming languages like Java or C#, then I strongly suggest stopping using classes and favoring objects and functions, and moving on to modules. This will be extremely beneficial if you want to work in frameworks like React or Fastify. JavaScript, like any other language, has good and bad parts. Surely, one of the best parts is the lack of classes and class inheritance. It might take some effort and time to truly master prototypal inheritance, but it is surely worth it.

Understanding JavaScript Inheritance: A Deep Dive into Prototypal and Constructor Patterns

PabloHoudini — Sun, 09 Jun 2024 04:41:21 +0000

Understanding JavaScript Inheritance: A Deep Dive into Prototypal and Constructor Patterns

Introduction

In our previous post, we explored how JavaScript tries to imitate classes and whether there is a better way. We discussed how JavaScript's class keyword is essentially syntactic sugar over its prototype-based inheritance model. Today, we will dive deeper into JavaScript's inheritance mechanisms, focusing on the differences between classical inheritance and prototypal inheritance, and clarifying some common confusions.

JavaScript Inheritance

JavaScript was not designed to be an object-oriented programming (OOP) language, but it can still support OOP-style coding. Unlike classical inheritance, JavaScript uses prototypal inheritance, which can be implemented in two patterns:

The prototypal pattern of prototypal inheritance.
The constructor pattern of prototypal inheritance.

Unfortunately, JavaScript primarily uses the constructor pattern of prototypal inheritance. This decision was influenced by Brendan Eich's intention to make JavaScript look like Java, which uses classical inheritance. However, this has led to some confusion among developers.

What is a Class?

Classes were introduced in ECMAScript 2015 (ES6) to provide a cleaner way to follow OOP patterns. Despite this, JavaScript still follows a prototype-based inheritance model. Classes in JavaScript are syntactic sugar over this model, making it easier for developers to build software around OOP concepts and bringing similarities to other OOP languages like C++ and Java.

Before the `class` Keyword

function Car(brand, model, color, price) {
    this.brand = brand;
    this.model = model;
    this.color = color;
    this.price = price;
}

const car = new Car("Marker", "Blue", "$3");
console.log(car);

After the `class` Keyword

class ClassCar {
    constructor(brand, model, color, price) {
        this.brand = brand;
        this.model = model;
        this.color = color;
        this.price = price;
    }
    drive() {
        console.log('Vroom!');
    }
}

Ok, it does look cleaner and less verbose, but is the class a real class or is it something else? Let's find out:

console.log(typeof ClassCar); // function

O wow, so the class actually hides something else behind itself. The MDN’s statement:

"Classes are in fact 'special functions'"

is a bit misleading. It’s more accurate to say that classes are syntax sugar for constructor functions.

So as we took a quick look under the hood and saw what is going on there, we can say that:

A function with the new keyword is a constructor function.
Using the new keyword binds car.__proto__ to Car.prototype.

Prototype

The prototype allows the JavaScript engine to look up the methods and properties we are trying to call on an object. The prototypical relationships in JavaScript create a tree-like structure where the root is Object.prototype. Thus, every object in JavaScript inherits from the root, which is Object.prototype.

console.log(Object.getPrototypeOf({}) == Object.prototype); // true
console.log(Object.getPrototypeOf(Object.prototype)); // null

We were just able to call a method on an empty object. That is magic (for those who do not know of prototypical inheritance). Let me explain it. First, JavaScript, in order to connect one object with another, has to create a 'link' or a 'reference'. How does JS do it? Really simple, it actually attaches it as another property on an object. Like so:

{} // our empty object
    [[Prototype]]:Object
        constructor:ƒ Object()
        hasOwnProperty:ƒ hasOwnProperty()
        isPrototypeOf:ƒ isPrototypeOf()
        propertyIsEnumerable:ƒ propertyIsEnumerable()
        toLocaleString:ƒ toLocaleString()
        toString:ƒ toString() // method we called
        valueOf:ƒ valueOf()
        __defineGetter__:ƒ __defineGetter__()
        __defineSetter__:ƒ __defineSetter__()
        __lookupGetter__:ƒ __lookupGetter__()
        __lookupSetter__:ƒ __lookupSetter__()
        __proto__ (get):ƒ __proto__()
        __proto__ (set):ƒ __proto__()

Here we see that even though we did not create the property [[Prototype]], it was added there automatically. It is something that real class-based languages like Java or C# do not have. For JavaScript, it is like an emergency source. When we try to call a method that does not exist on an object itself, the JS engine goes up the prototype chain and looks for it there. So in this case, the JS engine could not find it on our empty object, and instead went to a [[Prototype]] object and found it there. And if it did not find it there, it would throw an error:

console.log(empty.toNumber()); // Uncaught TypeError: empty.toNumber is not a function

Here we come to the essence of classes in JavaScript. In regular OOP languages, a class is just a type that is instantiated at runtime. In JavaScript, however, we have an actual instance of an object attached to our object and it is called, you guessed it, a prototype.

Summary

Classes in JavaScript were added because it was thought that people from other programming languages could pick up JS quickly. In some ways, this is true, but it also added extra confusion in terms of which approach is better. People not knowing how prototypal inheritance works want to simply patch it with classes. But as we saw earlier, a class is just a plain old function. There is nothing wrong with prototypal inheritance; it is just that the people responsible for JS development decided to go with the constructor pattern of prototypal inheritance.

In the next article, we will look at how to create objects with factory functions.

How JavaScript Tries to Imitate Classes and Is There a Better Way?

PabloHoudini — Sun, 09 Jun 2024 04:15:28 +0000

How JavaScript Tries to Imitate Classes and Is There a Better Way?

JavaScript, undoubtedly, can be a very confusing language, especially for those coming from traditional class-based languages like Java or C#. When JavaScript was first created by Brendan Eich, there was an intention to make it look somewhat like Java. This has led to some interesting design choices, particularly around how JavaScript handles object-oriented programming (OOP).

Today, I would like to take a quick look under the hood and see what is going on with JavaScript's approach to classes and prototypes.

The Evolution of Classes in JavaScript

Before the introduction of the class keyword in ES6 (ECMAScript 2015), JavaScript developers used constructor functions to create objects and simulate class-like behavior. Here’s a simple example:

// Constructor function
function Person(name, age) {
    this.name = name;
    this.age = age;
}

Person.prototype.greet = function() {
    console.log(`Hello, my name is ${this.name} and I am ${this.age} years old.`);
};

const john = new Person('John', 30);
john.greet(); // Output: Hello, my name is John and I am 30 years old.

In this example, Person is a constructor function, and we add methods to its prototype. This allows all instances of Person to share the same method, saving memory.

The Introduction of the `class` Keyword

With ES6, JavaScript introduced the class keyword, which provides a cleaner and more familiar syntax for creating objects and handling inheritance. However, under the hood, classes in JavaScript are still based on prototypes.

// Class syntax
class Person {
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }

    greet() {
        console.log(`Hello, my name is ${this.name} and I am ${this.age} years old.`);
    }
}

const jane = new Person('Jane', 25);
jane.greet(); // Output: Hello, my name is Jane and I am 25 years old.

Despite the syntactic sugar, the class keyword in JavaScript does not introduce a new object-oriented model. It simply provides a more convenient way to work with prototypes.

Understanding Prototypes

In JavaScript, every object has a hidden internal property called [[Prototype]] that points to another object. This is known as the prototype chain. When you try to access a property on an object, JavaScript will look up the prototype chain until it finds the property or reaches the end of the chain.

const animal = {
    eats: true
};

const rabbit = {
    jumps: true,
    __proto__: animal
};

console.log(rabbit.eats); // true
console.log(rabbit.jumps); // true

In this example, rabbit inherits the eats property from animal through the prototype chain.

Classes vs. Prototypes: What’s the Difference?

While classes provide a more structured and organized approach, prototypes offer more flexibility and control. Here’s a comparison:

Classes

Syntax: Cleaner and more intuitive, especially for developers from class-based languages.
Readability: Easier to read and understand.
Inheritance: Uses the extends keyword for inheritance.

Prototypes

Flexibility: More control over the inheritance chain.
Memory Efficiency: Methods are shared across instances.
Compatibility: Supported in all JavaScript environments, including older ones.

Real-Life Code Samples

Using Classes

class Animal {
    constructor(name) {
        this.name = name;
    }

    speak() {
        console.log(`${this.name} makes a noise.`);
    }
}

class Dog extends Animal {
    speak() {
        console.log(`${this.name} barks.`);
    }
}

const dog = new Dog('Rex');
dog.speak(); // Output: Rex barks.

Using Prototypes

function Animal(name) {
    this.name = name;
}

Animal.prototype.speak = function() {
    console.log(`${this.name} makes a noise.`);
};

function Dog(name) {
    Animal.call(this, name);
}

Dog.prototype = Object.create(Animal.prototype);
Dog.prototype.constructor = Dog;

Dog.prototype.speak = function() {
    console.log(`${this.name} barks.`);
};

const dog = new Dog('Rex');
dog.speak(); // Output: Rex barks.

Conclusion

JavaScript's approach to OOP through prototypes and the class keyword provides developers with powerful tools to create and manage objects. While classes offer a more familiar and organized syntax, understanding prototypes is crucial for mastering JavaScript. Both methods have their own advantages, and a good JavaScript developer should be comfortable using both, depending on the requirements of the project.

By understanding the underlying mechanics of prototypes, you can write more efficient and maintainable code, leveraging the full potential of JavaScript's object-oriented capabilities.

DEV Community: PabloHoudini

JS Inheritance - Part 2: Factory Functions vs. Classes

JS Inheritance - Part 2: Factory Functions vs. Classes

Introduction

Different Ways to Declare an Object

Class

Constructor Function

Factory Function

Factory Functions

Should You Use Factory Functions Instead of Classes?

Why We Should Not Use Classes

Functional Programming for Life

Some Code to Prove It

Summary

Understanding JavaScript Inheritance: A Deep Dive into Prototypal and Constructor Patterns

Understanding JavaScript Inheritance: A Deep Dive into Prototypal and Constructor Patterns

Introduction

JavaScript Inheritance

What is a Class?

Before the class Keyword

After the class Keyword

Prototype

Summary

How JavaScript Tries to Imitate Classes and Is There a Better Way?

How JavaScript Tries to Imitate Classes and Is There a Better Way?

The Evolution of Classes in JavaScript

The Introduction of the class Keyword

Understanding Prototypes

Classes vs. Prototypes: What’s the Difference?

Classes

Prototypes

Real-Life Code Samples

Using Classes

Using Prototypes

Conclusion

Before the `class` Keyword

After the `class` Keyword

The Introduction of the `class` Keyword