PATTERN HATCHING: CH. 5GOF: FAÇADE PATTERNJosh Mason

6/29/2009

7 HABITS OF EFFECTIVE PATTERN WRITERS

1. Taking Time to Reflect2. Adhering to a Structure3. Being Concrete Early and Often4. Keeping Patterns Distinct and

Complementary5. Presenting Effectively6. Iterating Tirelessly7. Collecting and Incorporating Feedback

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

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

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.

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

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

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

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

FAÇADE PATTERN

Makes a subsystem easier to use Defines a higher-level interface to make life

easier

FAÇADE - MOTIVATION

Reduce complexity Minimize dependencies Shield subsystem classes from client

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

FAÇADE – PARTICIPANTS

Façade Everyone else

Subsystem classes

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

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