220 likes | 390 Vues
Seven Habits of Effective Pattern Writers Facade Pattern. PH pp. 145-152 GoF pp. 185-193 John Klacsmann. Other Famous Gang of Four’s. Chinese Communist Politicians (1976) British Post-Punk Band (1977-1984). Seven Habits of Effective Pattern Writers. 1. Take Time to Reflect
E N D
Seven Habits of Effective Pattern WritersFacade Pattern PH pp. 145-152 GoF pp. 185-193 John Klacsmann
Other Famous Gang of Four’s • Chinese Communist Politicians (1976) • British Post-Punk Band (1977-1984)
Seven Habits of Effective Pattern Writers • 1. Take Time to Reflect • 2. Adhere to a Structure • 3. Be Concrete Early and Often • 4. Keep Patterns Distinct and Complementary • 5. Present Effectively • 6. Iterate Tirelessly • 7. Collect and Incorporate Feedback
1. Take Time To Reflect • Think about past problems and solutions • Record Your Experiences • Describe the problem • Why is it difficult? • Write down new approaches • Why did it fail? Why did it succeed? • Forms raw material of patterns
1. Take Time To Reflect • Identify Patterns You Already Know • If find something new & unique make sure you have at least two existing examples of a problem & solution
2. Adhere to a Structure • Pattern: “A Structured Exposition of a solution to a problem in context” • Include: • Name • Statement of Problem • Context and Justification of Solution • Solution itself • Settle on structure & keep it consistent
3. Be Concrete Early and Often • People understand better when presented in concrete first then abstract • Use examples and counterexamples • “Tell the whole truth” • Warn reader of potential pitfalls • Extra Cost • Ill-behavior under certain circumstances • Other patterns • Etc.
4. Keep patterns distinct and complementary • Insure patterns are distinct • Might not be obvious • Ask: “How is pattern X different from pattern Y?” • Let intents of patterns be guide to differences, not class structures • Spend time comparing and contrasting your patterns
5. Present Effectively • Typesetting and Writing Style are important • Use drawings liberally to illustrate key points • Make pattern approachable • Use down-to-earth writing style • Write conversationally
6. Iterate Tirelessly • Pattern writing is an ongoing process • Expect to write and rewrite your pattern many times • Don’t perfect before moving on
7. Collect and Incorporate Feedback • “No pattern can be trusted until it is used by someone other than its author” • Make pattern understandable to people who have never had the problem • Discuss with colleagues • Look for opportunities to use • Get comments & be prepared to hear the worst • Give reviewers benefit of doubt • Bend over backwards to make them happy
Seven Habits of Effective Pattern Writers • Follow these steps to make your own patterns better • The better your patterns are, the more impact they’ll have
GoF’s Facade Pattern • Make it simpler • Defines a higher-level interface that makes the subsystem easier to use From: http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/tutorial.html
Motivation • Structuring into subsystems helps reduce complexity • Provides a single, simplified interface to the more general (complex) facilities of a subsytem
Compiler Example • Contains subsystem of classes • Most clients don’t care about details – just want to compile • Low-level only complicates task
Compiler Example • Compiler class acts as Façade • Provides higher level interface that shields clients from lower-level classes • Makes life easier for programmer without hiding the low-level functionality completely • Puts all pieces of compile operation together
When to use Facade • When you want a simple interface to a complex subsystem • Provides simple default view good enough for most clients
When To Use Facade • When there are many dependencies between clients and implementation classes • Decouples subsystem from clients • When you want to layer your subsystems • Simplify dependencies between subsystems by making them communicate only through their facades
Structure • Façade • Delegates client requests to appropriate subsystem objects • Subsystem Classes • Implement subsystem • Handle work assigned by Façade • Have no knowledge of façade (keep no references)
Benefits • Shields client from subsystem • Reduces number of objects the client deals with • Makes subsystem easier to use • Promotes weak coupling between subsystem and its clients • Helps eliminate complex or circular dependencies • Minimizes recompilation time needed for small subsystem change • Applications can still use subsystem classes if needed • Provides both ease of use & generality
How is this different then Mediator? • Mediator abstracts communication between objects, centralizing functionality • Mediator’s colleagues are aware of it and communicate with it instead of with each other • Façade abstracts the interface to a subsystem to make it easier • It doesn’t provide any new functionality and subsystem classes don’t know about it