Vox

Leitura de 14 min

Decorator vs. Facade Patterns & Knowing When To Use Them

Summary

This episode of Developer Tea focuses on clarifying two commonly confused design patterns: the facade pattern and the decorator pattern. Host Jonathan Cottrell breaks down each pattern’s purpose, similarities, and key differences to help developers understand when to apply each one in their code.

The facade pattern is introduced as a composition tool that encapsulates multiple related steps into a single, semantically meaningful method. Using the example of a bank withdrawal process, Cottrell explains how a facade abstracts individual verification, fund checking, and update steps into a unified “withdraw” method. He emphasizes that facades are not meant to unify disparate interfaces (like jQuery does for AJAX) but rather to group functionality that moves together cognitively, often appearing naturally in many classes without developers realizing it.

In contrast, the decorator pattern extends existing functionality by wrapping objects with additional behavior. Cottrell distinguishes decorators from class inheritance by noting that decorators can wrap any instance, not just subclasses of a specific type, and can be chained in arbitrary orders. He provides a hamburger restaurant menu example to illustrate how decorators elegantly handle combinatorial complexity—where adding toppings, sides, and drinks would otherwise require an exponential number of classes if using inheritance alone.

The episode concludes by summarizing the core distinction: facades compose existing functionality into higher-level operations, while decorators add new functionality to existing objects. Cottrell encourages listeners to consider these patterns when designing systems that require either simplified interfaces for complex processes or flexible extension of object capabilities.

Recommendations

Tools

  • DigitalOcean — A cloud hosting service built for developers, mentioned as the episode’s sponsor. It offers SSD cloud servers that can be deployed in 55 seconds, starting at $5/month, with a special offer for Developer Tea listeners.

Topic Timeline

  • 00:00:00 — Introduction to facade and decorator patterns — Jonathan Cottrell introduces the episode’s topic: comparing the facade and decorator design patterns. He explains that while these patterns share similarities, they serve different purposes, and understanding when to use each is crucial for effective software design. The episode will explore their differences, similarities, and practical applications.
  • 00:00:50 — Explaining the facade pattern with a bank example — Cottrell begins with the facade pattern, describing it as fundamental to composition in design. He uses a bank withdrawal process as an example: verifying authorization, checking funds, processing the withdrawal, and updating records. The facade pattern abstracts these individual steps into a single “withdraw” method, providing a semantic interface without violating the single responsibility principle—it just operates at a different scope.
  • 00:02:28 — Clarifying what a facade is not (jQuery example) — Cottrell clarifies that the facade pattern is not intended to create unified interfaces across different implementations, like jQuery does for AJAX across browsers. That role belongs to the adapter pattern. Instead, a facade encapsulates functionality that moves together cognitively, grouping steps that naturally belong together. He notes that many classes we create inadvertently act as facades by encapsulating standard methods.
  • 00:04:39 — Transition to decorator pattern after sponsor message — After a sponsor message for DigitalOcean, Cottrell transitions to discussing the decorator pattern. He explains that decorators are similar to facades in some ways but fundamentally different: instead of encapsulating existing functionality, decorators extend or add to existing functionality. He immediately addresses a common misconception by distinguishing decorators from class inheritance.
  • 00:06:19 — How decorators differ from inheritance — Cottrell explains that decorators differ from class inheritance because they can wrap any instance, not just subclasses of a specific class. A single decorator can be applied to instances of different classes, and decorators can be chained in any order. This flexibility makes them powerful for adding behavior dynamically without creating rigid class hierarchies.
  • 00:07:09 — Hamburger restaurant analogy for decorators — To illustrate decorators, Cottrell presents an analogy: software for a hamburger restaurant menu. He describes the problem of modeling combinations of toppings, sides, and drinks. Using inheritance would require an exponential number of classes (e.g., plain hamburger, cheeseburger, cheeseburger with fries). The decorator pattern solves this by allowing ingredients like lettuce, tomato, fries, or coke to be added as separate decorators that wrap a base hamburger plate object.
  • 00:09:39 — Conclusion and pattern comparison — Cottrell concludes by summarizing the key takeaways: the facade pattern is for composing multiple steps into a single, higher-level operation, while the decorator pattern is for extending functionality by wrapping objects with additional behavior. He hopes the episode has clarified when to use each pattern and thanks the sponsor, DigitalOcean, once more before signing off.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2015-08-28T07:00:00Z
  • Duration: 00:10:33

References

Podcast Info

Transcript

[00:00:00] Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today we’re going to be

[00:00:06] talking about the difference between the facade and the decorator patterns. I want to say a quick

[00:00:12] thank you to today’s sponsor DigitalOcean. In just 55 seconds on DigitalOcean you can deploy

