Pattern Hatching: Ch. 5 GoF : Façade Pattern

1. Pattern Hatching: Ch. 5GoF: Façade Pattern Josh Mason 6/29/2009

2. 7 Habits of Effective Pattern Writers • Taking Time to Reflect • Adhering to a Structure • Being Concrete Early and Often • Keeping Patterns Distinct and Complementary • Presenting Effectively • Iterating Tirelessly • Collecting and Incorporating Feedback

3. 1. Taking Time to Reflect • Reflect on prior experience • Record experience incrementally • Write down problem • Write down approach to problem • Write down failed approaches • Look at other systems and their solutions • Not enough time? Read about them. • Look at what patterns were used • Analyze if a pattern is a variation of another well known pattern • Found a new pattern? • Ensure there are two example of problem • Go to step 2

4. 2. Adhering to a Structure • Write-up should include at least • Name • Problem description • Context and justification of solution • Solution to problem • Pick a structure and stick to it

5. 3. Being Concrete Early and Often • Concrete ideas easier to understand then abstract ones • Consider having a motivation section first • Have a concrete example • Refer to example when discussing solution abstractly • Tell the “whole truth” • Include shortcomings • Pitfalls • etc.

6. 4. Keeping Patterns Distinct and Complementary • Ask, “How is pattern X different form Y?” • Make it clear to reader the distinction • Let intent of pattern be your guide • Don’t let class structure guide you • Only so many class hierarchies • Make sure patterns are orthogonal • Merge related patterns • Compare your pattern with other patterns

7. 5. Presenting Effectively • Quality determined by effective presentation • Use the best software tools • Be good at typesetting • Make liberal use of drawings to illustrate key ideas • Have a good writing style • Down to earth • Don’t be pretentious • Write conversationally • Read a book on writing style

8. 6. Iterating Tirelessly • Realize, you’ll likely never get the pattern completely right • Expect to rewrite your pattern many times • Don’t try to perfect a single pattern before attempting another • Patterns don’t exist in isolation • A change to one could impact another

9. 7. Collecting and Incorporating Feedback • “No pattern can be trusted until it is used by someone other than its author” • Patterns are obvious to writer, not necessarily readers • Get feedback from colleagues • Look for opportunities to use your pattern • Disseminate your pattern as wide as possible • Be prepared for feedback • Take the good with the bad • Give reviewers the benefit of the doubt

10. Façade Pattern • Makes a subsystem easier to use • Defines a higher-level interface to make life easier

11. Façade - Motivation • Reduce complexity • Minimize dependencies • Shield subsystem classes from client

12. Façade – Applicability • Use Façade Pattern when • Want to provide a simple interface to a complex subsystem • Want to decouple a subsystem from the clients • Want to layer your subsystems • Use façade to define entry point at each subsystem level • Mutually dependent subsystem communicate through their facades

13. Façade – Participants • Façade • Everyone else • Subsystem classes

14. Façade – Consequences • Benefits • Shields client from subsystem components • Promotes weak coupling between subsystem and clients • Can easily swap one subsystem with another • Reduces compilation dependencies • Client classes can still use subsystem classes directly if needed • Disadvantages • May lose functionality in subsystem

15. Façade – Related Patterns • Abstract Factory • Provide an interface for creating subsystem objects in a subsystem-independent way • Mediator • Colleagues communicate through mediator • Mediator centralizes communication and sometimes functionality • Façade simply abstracts an interface for an entire subsystem • Singleton • Typically only one façade is required