What do you want to learn?
Skip to main content
by Dan Wahlin
Start CourseBookmarkAdd to Channel
Table of contents
Function Spaghetti Code
Function Spaghetti Code Demo
Closures to the Rescue
Closures Demo 2
To wrap up this module, I'm going to briefly talk about different ways of defining variables. Now most of us are used to defining variables this way. You put a var. You put the variable name and then possibly assign it a value, followed up with a semicolon. And then if you have another variable, you do the same thing over, and kind of repeat and rinse every time. Well, there is another option for defining variables where you don't have to put the var keyword every time. And you'll see this in some of the samples coming up, which is why I wanted to cover it here. An alternative way to define variables is this way. We could define the var keyword once, define the variable, assign it, and then put a comma, and then anything that follows is just a new variable. It's like we put the var keyword right at the front. And this is definitely something you'll see in different patterns. People do it differently for sure. Some people prefer this top way. I prefer this bottom way now. And it just simply saves you a little bit of typing, makes the file a little bit cleaner once you get used to this pattern I think of defining variables. Let me show you how we can convert the closure example shown earlier to use this kind of comma technique with variables.
Defining Variables Demo
Prototype Pattern Pros and Cons
Prototype Pattern Structure
Using the Prototype Pattern
Prototype Pattern Extension Demo
Now that you've see an example of the prototype pattern in action, let's explore a few of the other options it has and one other thing I'm going to throw in, which is called namespaces. Now two big things are available with prototype pattern, two big benefits. Number one I mentioned that regardless of how many Calculator instances I create, there's only going to be one add function up in memory at any given time, and that's why we define the variables up in the constructor area, because those are going to be unique to the instance, whereas the different functions we have are down in the prototype area, and those are not unique to each instance. They're shared. The second big thing I mentioned is that a user of this particular Calculator object could override functionality if they wanted. So for example, if I don't like what the add function does, I don't actually have to come in to the source code and change it. I can override it separately, and that's pretty nice because if I got this off the internet somewhere, and I know new versions are going to come out, I don't really want to go in here and tweak it because then as I get a new version, I'd override my tweaks. Well, fortunately, we can use prototyping for that. So, if I just come up and say Calculator.prototype., and notice add shows up, I can actually override and put my own functionality without ever touching the original source code down here. So, let's just say that we want to do basically the same thing, but for some reason our add actually subtracts just to demo it. And now what's going to happen is when I call Calculator.add and pass 2 and 2, we're going to actually get 0 back and write that out down to our div. So, I've now overridden the functionality without actually touching the source code. So, if you're building libraries, this might be a pattern you might want to explore and consider because now people don't have to go into your library to actually make modifications. They can actually to it outside, even in a separate file if they want. So, if we run this, we should get back 0 now because our override will kick in, and you can see it does work. That's a really nice feature that can come into play with the prototype pattern. Now the final thing I want to talk about is not unique to the prototype pattern, but it's something you might use. This Calculator object, even if it was in a separate file called calculator.js, is going to be placed up in the global scope. Well, it's very possible you might use another script that also has something called Calculator. So what you can do is define your own little wrapper around this or what I'll call a namespace. So, I'm going to create something called my namespace (myNS). And what I'm going to do is say if my namespace (myNS) is already defined, go ahead and use it. So I'm just going to assign it to itself, and the reason you do that is maybe in another script, they already did myNS equals something, and I don't want to override that. So we're going to go ahead and say if it's already defined just to use it. Otherwise, create a new object and assign it. Now this is literally just an empty object. We're going to assign it to this. Now what I can do is I can prefix myNS on the front of Calculator. Now my Calculator is always going to be distinct from somebody else's Calculator object because of this namespace. Of course, now when I want to use it, I'm just going to comment out the override here, but when I want to use it, I'm going to have to say new myNS.Calculator. So if you've worked with namespaces in the .NET world or packages in the Java world or other languages have other features like this, we're basically adding a unique naming container, and we're putting the Calculator inside of that naming container. Now the only time I could have a name conflict now in my code is if somebody else had a myNS and a Calculator, which the odds of that are pretty bad, and if they do, unfortunately, you're going to have to fix that manually. So if we run this, we get basically the same thing. We should get 4 written out, and you can see it works. But now what we've done is we've put this out of---or taken this out of the global scope and into the myNS scope. Now myNS, yes, it is in the global scope, but we can now reuse myNS across all of our objects. So, typically, you might just use your company name, as an example, for this value. So that's an example of what you can do with namespaces and also how you can override with the prototype pattern.
Module Pattern Pros and Cons
Module Pattern Structure
Like all of the patterns that we're talking about in this course, the module pattern also relies on closures. So we have functions nested within other functions. So, here's what the basic structure looks like, and you'll notice that there's a special return statement, and I mentioned earlier that if you look back in module one at one of the closure demos I did, this looks very, very similar to it actually. So in this example, we're going to have an object called Calculator. Now this is going to have to be created itself, so we could use, for instance, the new keyword on it, and that's why it's uppercased. Again, that's a convention you'll see oftentimes that is kind of a giveaway that you have to initialize the object somehow. We're going to assign it to an anonymous function, which ends down here. And then our private members will go inside of this area, and this will be our variables and our functions, and then in the return block here, this is going to return another object literal. So an object literal, again, is going to have a name of something and then you'll associate that either with a value or a function. So in this case, we could put all of our public members inside of the return statement here, inside of the object literal. Anything outside of that, including these guys up here, will be private. Now when I say private, I of course don't mean they're private in the source code. You can always get to them in the code. But external callers won't see those, especially if you work with programs that have code help as you type. You won't see IntelliSense or code help in the little drop-down that pops down as you hit a dot or whatever you're using. So another example is shown here. Here we have a Calculator much like I showed with the prototype pattern, but this time we're using the module pattern. So you'll notice that we have an anonymous function. This is kind of like the constructor, and it takes one particular parameter. We're going to pass that parameter in, and that's going to grab the DOM element and assign it to this variable. Now this variable will be private automatically because it's not in the return statement. Now if we jump down to the return statement, though, you notice we have one single public member, and that is the add function. And the add function does what it says, basically takes two parameters, adds them, and then assigns the value to the inner HTML of the DOM object. So by doing this, if you were to create a new Calculator using this type of technique right here, when you hit calculator dot, and if you try to do calculator.eqCtl and try to get to this variable up here, you actually won't be able to. And that's because the way we're nesting things here, we've made it so that only the things defined in the return object literal will actually be made public. So it's kind of an interesting pattern you can follow that if you're used to the whole public and private methodology may appeal to you. It works out very well. Now there's another pattern we're going to be talking about called the revealing module pattern. It's based on this one, and it's going to change it up a little bit. So I won't go into it now, but it's going to simplify this part down here, make it a little easier to read, at least in my opinion. So that's a look at what the module pattern structure looks like, and the big thing to understand from here is we kind of have three mains parts. We have our constructor. We have our private member area. And then in the return object literal, we have our public members, and that's how the pattern works.
Using the Module Pattern
Revealing Module Pattern
In this module, we're going to take a look at the revealing module pattern, one of my personal favorites, and one I've used a lot in different web applications out there. So to start off, we're going to jump into what is this pattern, how does it differ from the module pattern, and what are some of the pros and cons? And you'll find that it's actually very similar to the module pattern. In fact, it has all kind of the same pros and cons associated with it. We'll then go into the overall structure of this pattern. And then from there, I'll show you several demos again of how we can use this pattern, and I'll show you a couple of ways you can use this pattern. So, let's go ahead and get started with what the pattern is and some of the pros and cons that it offers us.
Revealing Module Pros and Cons
In this section, we're going to talk about the revealing module pattern, and I'm going to compare how it kind of matches up with the module pattern, which was covered earlier in this course, and you'll see they're very, very similar actually. In fact, really the only difference is the way that things are exposed publicly, and you'll see this pattern used a little bit differently as far as creating objects. So, I'll cover all of that as we jump forward here. So, as I mentioned, it is very similar to the module pattern. It provides modularization of your code. It satisfies the three main tenets that I kind of keep harping on in this course, and that's reuse, better maintenance, and we don't want naming conflicts. We want to take variables and functions out of the global namespace. And it also allows you to provide public versus private members, whether it's variables or functions. Now the main difference, though, between this pattern is that the way you expose public members is a little bit cleaner. With the module pattern, you actually have an object literal, and the entire function that's publicly exposed is embedded in the return statement for the object literal. With this pattern, we're actually going to define it separately, and I think it actually is a lot easier to read, a little bit easier to maintain I would think as well. Now the other main difference is a lot of times you'll see this pattern used with a singleton. In other words, there'll be one object in memory at any given time, and you can actually do that with these other patterns as well, but it's something that you'll definitely see as you go research on the internet this pattern and look at some of the sample codes. So, I'll kind of show you both ways in this particular module. I'll show you the singleton approach and the just instance approach where you can create multiple instances if you'd like. Now, like the module pattern, it does have some cons. First off, any function that you define inside of your encapsulation container will actually be duplicated if you create a new instance. Now, if you're just doing a singleton, a single object that gets created, you'll be fine there, of course, because you only have one. But it is something to keep in mind. It's not something that's scared me away from the pattern personally because I haven't had an app where I had to create maybe thousands or even hundreds of thousands of objects of a similar type and worry about duplicating those functions in memory. But it would be something to be concerned about if you are creating a huge number of the same object in memory. It's not easy to extend, so this is really not a good pattern to go with if you need users of your code to easily be able to tack on new functionality and extend existing functions and things like that. So, that's really not the goal of the pattern, though. This is truly an encapsulation pattern. And just like the module pattern, some do complain about debugging because it's not as easy to get to the private members. And as I mentioned in the previous module on the module pattern, it's really I don't think that big of a deal to deal with. Yes, you do have to refresh your page maybe a little more often versus just changing things right there when you're debugging, but it's kind of up to you to decide if it's a blocking feature or not. So now that we've talked about what this provides as far as pros and cons, let's go ahead and move on, and we'll take a look at the structure.
Revealing Module Structure
The overall structure of the revealing module pattern is very similar to what you've already seen with the module pattern. And there's a good reason for that. When the module pattern first came out, people liked the fact that you could kind of divide up your private and your public members, but some people weren't super fond of how you defined your public members, because you define those in the object literal. But with the revealing module pattern, it makes it a little bit cleaner. I personally like it better, and it makes it easier to read, definitely easier for maintenance I think. So, here's an example of kind of the standard format and structure for the revealing module pattern, and you'll notice it's almost identical to what we saw with the module pattern. There're a couple of key differences, though, and I'll point out even more of these in the next couple of slides here. First off, you'll notice the name is lowercase. Now, you don't have to do it this way with the revealing module pattern, but the reason it's lowercase is you don't have to use the new keyword on it. Again, it's kind of a giveaway, something I've mentioned a couple of times throughout this course. You'll see this is a self-calling function. We're actually calling directly into the function, and we're not passing anything in this particular example. But because it's self-calling, and the user wouldn't have to use the new keyword to instantiate it, we're going to use the lowercase. Now, that is certainly just a convention some people follow. You don't have to go with that, but it is something you might come across out there on the internet as you research this and other patterns. Now, really the main big difference, though, between this pattern and the module pattern, is shown here. With the module pattern, we actually go in and we add the function and all the code for the function, the brackets and the body and everything, right into the object literal that you see there. Now in this case, the external caller is going to call calculator.add, and internally what it's going to do is forward that to doAdd, which you'll see is up here. So with this pattern, you can actually define all your private members all together, and that includes all your variables, all your functions, everything like that. Then the public ones, you simply give them a name, give them an alias. Now I normally name them the same. In this particular example, I wanted to show that you don't have to. But this could be doAdd forwards to doAdd if we wanted. It could be foo forwards to doAdd. And that'll forward up to here. Now what's nice about that is now your return section, your object literal, that gets returned to the caller of this particular script code only sees the public members that you expose in the return. Now that's identical to the module pattern, but I think it's a lot cleaner now because now you just simply match up the names. You can see here also it's self-invoking. So, right as this function's parsed, it'll then be invoked immediately. And we're going to pass in eq control up into the parameter, which is then used for this variable here. So, that's really the main difference. Now, because it is self-invoking, you would simply say calculator.add, and then you would pass in your two parameters that you want to pass in here. Now, if we compare that really quickly again to the module pattern, here's an example of that one, and you can see that we still have an add, but the function is actually embedded directly in the object literal, which starts here and ends here, and then we return that. So, it gets a little messier. I personally think it's a lot harder to read this way. But it is something you can certainly do. I personally think this is a lot cleaner, though. Definitely easier from a maintenance standpoint. From the standpoint of encapsulation, keeping things out of the global scope, the global namespace if you will, both patterns are equal. From the standpoint of reuse, both patterns are equal. But when it comes to maintenance, I just think this one's more clean, but that's kind of up to you to decide. So that's what the revealing module pattern structure looks like, and that's kind of how it's compared to what you would do for the module pattern that we looked at earlier in this course. Now you can also use this type of syntax with the revealing module pattern. Simply remove the parentheses. And I'll demonstrate that coming up in the demos that follow. Let's go ahead and move on. We'll take a look at some sample code.
Using the Revealing Module Pattern
Now that you've seen what the revealing module pattern offers and the overall structure of the code, let's take a look at a few demonstrations of how it can be used in different scenarios. Let's get started by creating a new HTML page, and I'm just going to call this RevealingModuleDemo.html, and we'll come in and add a script block. Now I'm going to have an Output area as you've seen in some of the other demos. We'll write some Output data too. And what I'd like to do is because I'm going to do the self-invoking revealing module pattern demo, I need to make sure that the DOM, at least this DOM element called Output, is loaded before my script actually runs. You'll see what I mean. So, what I could do is I could come in and put my script right up here inside of the onload, but if it was a separate script, that's not going to work out. So, what I'm going to do instead is I'm just going to put a script block right under this, and although I could load a separate script, we're just going to do it inline. We'll kind of pretend that it might actually call calculator.js or something like that. This is where I'm going to demonstrate the code that you've already seen up to this point for the revealing module pattern. So, we'll go ahead and make a calculator, and I'm going to pass in one parameter. And there is our wrapper. So, if you come from a class background, again, this would be very analogous to a class in this particular case. Now I'm going to come in and make a variable, and it's going to reference the DOM element above, so we'll pass in eq. And then I'm going to make my object literal, and so this will represent my private members, and this will represent my public members. Okay, now instead of actually putting all the function code inside of the return block here, the object literal, we're going to go ahead and make it a little cleaner by following the revealing module pattern, which basically says let's come in and let's make our functions up top. So what I'm going to do is go ahead and put a comma there, move that over, and we'll have---let's do two of them. We'll do an add and a subtract. And then for the add, we'll just simply grab this and update the innerHTML to X plus Y. And I'd do the same thing here normally, but I don't want them---they'll run so fast you wouldn't see the difference between the two, so let's just do an alert because I'm going to call both in succession, and we'll do X minus Y so we can see it just works. Okay, now if I were to come in and run this as is, I would have to new-up the instance because we're not self-invoking. So, what I'm going to do is change that to be more of a singleton where we'll have one instance of the calculator in memory at any given time. And we'll do that by simply passing in the ID we want, which is this one, and we'll self-invoke the function. So when the script parses or gets parsed down to here, it'll then self-invoke the function, pass this up in, and then it'll be used in the script. Now if we were to come into here in the window load and now say calculator., and call add, we wouldn't be able to call it. So I can go ahead and add this code, but it's not going to do anything at this point because we haven't returned anything in the object literal. So we'd get a script error if we tried to run this. So, what I'm going to do is simply say, "What do we want the alias of the internal function to be?" So, let's say it was doAdd, but I want it to call add, and we might have doSubtract, which calls subtract. Now I'm providing an alias that the external caller of my script would use, but internally it's going to forward it to these guys. Now I normally don't do that. I normally name them as is. So we'll call them like that especially since I already have it set up that way. Okay, so basically what'll happen is once this guy gets parsed, our script then gets parsed, it self-invokes the function. That sets up all these internal members. We expose both of these functions publicly, and now we're ready to go, and we can just call this object directly without having to new it up. It's a singleton. So let's go ahead and View in Browser, and we should get an alert, and then we'll get the 4. Now it looks like we didn't get an alert, so let's take a look at our script error, has no method 'subtract,' which probably means I have a typo down here, and I do--'substract.' Let's go ahead and change that. We'll run it one more time. And there we go. We get that, and we get that, so we get our add and our subtract called. So you can see that it really does matter obviously what you name these. Again, if I were to call this doAdd and doSubtract, then down here we would need to call them this way as well. Otherwise, the client would never see it. But now it kind of lets you name things like you want the public API to be called, and it allows you to name things whatever you want internally, which can be useful in some scenarios. So that's an example of getting started with the revealing module pattern. Now let's look at some more involved demos of using the pattern. So I also have an example of the calculator. Now we've seen this same calculator for the prototype pattern and the module pattern. Now we're going to see it again, but now it's using the revealing module pattern. So the script is here, and you'll notice this actually follows the same type of thing we've been working with. You'll notice it's lowercase. If I come down to the bottom, you'll see it's self-invoking. That's why we're going to go ahead and go with lowercase there, so it's kind of obvious to the user that you don't have to use the new keyword. Other than that, it's identical. There's just more code. All of our private variables. We have a lot of different functions, you can see here, that perform the calculator functionality are defined. You'll see all those in here. And then as I scroll to the very bottom, you can see that we're only exposing four different members from above as public members for this calculator functionality. So, that's what I really, really like about this pattern is that it's very, very simple to only expose what you want if you're into the whole public and private member type of thing. And this makes it very easy to work with that. In fact, it's kind of nice because there've been times in real apps where I've actually forgot to list something here, and then instantly I'll kind of say, oh yeah, I didn't expose that publicly. So, by default, everything is kind of private, much as it would be in traditional object-oriented languages. So, if we run this, it'll just run the same calculator you've seen a couple of times but now using the revealing module pattern. And you can see it works as you would expect. So, now we've satisfied those three main tenets I keep talking about in this course, which is we now have reuse because we can reuse this calculator object, we have excellent encapsulation of our data for maintenance, these functions are only unique and only used for this calculator object, and we've taken everything out of the global scope except for this guy. So the final one I want to show that uses this pattern is script that's related to the HTML5 canvas. So I have a Chart.html, and you'll notice I'm using jQuery in this example to detect when the DOM is actually loaded. And we're going to actually create a new instance of something called CanvasChart. Now CanvasChart is right here. You'll notice it's uppercase. And let's go look at the very bottom of it. And that's because this is not self-invoking. Now you can see it is the revealing module pattern. We don't have any functions in here as with the module pattern. We're not using the prototype keyword, so it's definitely not the prototype pattern. And all my functions are now referencing others. Now this one has quite a bit of code in it and quite a few other functions. Now, I won't be able to go through the canvas code, but if you are interested, there're other HTML5 courses on Pluralsight.com if you want to get more into what I'll show you here with the canvas API. So, you can see all of our private members. We have quite a few variables up top, several different functions that handle the rendering of our canvas, and then we only expose two of those, though, to external clients-- renderType and a render. So back here in Chart.html, once this DOM is loaded, I'm going to go ahead and create a new instance. Now this is not a singleton because I might want multiple charts on one page. Not a problem. We just take off the self-invoking parentheses at the end of the revealing module code, and that lets us new it up. So what this does is you can pass in some information about the chart, such as what's the title?, the X and Y labels, font information, what do I want to render?, do I want lines?, do I want points? And in this case, I'm doing both. And then this is the actual data that the chart is going to plot, so this represents U.S. population data at different years and then shows in millions how many people lived then. Now what we're going to do from there is we're going to pass the name of our canvas, which you'll see is right here, the ID I should say of the canvas, into the render function, along with all of this data definition code, which is just a JSON object you can see here going down to here. Now what this will do is render a nice little chart without any plugins right here in the page. And there's an example of using the canvas API. Although this is a little more fancy as far as the code, especially compared to the calculator, I'm still able to leverage the same revealing module pattern structure that we've talked about in several of the different demos up to this point. So that's an example of different ways in which the revealing module pattern can be used, and I hope that gets you started thinking about how you can use it in your applications.
So in sum, the revealing module pattern provides a great way to encapsulate variables and functions into a reusable object, and it allows you to along the way expose different members as either being public or private. So in that regard, it's very, very similar to the module pattern. However, it does provide, at least in my opinion, a cleaner way to expose your public members as compared to the module pattern we talked about. And one of the downsides of this pattern is, again, if you want to work with, say, libraries and you do expect people to be able to extend existing functionality, you don't want them to have to tweak your source code, then this is not as flexible as the prototype pattern that we talked about earlier in the course. So it's important to keep that in mind. However, in scenarios where you're simply writing functionality that's very custom for a given application, I think it can definitely be a pattern that you can jump into and use effectively to promote reuse, to simplify your maintenance, and to make sure that you keep all your functions and variables out of the global scope. And that's a wrap on using the revealing module pattern.
Revealing Prototype Pattern
Revealing Prototype Pros and Cons
Revealing Prototype Structure
The revealing prototype pattern pulls from the revealing module pattern and the prototype pattern, as mentioned earlier, so several aspects of those patterns are going to be used in the code and the structure of the code. So, a simple example of getting started with the pattern is shown here. And this very first example looks very much like what we saw with the prototype pattern, but there's one key distinct difference, and I'll kind of tie that in at the end of this section. So, first off, we have a constructor area up at the top. We have a Calculator. And you can see it has a constructor that takes one particular value. All of our variables would then be defined in here. Now when you define those variables, you will need to use the 'this' keyword to do that, so I'll show an example of that actually coming up. Now once you've defined your constructor, then you can define the actual functions. Now those are going to be moved into the prototype section, though, so you'll notice it is separate from our constructor area. But this is very different than the definition we saw earlier with the prototype pattern because instead of assigning an object literal to the prototype, we're actually assigning an anonymous function, and then we're self-invoking the function. So, really, this is following very much along the lines of the revealing module pattern, and so this is how we're going to get the public/private capability where we can mark some things as private and mark some things as public as needed but still be able to prototype because we want to build a prototype. Prototyping is good for extensibility and adding new features onto existing code. So, in this example, we assign the prototype to a function. That function is immediately invoked. Now this does not create a singleton in this example because our constructor is separate, so it is different from the revealing module pattern in that regard. You're still going to have to new-up the object to use this calculator. What this will do, though, is all these functions that'll be defined here will be made available instantly through the prototype. Then once we create a new instance, we'll be able to get to those functions. So I'll show a demonstration at the end of this particular module. Now, where does the revealing module part tie in? Well, you can see it right here. What we're going to do is inside our object literal, any functions that are defined up here, we're simply going to reference here. So, we're going to do it in exactly the same way as we saw in the revealing module part of this course, and I'll show you another example of that again coming up as well. So, we really have the best of both patterns. The prototype pattern's being used here, although we're using kind of the revealing module pattern to assign the functions to the prototype, and then the revealing module pattern is obviously used not only for the assignment here but also in the way that we're exposing our public members. So it's a really nice thing to work with, very easy. Now we get the benefits of extensibility and the public/private hiding or showing to the external client our functions if we want. Now here's a more filled in example of the revealing prototype structure, and you'll notice that we have our constructor area. We're passing in a parameter, and then we're assigning that to this variable eq.Ctl. So, we're going to grab the DOM object and assign it. Now the reason we put the variables in here is we don't want to put them in the prototype section because then they'd be shared across everything. So, if we had 50 objects, they'd all share everything, and that would definitely be bad. So, instead, what we're going to do is define all our variables in the constructor area. That way, when we new it up, each new copy of the object gets a fresh of variables. But we'll still be able to share the functions across all objects. They won't maintain any state. All the state will be stored in the variables. So, in this case, you'll notice we have a very simple add function. So, we have add equals an anonymous function, takes our X and Y, does its thing. This is private by default because of the way we've defined the function and assigned it to the prototype. To make it public, we're going to follow the revealing module pattern. And so we're going to say return. In this case, we're going to name it the same. This'll be the alias that the external caller will call, and it's simply going to forward that call to the add function that you see here. It makes it very easy to hide or show the different members, just like the revealing module pattern. Now if you were to compare this again with the actual prototype pattern, especially as you're learning these patterns, it can be a little tricky to remember which is which, the big thing to remember here is the revealing prototype structure really falls along the lines from the prototype equals down the revealing module pattern. Whereas the prototype pattern uses an object literal to assign the functions to a prototype. Here's an example of that. And I'll come back to that. So, here's the prototype structure, and kind of reviewing this, everything up top's the same, but notice down here it's very different. We just have an object literal that starts and ends, and then we define our functions. Whereas, with the revealing prototype pattern, we use very much along the lines of the revealing module pattern. That way, we get the benefits of the public/private if you want that. Now if you don't want that, you probably should just go with the regular old prototype pattern if you'd like. But if you do like that, this is a great way to go. Now you can see an example of actually using this. We simply create a new Calculator object. We pass in our initial constructor parameter, and then we can call the add function because the add function is defined publicly. So that's an example of how to use it and comparing it with the prototype pattern. So, now that we've taken a look at that, let's jump into some examples of how we can use the revealing prototype pattern.
Using the Revealing Prototype Pattern
Using the Revealing Prototype Pattern with 'this'
Extending the Revealing Prototype Pattern
One of the best features of the revealing prototype pattern is the ability for external users of your script or library to override or even extend functionality that you've defined without touching your source code. Now, I showed a simple demonstration of this with the prototype pattern, but I'm going to show that it also works with the revealing prototype pattern. So, I'm going to open up the simple demo we did initially in this section. And what I'd like to do is, let's change the add functionality instead of maybe adding, we're going to come in and maybe we want to, let's say we want to multiply, something like that. So, we're going to say Calculator.prototype., and now we can get to the add, and we'll give it a different function, so we're going to override it now. And now it's up to us what we want to do. So, let's just go ahead and we'll grab 'this' and the variable, and let's just multiply them. And so, we'll have 2 times 2, which is 4, which isn't going to be very impressive, so let's go ahead and change this a little bit. Let's do 3 and 3 there. So, normally, we should obviously get 6, but now we should get 9 if the override works appropriately, and that's all you have to do. So what's beautiful about this is, if our script is in a totally separate file, I don't have to go in and actually touch that script at all. I can extend functionality. I can even add new functionality if I want to the Calculator object just through the prototyping. Let's go ahead and try this out. We should see 3 times 3. We should get 9 instead of 6. And there we go. You can see that it worked. Now of course if I comment this out, we should be back to the normal, and we should get 6, because it's going to do the regular addition function. And you can see that worked as well. So that's an example of how easy it is to actually extend this type of pattern. That's one of the big strengths of this pattern is that you can allow users to do this type of activity without having to modify your source code.
Converting Code to the Revealing Prototype Pattern
Released12 Dec 2011