[00:00:19] an SSD cloud server and their plans start at five dollars a month. Later on we’ll talk about how you

[00:00:24] can save a little bit of money because you are a Developer Tea listener. But for now let’s go

[00:00:28] ahead and jump directly into today’s topic. We’re going to be talking about the facade pattern and

[00:00:34] the decorator pattern, how they are different, how they are similar, and when you would use each of

[00:00:39] these patterns. They’re very similar to each other in some ways but there are a few extra things that

[00:00:46] you need to know about when each pattern is applicable. So we’re going to start with the

[00:00:50] facade pattern because the facade pattern in my opinion is kind of the fundamental idea of

[00:00:57] composition and design. So we’re going to start with the facade pattern because the facade pattern

[00:00:58] allows you to do is take single step methods or single responsibility methods and compose them

[00:01:09] together into larger meta responsibilities. A perfect example of this is withdrawing from a

[00:01:16] bank account. So first you have to verify that whoever is trying to withdraw is able to and

[00:01:23] authorized to withdraw from that bank account. So that might be one method. Then the next

[00:01:28] method might be actually checking to make sure that the amount that they want to withdraw is

[00:01:33] available in their existing funds. And then the next method may be dealing with it if it isn’t

[00:01:40] or actually pulling the money if it actually is available. And then finally updating anything else

[00:01:46] that needs to be updated at the end of that withdrawal. So the reality is we call this

[00:01:52] entire process withdrawal but we know that each of these individual steps has to happen every

[00:01:58] time withdrawal occurs. So what the facade pattern allows you to do is abstract away each of those

[00:02:05] individual steps each of those individual methods into a method that we can call withdraw. And what

[00:02:12] this does is it allows us to not have to remember each and every individual step and it gives us

[00:02:18] a more semantic way of describing this larger task. And the responsibility principle is not

[00:02:24] violated. It is just a different scope of responsibility.

[00:02:28] Now it’s important to note that the facade pattern is not intended to create a unified

[00:02:34] interface. For example jQuery was built as a library to unify the different ways of doing

[00:02:41] AJAX. That is not what the facade pattern is intended to do. The facade pattern instead

[00:02:47] is intended to hold multiple steps that are visible. It’s not intended to abstract away

[00:02:55] all of the discrepancies between different

[00:02:58] underlying technologies. Now you may be wondering why you wouldn’t call that a facade. Why you

[00:03:05] wouldn’t call fixing the inconsistencies between browsers for example. Why you wouldn’t call that

[00:03:10] a facade pattern. And the reason for that is because there are other patterns to describe

[00:03:15] that process. Namely there is the adapter pattern for example that kind of unifies the interfaces

[00:03:21] between different implementations. So the facade pattern serves to encapsulate functionality that

[00:03:28] moves together cognitively. So the withdraw being the meta method and each of those individual

[00:03:35] steps being the underlying methods that the facade is encapsulating. And in reality we

[00:03:41] see this at play all the time. In fact I would argue that most of the classes that we create

[00:03:47] are actually doing this process. It just so happens that a lot of their encapsulated methods

[00:03:54] are part of the standard class. For example manipulations of strings,

[00:03:58] are inside of your methods. But those methods are actually implemented in another location.

[00:04:05] So your class in many ways is actually just a facade pattern at play without you even knowing

[00:04:12] it. Now there’s a little bit of a disclaimer that I have to give here. There’s probably a

[00:04:16] better formalized definition of when something is or is not considered a facade. But for the

[00:04:23] sake of practical use and for the sake of actually writing code today.

[00:04:28] And utilizing the facade pattern. What you’ve heard in this podcast is the facade pattern kind

[00:04:34] of in summation. I’m going to talk to you about decorators next. But first I want to talk to you

[00:04:39] about today’s sponsor DigitalOcean. If you’ve ever had a hassle setting up a server then you know

[00:04:45] how frustrating it can be. DigitalOcean is basically the opposite of that. Their simple

[00:04:50] cloud hosting that’s built specifically for developers actually went through the process

[00:04:54] of setting up their five dollar droplet. That droplet has five hundred dollars worth of data.

[00:04:58] One hundred and twelve megabytes of RAM. A twenty gigabyte solid state drive and a CPU with a full

[00:05:04] terabyte of transfer. All for five dollars a month. I set it up in fifty five seconds. Fifty five

[00:05:11] seconds is all it takes to set up a solid state cloud server with DigitalOcean. Check it out

[00:05:16] DigitalOcean.com. They’ve been kind enough to provide developer T listeners with a code to get

[00:05:22] ten dollars off. That code is very simply developer T. All one word. Of course that code will be in

[00:05:28] the show notes.

[00:05:28] And the link will be in the show notes as well. Check it out DigitalOcean.com. And that would be a

