Instantiation Patterns at the FroYo Shop

Learning how to make object classes in Javascript can be a daunting task, but when you realize that the four types of instantiation patterns are all means to the same end product, it becomes slightly more straightforward. I am going to attempt to explain the similarities and differences between the patterns using an analogy of going to frozen yogurt shop to make your own personal FroYo creation.

The four instantiation patterns are: Functional, Functional-Shared, Prototypal, and Pseudoclassical.


In this example, you can see that a bowl is our object and within the bowl there are three properties and two methods. Every time the FroYo object is instantiated, a bowl object is created along with its properties and methods, and then returned. It makes a lot of sense to have all the properties and methods available in one nice little package, but it will become redundant if you are making many new FroYo objects.

When you go to the Functional FroYo Shop, you must bring your own bowl, cherry, and spoon to eat with. Although you have equipped yourself with all the necessary tools to eat your Frozen Yogurt with, it is an inconvenience to bring these things to the yogurt shop every time you want to eat (and remember, they are not giving you a discount for providing your own supplies).


When you make a constructor function using the functional shared method, you must still create an object within the function and attach the properties to that newly created object. The “shared” part of this instantiation pattern are the methods. The methods are stored in another object so that it does not have to be recreated with every instance of your object. In order to link the constructor with the other object where the functions are stored, you can use the underscore method “extend” or refer to them as I’ve done.

If you go to the functional shared frozen yogurt shop, you are still going to have to bring your own bowl. Unlike the functional FroYo shop, they have spoons and cherries available on loan to their member customers. The spoons are shared and maintained by the staff, but you must have access to them using their “extend” pass for members. Going to the frozen yogurt shop is now a little bit more convenient, but it could definitely be less of a hassle.


The prototypal instantiation pattern continues with the pattern of splitting up the properties and the methods. Instead assigning the bowl object to be an object literal, you must use the Object.create() method to make a new object. Oftentimes, it is made using the constructor’s prototype. However, this can be misleading. The object in your constructor needs to be made using the name of the object that stores all the methods. Usually people just put the methods in the object’s prototype, but it can also be another object with a name that is not the prototype.

The prototypal FroYo shop poached the idea of sharing utensils from the functional-shared shop but gave their members an added bonus — member only bowls. These bowls are granted when you get to the shop and flash your members only card. In addition to creating the bowl for you, they give you access to the house cherries and spoons.


When using the pseudoclassical pattern, there are a few operations under the hood that eliminate redundancy in your the code. In the other three instantiation patterns, we had to create the bowl object and return it; in the pseudoclassical style, an object is created and returned automatically. We will refer to the object that is created as “this.” In addition to creating the object “bowl,” the interpreter also creates the FroYo.prototype which is available for our methods to be stored in. In the method functions, we need to refer to our bowl as “this” because we weren’t able to actually identify it as a bowl, we are just trusting that the interpreter made an object for us and is calling it “this.” One of the most important parts of the pseudoclassical pattern is when you make an instance of the FroYo object, you must use the new keyword. It is such a small detail, but if you don’t use the new keyword, the interpreter won’t know to automatically make the bowl object and return it.

The pseudoclassical pattern is what we most commonly experience when going to the Frozen Yogurt Shop. It is assumed that there are bowls, spoons, and cherries available for us when we show up. Now we can refer to our bowl as “this” because it was provided for us automatically. The pseudoclassical pattern eliminates the inconvenience of everyone bringing in their own utensils.

I am still new to Javascript so trying to find analogies for these tricky topics has helped me get a better grasp on them. I hope you have also learned something about Instantiation Patterns. Please feel free to leave any feedback you have for me. I would love to hear from experienced programmers as well as newbies and everyone in between!

Functional — Functional/Shared — Prototypal — Pseudoclassical