Practical Design Patterns
From BriansWiki
Contents |
[edit] Presenter
[edit] Joe Rinehart
[edit] Agenda
- Why Design patterns?
- Dispelling myths
- Examples of a design pattern
- Everyday patterns
[edit] Why Design Patterns
[edit] What they are not
They are not recipes, yes they are called "catalogs" but they are a list of observations like a naturalists records of observations.
They are not always outside things to be learned, but things to be discovered with in your applications.
They are not overly specific, they are general arraignments of objects and classes that solve problems.
They don’t tell you what to name classes, parameters they take and things they return
[edit] What they are
If you have a cfc called template that all apps call to add a header and a footer. But if the app changes or has to be dynamic based on the users role or the server name, so he writes a component to load the correct template based on a passed in variable. The Application CFC then just needs to check for the template loader and creates it passing it the server name
But then requirements change and he needs to support multiple languages, so he changes the application to check for a language cookie and then loads the localized version of the template loader based on the result.
Then there is a new Requirement to support multiple database backends, he realizes that this is not unlike the Template loader, so he creates a Dao Loader that checks for a parameter passed in at run time.
What you are doing here, is creating a pattern of responses to design problems. A name for this could be a simple factory pattern for the first pattern. The second is an abstract factory pattern and the last is a singleton factory pattern. All design patterns must have three parts
[edit] Forces:
The constraints, Challenges or sets of intents that must be met
[edit] Solution:
The arraignment of objects that meet the design forces
[edit] Consequences:
The implications, (good and bad) of the solution – the results.
Design patterns are generalized solutions to challenges
There may be multiple responses
[edit] Observer Pattern
This is data binding at work. Changes by one object the subject, can be acted on by observers of these objects. Observers are also automatically notified of changes to the subject.
Observers are central to Model Glue and Mach II: each relies on listeners (observers) that subscribe to messages broadcast by the framework (the subject).
[edit] Factory
[edit] Forces:
A concrete implementation of a instantiated needs to be determined at runtime
[edit] Solution:
Create a class (the factory) responsible for concrete instantiations of a given interface based on context, such as parameters.
[edit] Consequences:
Example is a DAO factory that can creates a consistent API
[edit] Facade (service) Pattern
[edit] Forces:
Simplify interaction with a complex API
[edit] Solution:
Create a single class representing a single entry point to a set of functionality
[edit] Consequences:
Interaction is simplified, flexibility is increased and the code utilizing the façade is only bound to the service interface.
Flicker is a great example of working with a façade interface, the complexity is hidden and all we need is to pass the tag we want to search for.
