Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Js design 1
  • Overview
  • Transcript

4.1 The Facade Pattern

The Facade pattern is well-suited for uniting disparate APIs into a single public-facing interface that connects with the other APIs behind the scenes. It's been in use in JavaScript for a long time, and you may have used it many times without even knowing it.

4.1 The Facade Pattern

Hello folks, in this lesson we're going to take a look at the facade pattern. A facade is a simple interface that is exposed publicly to hide the complexity of an underlying subsystem. Like an oaken veneer over rough cut chip board, a facade conceals the underlying implementation and presents a smooth and easy to use exterior to the outside world. This is a structural pattern which simplifies the use of your API for consumers. It also has other benefits, such as shielding you from becoming locked into a particular architecture. You can refactor and change the internal API as much as you want, while leaving the methods exposed by the public facing facade unchanged. Or at least with minimal changes. Maybe they can accept new arguments, or something like that. This pattern has been around for a long time in JavaScript. Ever since frameworks wrapped a simple interface around the descript and disconnected APIs that different browsers exposed donivent through, for example. To illustrate the general idea of the facade pattern, let's put together a simple module that will process different JavaScript types in different ways. First of all, let's create a new directory called Facade. Inside this, we can add a new file called Processor. This module will return an API consisting of five methods that each process a different JavaScript type. So I've tried to keep it simple here. Each method is just a single line that handles a type in a particular way. It doesn't handle each type very well, it just does one thing and then passes it back. This module doesn't depend on the facade, it knows nothing about the facade, it just exports it's API as normal. It could depend on other modules of course, but it shouldn't depend on the facade. The facade itself does depend on the module or modules for which it is the facade. So let's create a new module called Facade Now. We need to use the require function here so we can load the processor module that the facade is going to wrap. After we've loaded the processor as a dependency, we can return a single method from the facade. In the single method returned by the facade, we can have a switch statement that invokes on of the processes methods, depending on the type of thing that was passed to it. So the value that we're switching on here is the type of object that was passed to the process theme method. And we're using the object.prototype.tostring.call technique to convert the type into either object string or object number or whatever the type of the thing that was passed in. And then in each case, we just call the appropriate method and pass in the thing arguments. So let's carry on now and just add the rest of the case statements. So that should be what we need to do. Let's add the init file for this example and try out our facade. So the consumer, which in this case is the inits module, doesn't know anything about the processer directly and it doesn't depend on it. It just depends on the facade and it just knows how to invoke the facades process thing method. So in order to run the example let's just update the main JS file. And the array is starting to get quite long here so I'm just gonna break onto another line. And let's try running it in a browser. So we do have a script error there. Let's see if we can see what's going on init.js, line 11. And we need to actually pass a boolean. So the init file is nicely decoupled from the processor and knows nothing of the underlying complexity. If we need to, we can refactor the processor as much as we want to, as long as the API exposed by the doesn't change any consumers are shielded from the change. So in this lesson we looked at the facade pattern. We learned that it is a structural design pattern that is used to hide the complexity of the subsystem, and presents a simplified interface to consumers. We learned that it can also allow us to make changes to the underlying subsystem that don't ripple out to consumers. Thanks for watching.

Back to the top