Adapter and Facade

November 3, 2008 — Posted by Scott Bain

Comparing Two Patterns: Adapter and Façade

(Note: if you are unfamiliar with these patterns, you can read about them at our pattern repository)

One reason people often struggle to understand how to get real value from patterns is that sometimes two or more of them can look, at first glance, extremely similar. When I'm teaching patterns, people will very often point out how similar the Strategy and Bridge patterns are, or the Decorator and Chain of Responsibility, or the Factory Method and Abstract Factory, etc…

Usually this is because people often confuse the example of the pattern that's being presented to them with the pattern itself. Patterns are neither UML diagrams nor code examples; they are a higher concept that captures best practices, domain and implementation forces, and the consequences (both benefits and costs) of certain decisions. Diagrams and code are simply representations of the patterns, and are always more specific and narrow than the patterns themselves are.

This misunderstanding is an opportunity, however, because when we compare two patterns that appear similar and determine how they are actually different, we can sometimes dramatically enrich our understanding of them.

Adapter and Façade are like this. As described in the pattern repository, they have a very similar role to play in development:

New development ----------> Adapter or Façade ----------> some pre-existing, often supplied code

Both represent some kind of intervening entity that alters some pre-existing code, object, or system in such a way that it is more appropriate for use by new development.

There are a lot of ways of explaining the differences between the two, but I just thought of a new way and wanted to see if this makes sense to others. It's an example of teaching by analogy.

Imagine putting yourself in the context of a foreign country where you do not speak the language. There could be many reasons you might find yourself in such a situation, but let's look at two: You are a tourist, or you are intending to live there.

As a tourist, it might be useful to hire the services of a translator who speaks both your language and the language of the country. This guide would help you to navigate the signs and speak to the waiters and generally be able to interact successfully.

Adapters are like this; they serve to translate the unknown or unusable aspects of your situation to what you are accustomed to, and are essentially designed to expect.

If you are planning to live there, on the other hand, you might want to hire the services of an immigration attorney. This is because there are a great many things that will have to be done, and arranged for, in your quest to become a citizen of a new country. You'll probably have to demonstrate, legally, your employability, you'll have to arrange for some training (language, history) for yourself, you may have to file extensive paperwork and attend hearings, etc… This complexity can be fractal; each thing may have many layers and require a great depth of knowledge. However, your goal is much simpler: you want to become a citizen of the country in question.

Façades are like this; they serve to interact in your stead with a number of interfaces and API's, hiding their complexity, storing intermediate results, dealing with specifics that are neither important nor interesting to you, and presenting a clean, clear result.

Again, there are other ways of demonstrating the differences between these patterns. I have, for example, usually focused on the differences between the entity being adapted, and the entity being covered by a façade. This new way of thinking has more to do with the difference in what is wanted/needed by the entity using the adapter or façade.

Is this useful? Comments would be very welcome.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Scott Bain

Scott Bain is an consultant, trainer, and author who specializes in Test-Driven Development, Design Patterns, and Emergent Design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban