What is the difference between the Prototype pattern and the Construct pattern?

In JavaScript OOP is prototype based, there is no concept of "classes". What you know as a class in procedural languages ​​like C#, Java or Python does not exist in JavaScript.

It is very common for new developers or developers who come from non-functional languages ​​to get confused, and it is not for less, the concept of object orientation is quite particular in JavaScript.

prototypes

Almost all objects in JavaScript have a prototipo. A prototype is simply an object "within another", but not just any object, but a special object; within this object the properties are stored. When a property of an object ( objeto.propiedad) is requested, what happens is that it will start looking for it first in the object, if it is not there, it will look for it in the prototype, and so on in a chain.

Since when looking for a property in an object, it will also look in the prototypes that exist within the object, it is a good practice to use hasOwnProperty, which will return true if the object directly owns said property.

An interesting question is: if the object is empty and has a prototype, who does it belong to? The response is to the parent prototype: Object.prototype. Do a test with the following statement:

console.log(Object.getPrototypeOf({}));

What you will see in the console will be: Object.prototype. But if you do instead, you Object.prototypeOf(Object.prototype)'ll see that it prints null, because Object.prototypeit's the parent of all prototypes and obviously doesn't have a built-in prototype.

The availability of "universal" methods such as toStringand is due to this prototype valueOf. There are also objects that do not necessarily have Object.prototype, but instead Function.prototypeas is the case with isNaN.

builders

An interesting note is that it Object.prototypehas a function called constructor, this function is called when you make use of newand returns an instance of the function thisassociated with it. Likewise, each instance will have a prototype derived from Object.prototipo.

There is an important difference between object and Constructor prototypes: all objects have a derived prototype of Object.prototype, while the prototype of Constructoris Function.prototype, because it is a function.

Consider this example:

function Car () {

}

var ferrari = new Car();

console.log(Object.getPrototypeOf(ferrari)) // object
console.log(Object.getPrototypeOf(Car.prototype.constructor)) // function

As you can see, even though it constructorhas a prototype of type function, the instance of Car is assigned a prototype of type object.

Exhibit

Banana/Gorilla Problem

"The problem with object-oriented languages ​​is that they have all this implicit environment that they carry with them. You want a banana but what you get is a gorilla holding the banana and the whole jungle." -Joe Armstrong

I think Joe Armstrong could not have summed up the problem of heredity with a better analogy. But what does he mean by this? The answer is simple:

"Para obtener una funcionalidad específica, debes hacerte cargo de lo demás implícitamente"

When working with classical inheritance, it is very common to do an initial design and as requirements change, refactor classes and hierarchies at the risk of breaking everything . Also, it's not modular, so what if you need class features Aand Cbut don't want to inherit all of its functionality? This is where composition becomes important .

Functional inheritance or composition

The great Douglas Crockford talks about the "dangers of classical inheritance and this" in JavaScript. He discusses factory functions , which are functions that create objects and don't need the this. This "pattern" is widely used by "anti-class" JavaScript developers. For example:

const Dog = (name) => {
  return {
    name,
    description() {
      return `Hi, my name is ${this.name} and I'm a ${this.race}`
    }
  };
};

const Rottweiler = (name) => {
  const dog = Dog(name);
  return Object.assign({}, dog, {
    race: 'Rottweiler'
  });
}

const bobby = Rottweiler('Bobby');
console.log(bobby.description()); // Hello, my name is Bobby and I'm a Rottweiler

As we can see in the previous code, functional inheritance or composition is much more modular, it's like lego, you only use the pieces that you need to use. This type of inheritance is much easier to refactor.

Object.assign vs Object.create

How does one way and the other affect the attributes and functions of those objects?

When you use a constructor to create instances, you will often need to use hasOwnPopertyit to find out if an object has a certain property (and not look at the internal prototypes), which if you forget can make a logical error. The same goes for objects created using Object.create. On the other hand, creating objects by assigning new values ​​to a prototype Object.assignavoids this inconvenience.

Look at the following example:

const Human = (name) => {
    return {
    name,
    sayHi () {
        return `Hello, my name is ${this.name} and I'm a ${this.gender}`;
    }
  };
}

const Man = (name) => {
    const human = Human(name);
  return Object.assign({}, human, { gender: 'man' });
};

const Woman = (name) => {
    const human = Human(name);
  const woman = Object.create(human);
  woman.gender = 'woman';
  return woman;
};

const man = Man('Sebastián');
const woman = Woman('Milett');

console.log(man.hasOwnProperty('name')); // true
console.log(woman.hasOwnProperty('name')); // false

Note: It can be emulated Object.assignusing Object.setPrototypeOf.

Performance

Can I combine them to further optimize memory?

About performance I have no idea; however, I don't think it's a big deal most of the time unless you're creating a lot of objects (and I mean, a lot of objects). You can do a test to find out.