[00:05:34] great place to practice some of these patterns that you’re learning here on developer T. We’ve

[00:05:39] already covered the facade pattern today. Now let’s talk about decorators. What exactly is a

[00:05:45] decorator? Well a decorator is similar to the facade pattern but instead of encapsulating

[00:05:51] existing functionality it takes existing functionality and in a way extends that

[00:05:57] functionality.

[00:05:58] Now those of you who are listening very carefully and have some experience with object oriented

[00:06:02] programming you might think well this sounds a lot like class inheritance. When I have a subclass for

[00:06:08] example I can add new methods to that subclass and I’ve extended the original methods. I inherit from

[00:06:14] the parent class and that’s that’s what you’re talking about. But the reality is decorators are

[00:06:19] very different. And the way that decorators are different is that you can actually wrap pretty

[00:06:24] much any instance in a decorator. So the decorators are very different from the decorators that are

[00:06:28] in a class. So a decorator doesn’t necessarily depend on a particular class. Let’s say you have a

[00:06:33] class A and you have a class B and then you have a decorator named C. Well you can decorate both

[00:06:40] instances of A and instances of B with that decorator C. And in fact you can make your classes

[00:06:47] decorators and then chain them in any order that you would like. For example if class A, B, and C

[00:06:54] are all decorators then you can decorate A, B, and C in any order that you would like. So you can

[00:06:58] A with B and then decorate that with C. Of course this is one of those topics that is a little bit

[00:07:03] hard to talk about on a podcast efficiently. But I want to share with you an analogy that I heard

[00:07:09] about decorators one time that helps me understand when and how they were useful. Imagine hypothetically

[00:07:16] that you are writing some software that creates menus for a hamburger restaurant. Now imagine that

[00:07:24] the hamburger can have many different types of toppings, many different types of toppings, many

[00:07:28] different types of sides, and perhaps many types of drinks. Now there’s a lot of ways you can tackle

[00:07:33] this. One way would be to have attributes on the plate that would allow you to add multiple sides.

[00:07:40] Maybe you have sides as an array and perhaps you have the main dish as another attribute. But

[00:07:47] imagine now that that main dish needs to have toppings added to it. Like I said previously

[00:07:53] for example cheese and tomatoes and lettuce. That hamburger now has toppings added to it.

[00:07:58] Now that has cheese, tomatoes, and lettuce. Well now that has to be an array as well. Another way

[00:08:03] that you could approach this is to create a single class for every possible iteration that all

[00:08:09] inherit from some sort of base level hamburger plate. So you’d have something like plain hamburger

[00:08:16] as your primary base level class. No sides and no drinks that go along with that. And then you

[00:08:23] could inherit cheeseburger. And then from cheeseburger maybe inherit cheeseburger. And then

[00:08:28] from cheeseburger maybe inherit cheeseburger with fries. And this seems reasonable to you

[00:08:31] until you decide to have multiple different sides as well. Then you have to start creating

[00:08:38] new classes for each side. And you have to have each of those iterations with and without cheese

[00:08:47] and with and without tomatoes. Of course for each variable item that you add the number of classes

[00:08:53] that you have to have increases exponentially.

[00:08:56] Now the decorator is going to have to create a new class for each side. So you have to have

[00:08:58] a certain number of classes. And this decorator pattern is perfect for this example. It allows

[00:09:00] you to arbitrarily add different aspects to your plate. For example you could have a lettuce

[00:09:06] decorator and a tomato decorator and maybe a fries as a side decorator and a coke decorator.

[00:09:13] All of these different decorators would sit as their own ingredients for a given plate and you

[00:09:19] simply add them on and decorate the plate with each of those ingredients. What you end up with

[00:09:26] is an instance of your base level hamburger plate. And then you have to have a different

[00:09:28] class that has been decorated with multiple objects, each of these describing a slight

[00:09:33] variation on that base level plate. I hope today’s episode has given you some ideas about when you

[00:09:39] would go about using the decorator pattern versus the facade pattern and how they are different from

[00:09:45] each other. Thank you again to today’s sponsor, DigitalOcean. Check it out, digitalocean.com.

[00:09:51] A very fast SSD servers and 55 seconds for 10 off with the coupon

[00:09:58] developer T. Thank you for listening to today’s episode. If you want to make sure that you don’t

[00:10:03] miss out on future episodes of developer T, you can always subscribe to the podcast and just about

[00:10:09] any podcast listening application that you use, particularly iTunes. As always, developer T is

[00:10:16] brought to you today by spec.fm. Go and check out the other podcasts and resources

[00:10:21] that are always growing at spec.fm. Thank you for listening to today’s episode and until next time,

[00:10:28] enjoy your tea.

Visão de gráfico