Hey everyone and welcome to Developer Tea my name is Jonathan Cutrell and today we're going to be talking about the difference between the facade and the beckerator patterns. I want to say a quick thank you to today's sponsor Digital Ocean and just 55 seconds on Digital Ocean you can deploy an SSD cloud server and their plans started $5 a month later on we'll talk about how you can save a little bit of money because you are a Developer Tealistener but for now let's go ahead and jump directly into today's topic. We're going to be talking about the facade pattern and the decarator pattern how they are different how they are similar and when you would use each of these patterns they're very similar to each other in some ways but there are a few extra things that you need to know about when each pattern is applicable. So we're going to start with the facade pattern because the facade pattern in my opinion is kind of the fundamental idea of composition and abstraction. Basically what the facade pattern allows you to do is take single step methods or a single responsibility methods and compose them together into larger meta responsibilities. A perfect example of this is withdrawing from a bank account. So first you have to verify that whoever is trying to withdraw is able to an authorized to withdraw from that bank account so that might be one method. Then the next method might be actually checking to make sure that the amount that they want to withdraw is available in their existing funds and then the next method may be a dealing with it if it isn't or actually pulling the money if it actually is available and then finally updating anything else that needs to be updated at the end of that withdrawal. So the reality is we call this entire process withdrawal but we know that each of these individual steps has to happen every time withdrawal occurs. So what the facade pattern allows you to do is abstract away each of those individual steps, each of those individual methods into a method that we can call withdrawal and what this does is it allows us to not have to remember each and every individual step and it gives us a more semantic way of describing this larger task and the responsibility principle is not violated. It is just a different scope of responsibility. Now it's important to note that the facade pattern is not intended to create a unified interface. For example, J query was built as a library to unify the different ways of doing Ajax. That is not what the facade pattern is intended to do. The facade pattern instead is intended to hold multiple steps that are visible. It's not intended to abstract away all of the discrepancies between different underlying technologies. Now you may be wondering why you wouldn't call that a facade, why you wouldn't call fixing the inconsistencies between browsers, for example, why you wouldn't call that a facade pattern. The reason for that is because there are other patterns to describe that process. Namely, there is the adapter pattern, for example, that kind of unifies the interfaces between different implementations. The facade pattern serves to encapsulate functionality that goes together cognitively, so that withdrawal being the meta method and each of those individual steps being the underlying methods that the facade is encapsulating. In reality, we see this at play all the time. In fact, I would argue that most of the classes that we create are actually doing this process. It just so happens that a lot of their encapsulated methods are part of the standard class. For example, manipulations of strings are inside of your methods, but those methods are actually implemented in another location. Your class in many ways is actually just a facade pattern at play without you even knowing it. There's a little bit of a disclaimer that I have to give here. There's probably a better formalized definition of when something is or is not considered a facade, but for the sake of practical use and for the sake of actually writing code today and utilizing the facade pattern, what you've heard in this podcast is the facade pattern kind of insomeration. I'm going to talk to you about decorators next, but first I want to talk to you about today's sponsor, Digital Ocean. If you've ever had a hassle setting up a server, then you know how frustrating it can be. Digital Ocean is basically the opposite of that. There's simple cloud hosting that's built specifically for developers actually went through the process of setting up their $5 droplet. That droplet has 512 megabytes of RAM, a 20 gigabyte solid state drive and a CPU with a full terabyte of transfer all for $5 a month. I set it up in 55 seconds. 55 seconds is all it takes to set up a solid state cloud server with Digital Ocean. Check it out, digital ocean.com. They've been kind enough to provide Developer Tealisteners with a code to get $10 off. That code is very simply Developer Tea, all one word. Of course, that code will be in the show notes and the link will be in the show notes as well. Check it out digital ocean.com. That would be a great place to practice some of these patterns that you're learning here on Developer Tea. We've already covered the facade pattern today. Now let's talk about decorators. What exactly is a decorator? A decorator is similar to the facade pattern, but instead of encapsulating existing functionality, it takes existing functionality and in a way extends that functionality. Those of you who are listening very carefully and have some experience with object or any programming, you might think, well, this sounds a lot like class inheritance. When I have a subclass, for example, I can add new methods to that subclass and I've extended the original methods. I inherit from the parent class and that's what you're talking about. The reality is decorators are very different. The way that decorators are different is that you can actually wrap pretty much any instance in a decorator. The decorator doesn't necessarily depend on a particular class. Let's say you have a class A and you have a class B and then you have a decorator named C. Well, you can decorate both instances of A and instances of B with that decorator C. In fact, you can make your classes decorators and then chain them in any order that you would like. For example, if class A, B and C are all decorators, then you can decorate A with B and then decorate that with C. Of course, this is one of those topics that is a little bit hard to talk about on a podcast efficiently, but I want to share with you an analogy that I heard about decorators one time that helps me understand when and how they were useful. Imagine hypothetically that you are writing some software that creates menus for a hamburger restaurant. Now, imagine that the hamburger can have many different types of toppings, many different types of sides, and perhaps many types of drinks. Now, there's a lot of ways you can tackle this. One way would be to have attributes on the plate that would allow you to add multiple sides. Maybe you have sides as an array and perhaps you have the main dish as another attribute. But imagine now that that main dish needs to have toppings added to it. Like I said previously, for example, cheese and tomatoes and lettuce that hamburger now has cheese, tomatoes and lettuce. Well, now that has to be an array as well. Another way that you could approach this is to create a single class for every possible iteration that all inherit from some sort of base level hamburger plate. So you'd have something like plain hamburger as your primary base level class, no sides and no drinks that go along with that. And then you could inherit cheeseburger. And then from cheeseburger, maybe inherit cheeseburger with fries. And this seems reasonable to you until you decide to have multiple different sides as well. Then you have to start creating new classes for each side and you have to have each of those iterations with and without cheese and with and without tomatoes. Of course, for each variable item that you add, the number of classes that you have to have increases exponentially. And the decorator pattern is perfect for this example. It allows you to arbitrarily add different aspects to your plate. For example, you could have a lettuce decorator and a tomato decorator and maybe a fries as a side decorator and a coke decorator. All of these different decorators would sit as their own ingredients for a given plate and you simply add them on and decorate the plate with each of those ingredients. What you end up with is an instance of your base class that has been decorated with multiple objects, each of these describing a slight variation on that base level plate. I hope today's episode has given you some ideas about when you would go about using the decorator pattern versus the facade pattern and how they are different from each other. Thank you again to today's sponsor, DigitalOcean, check it out, DigitalOcean.com, a very fast SSD server and 55 seconds for $5 a month. You get $10 off with the coupon Developer Tea. Thank you for listening to today's episode. If you want to make sure that you don't miss out on future episodes of Developer Tea, you can always subscribe to the podcast and just about any podcast listening application that you use, particularly iTunes. As always, Developer Tea is brought to you today by spec.fm. Go and check out the other podcasts and resources that are always growing at spec.fm. Thank you for listening to today's episode and until next time, enjoy your tea.