68: Design Patterns: Facade.

The facade structural pattern provides a simplified way for you to interact with a more complicated set of interfaces. This is a simple design pattern that you can use whenever you have a complicated class or set of classes that you want to provide a simpler and easier way for other code to use. It really just comes down to making a new class with a new interface that’s designed to solve the majority of use cases. You can still have some or all of the more complicated interfaces available if you want. You can compare this facade design pattern with the adapter design pattern which should help explain both patterns. Both involve creating a new interface. the difference between the two patterns though is in their intention. If you find yourself creating a new interface for another class or set of classes because the new interface is expected and needed by some other code, then you have an adapter. And if you find yourself creating a new interface for another class or set of classes because the new interface is simpler and easier to use, then you have a facade. Listen for more or read the full transcript of the episode below. Transcript The basic description says that this pattern provides a single interface to a more complicated set of interfaces in a subsystem so that other programmers will have an easier time using the subsystem. Have you ever worked in a team and needed to figure out a good way for your team to work with other teams? What did you do? Chances are, your team selected a representative as a point of contact for your team and it was the representative’s job to coordinate requests from other teams and isolate the rest of your team so you all could stay focused. Or have you ever had a question or complaint from a large company and called them? Did you speak directly with the person who created the item or service that you were calling about? Probably not. I’d guess that you instead spoke with a customer support representative who either handled your issue right away or referred you to somebody else. Or for a more technical example, have you ever driven an automatic car? You don’t have to worry about pressing the clutch or when to change gears. You just put the car in drive, take your foot off the brake pedal, and press the gas pedal. These are all examples of the facade pattern. The first example provides a single person who can route questions and comments to the appropriate team member who then reply back through the representative. As far as the other team members are concerned, the requests might just as well be coming from the representative. The second example also uses representatives but at a higher level. These are not just team representatives but company representatives. This pattern can work with various levels. The third example is possible because an automatic transmission provides a simple interface which can be passed on to the driver. There are still gears that need changing but the transmission deals with this part by measuring speed and the effort the driver is placing on the engine. Having a facade in place doesn’t mean that it must always be used. A facade is usually created to solve the majority of issues in the most simple and direct manner possible. There will sometimes be situations that require access to the individual team members, or to the departments directly, or take manual control over when to change gears. You can still expose the more complicated systems if you need to. It all depends on what you’re trying to solve. Wrapping up complicated systems or details behind a simple interface is usually a good idea. And not only because it provides a simpler interface. If you can convince clients to use the facade instead of directly using more low level resources, then you have more ability to change those low-level systems without affecting the clients. The facade pattern also helps you to layer your code. You may have a set of low level classes that of