In today's episode I review decorator and facade patterns. Special thanks to today's sponsor: DigitalOcean. Go to https://digitalocean.com to get started on cloud hosting. Use the promo code "DEVELOPER TEA" at the checkout after you create your account to get a $10 credit!
In today's episode I review decorator and facade patterns. I'll go over strengths, weaknesses, similarities and difference between decorator and facade patterns and give tips on determining when to use one or the other.
Today's Sponsor is: Digital Ocean
Go to https://digitalocean.com to get started on cloud hosting. Use the promo code "DEVELOPER TEA" at the checkout after you create your account to get a $10 credit!
If you enjoyed this episode and want to know when the latest episode has gone live, subscribe to the podcast, and be sure to check out other podcasts and content on the network that makes this podcast possible: Spec.fm.
Until next time,
Enjoy your tea
Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today we're going to be talking about the difference between the facade and the decorator patterns. I want to say a quick thank you to today's sponsor, DigitalOcean. In just 55 seconds on DigitalOcean, you can deploy an SSD cloud server and their plans start at $5 a month. Later on, we'll talk about how you can save a little bit of money because you are a Developer Tea listener. 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 decorator 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 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 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 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. So the reality is, we call this entire process 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. 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, 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, jQuery 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. And 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. So the facade pattern serves to encapsulate functionality that goes together cognitively. So the withdrawal being the meta method and each of those individual steps being the underlying methods that the facade is encapsulating. And 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. So your class in many ways is actually just a facade pattern at play without you even knowing it. Now, 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 in summation. I'm going to talk to you about decorators next, but first I want to talk to you about today's sponsor, DigitalOcean. If you've ever had a hassle setting up a server, then you know how far you can go with your software. It's frustrating. It can be. DigitalOcean is basically the opposite of that. Their 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. That's all it takes to set up a solid state cloud server with DigitalOcean. Check it out. DigitalOcean.com. They've been kind enough to provide Developer T listeners with a code to get $10 off. That code is, very simply, Developer T, 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. DigitalOcean.com. And that would be a great place to practice some of these patterns that you're learning here on Developer T. We've already covered the facade pattern today. Now let's talk about decorators. What exactly is a decorator? Well, 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. Now, those of you who are listening very carefully and have some experience with object-oriented 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. But the reality is decorators are very different. And the way that decorators are different is that you can actually wrap pretty much any instance in a decorator. So 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. And 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 helped 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. 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 start creating new classes for each side. 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 base level plate. 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 servers and 55 seconds for $5 a month. You get $10 off with the coupon developer T. 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 T, you can always subscribe to the podcast and just about any podcast listening application that you use. Uh, particularly iTunes. As always, developer T 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.