1. P ATTERN H ATCHING : C H. 5 G O F: F AÇADE P ATTERN Josh Mason 6/29/2009

2. 7 H ABITS OF E FFECTIVE P ATTERN W RITERS 1. Taking Time to Reflect 2. Adhering to a Structure 3. Being Concrete Early and Often 4. Keeping Patterns Distinct and Complementary 5. Presenting Effectively 6. Iterating Tirelessly 7. Collecting and Incorporating Feedback

3. 1. T AKING T IME TO R EFLECT 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. A DHERING TO A S TRUCTURE 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. B EING C ONCRETE E ARLY AND O FTEN 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. K EEPING P ATTERNS D ISTINCT AND C OMPLEMENTARY 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. P RESENTING E FFECTIVELY 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. I TERATING T IRELESSLY 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. C OLLECTING AND I NCORPORATING F EEDBACK “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. F AÇADE P ATTERN Makes a subsystem easier to use Defines a higher-level interface to make life easier

11. F AÇADE - M OTIVATION Reduce complexity Minimize dependencies Shield subsystem classes from client

12. F AÇADE – A PPLICABILITY 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. F AÇADE – P ARTICIPANTS Façade Everyone else Subsystem classes

14. F AÇADE – C ONSEQUENCES 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. F AÇADE – R ELATED P ATTERNS 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