7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial

Next lesson playing in 5 seconds

  • Overview
  • Transcript

3.1 The Factory Pattern

Factory functions have become popular over the past few years. You'll learn the pattern and its advantages in this lesson.

3.1 The Factory Pattern

In the previous lesson, we started looking at how to create objects, and we ended the lesson with two very similar objects. In fact, for the most part, they are the same types of objects, although at this point in time, we don't really have types of objects, we have just objects. But they have the same interface and they have the same functionality. Now that latter point is kind of stretching it because they both have greet methods, but they don't really do anything. So instead, let's add some functionality here. Let's say hello, and then we are going to accept a parameter called names. So we'll just copy and paste this greets method into this other object. So except for the first name value and of course the name of the object itself, we have two objects that served the same purpose. Now in a real application if you need multiple objects of the same type this isn't the best way of going about doing it, just creating them one at a time. Of course you want some white to mass produce objects. And there are several different creational patterns that do just that. In this lesson, we're going to look at what's called the factory pattern. We're going to write a function that creates the object and returns it. So let's start by creating a function, and we'll just call it create person. Whenever you are going to use the factory pattern, usually the function is create and then whatever type of object that you're going to create. So in this case we're going to create some person objects, objects that represent individual people. And we'll go ahead and we'll have first name and last name values for our parameters. And we will create properties with first name and last name. So the first thing we need to do is create our object. So let's just call this object, person. We will use object literal notation and then we will assign the first name and the last name properties to the first name and last name values that were passed to this function. Now if we were running in an ES6 environment or ES 2015, whatever you want to call it, we could use just the shorthand version where we just have first name and a last name. But support for ES6 still isn't fully there, so we're going to do everything the old school way. So we will have first name and assign that the value. Last name and assign that the value. And then let's also create the greet method. So we're going to add that there. We have our name and then we want to return hello, and then concatenate the name there. So we are essentially creating our person object, and then we are returning it. So we can get rid of all of this extra code and we can just say createPerson and our first person is going to be John and his last name will be Doe. And then for obj2, we will have Joe Smith. So the first name is Joe, the last name is Smith. So we essentially get to do the same thing as we did before, but with considerably less code. Now, the factory pattern became very popular for creating JavaScript objects, for a variety of reasons. The first is simplicity. You simply create your object and return it, and we could even simplify this further by just saying return and then our object. So simplicity is the first, the second is that we can starts to take advantage of our function itself and use it as a closure, so that we can kind of emulate privacy. Now I say kind of, because the privacy that we can emulate Really isn't privacy. Especially when you compare it against other object oriented programming languages. But regardless, privacy is very important in object oriented programming, because it allows us to protect the vital pieces of an object. There are just some things we don't want people messing around with. So, for example, if we wanted to protect our first name and last name, well we can do that in a couple of different ways. The first would be to get rid of the first name and last name properties on our person object and replace them with a method like get first name or now we could just use a getter. So we could say get first name. And then we could return firstName. And we would do the same thing for the lastName. So we would have get lastName, and then we would return lastName. And in this way, the first name and last name properties are read only. So they cannot be modified outside of this object. And then we would have complete and total access to the first name and the last name parameters inside of this creates person function. So we could say something like this inside of our greets method. We could first of all greet the person that we are greeting, and then we could concatenate a message saying my name is, and then first name. So, my name is. And then we have two options, we could use the first name property Or we could just use first name because we have access to that parameter. Now, while the factory pattern does have its advantages namely its simplicity. There are some reasons why you might not want to use the factory pattern. First of all JavaScript itself is a language of types. You of course have all of the primitive types but then you have the reference types. Object, array, function, and a variety of others. And whenever you want to create an object, you typically do so using the new keyword. So var obj three equals new object. Now I know that in the previous lesson we got away from doing this. And instead we used a literal notation. But behind the scenes this is creating a new object by calling the constructor. The same is true for any other literal Centex. So whenever you use the over array literal, you are creating a new array. Whenever you define a function with a function literal, you are creating a function object by essentially calling new function. And so from that standpoint you lose some of the functionality that's built into the language. Like for example, these two objects obj and obj2 represent individual people. But the only way that we can verify that is by inspecting the object itself. Does it have a first name and last name properties? Does it have a greet method? If so, then it is one of these person objects. But there is the instance of operator that's built into JavaScript. And we should be able to say obj instance of. But we don't really have a type for this type of object. We could do objects but that's not really telling us anything because a lot of things in JavaScript are objects. We can't do create person because create person is just a normal function. So there's really no way to really check to see if our obj is one of these person objects unless if we inspect the properties that it has. So that's the first reason why you might not want to use the factory pattern. The second is more of a performance reason. Remember that functions in JavaScript are objects. Whenever you define a function, you are essentially creating a function object. And so every time that we call this createPerson method, we are creating a new function that is assigned to the greet property on each one of these person objects. So if we do obj.greet is identical to Obs to greet. This is going to return false, because every time we call the create person function we are creating a new function for the Greta method. And that is a waste of computational time as well as a waste of memory. Now admittedly this particular function isn't going to consume a lot of memory. But also keep in mind that this is just one and if we strive for really simple methods on our objects then we typically have a lot of methods. So if we have a large method, that's going to consume more memory, if we have a lot of smaller methods, those are going to consume more memory as well. Now, some people have said that we shouldn't really worry about memory, and yes, that's true on really powerful systems. On a desktop or laptop memory is very very cheap, but we are in an age of mobile computing. We have supercomputers in our pockets, but they are also sharing their memory and their CPU time with all of the other applications that are running at that given time. So memory is still an issue, just not for certain devices. Now the issues that I just mentioned for using the factory pattern can be solved by using another pattern. One where we define our own data type and we will look at that in the next lesson.

Back to the top