1: Pseudoclassical

JavaScript is conflicted about its prototypal nature. Its prototype mechanism is obscured by some complicated syntactic business that looks vaguely classical.

Instead of having objects inherit directly from other objects, an unnecessary level of indirection is inserted such that objects are produced by constructor functions.

1: Pseudoclassical

1: Pseudoclassical

The pseudoclassical form can provide comfort to programmers who are unfamiliar with JavaScript, but it also hides the true nature of the language.

The classically inspired notation can induce programmers to compose hierarchies that are unneces-
sarily deep and complicated. Much of the complexity of class hierarchies is motivated by the constraints of static type checking.

JavaScript is completely free of those constraints. In classical languages, class inheritance is the only form of code reuse. JavaScript has more and better options.

2: Prototypal

In a purely prototypal pattern, we dispense with classes. We focus instead on the objects.

Prototypal inheritance is conceptually simpler than classical inheritance: a new object can inherit the properties of an old object.

2: Prototypal

2: Prototypal

3: Functional

One weakness of the inheritance patterns we have seen so far is that we get no privacy. All properties of an object are visible. We get no private variables and no private methods. In frustration, some uninformed programmers have adopted a pattern of pretend privacy.

If they have a property that they wish to make private, they give it an odd looking name, with the hope that other users of the code will pretend that they cannot see the odd looking members.

Fortunately, we have a much better alternative in an application of the module pattern.

3: Functional

We start by making a function that will produce objects. 

1. It creates a new object. There are lots of ways to make an object. It can make an object literal, or it can call a constructor function with the new prefix, or it can use the Object.create method to make a new instance from an existing object,  or it can call any function that returns an object.
2. It optionally defines private instance variables and methods. These are just ordinary vars of the function.
3. It augments that new object with methods. Those methods will have privileged access to the parameters and the vars defined in the second step.
4. It returns that new object.

Useful If contstructors take lots of parameters

3: Functional

The my object is a container of secrets that are shared by the constructors in the inheritance chain. The use of the my object is optional. If a my object is not passed in, then a my object is made.

3: Functional

Let’s apply this pattern to our mammal example. We don’t need my here, so we’ll just leave it out, but we will use a spec object. 

The name and saying properties are now completely private. They are accessible only via the privileged get_name and says methods:

3: Functional

3: Functional

Creating the cat

3: Functional

The functional pattern also gives us a way to deal with super methods. We will make a superior method that takes a method name and returns a function that invokes that method.

The function will invoke the original method even if the property is changed:

3: Functional

Let’s try it out on a coolcat that is just like cat except it has a cooler get_name method that calls the super method. It requires just a little bit of preparation. We will declare a super_get_name variable and assign it the result of invoking the supe-rior method:

3: Functional

The functional pattern has a great deal of flexibility. It requires less effort than the pseudoclassical pattern, and gives us better encapsulation and information hiding and access to super methods.

If all of the state of an object is private, then the object is tamper-proof. Properties of the object can be replaced or deleted, but the integrity of the object is not compromised.