Design Patters (official)

Gleaning from Sean Corfield presentation.

Pattern: Composite View
A composite view is a view that includes other views

Patterns have four parts:
• Name - the common vocabulary
• Problem - “forces” that determine when the
pattern is applicable
• Solution - a template for solving the problem
• Consequences - “pros and cons”

APPLICATION / onApplicationStart()
is a singleton pattern (once entity accessible from one place)

problem (trade off) is breaks encapsulation when object x needs to reference some application scoped variable. A solution is to use something like CS, that injects object X at instantion with the application scoped variable (which is no longer application scoped at this point).

A common problem

I have components that make up my user
security logic but I don't want to expose them to
other code, in case I want to change how its implemented.

Create a new component that has a simple
API that calls the security components.

Think in terms of trade / offs (pros and cons) a pattern has both! For example

Application code no longer needs to know about the
internals of your security system (+)

Application code can still get at the “low-level”
components if it needs to (+/-)

Some redundancy of methods between the API and
the underlying components (-)

Pattern - Facade ( common very helpful)
Problem - as a subsystem grows, it becomes more
complex with a large number of smaller objects

Solution - introduce a single component that
provides a simple API to the set of components
within the subsystem

Consequences - shields clients from the inside of the
subsystem, reducing complexity and coupling; does
not prevent access to subsystem if needed

Often only one instance of a facade is needed(singleton)

Pattern Name: Front Controller - like fusebox or machii or global index, each of these frameworks is a front controller pattern.

Problem - need to apply consistent logic across all
requests in an application (security, layout etc)

Solution - route all requests through a single file that
decides how to process the request

Singleton and Facade refer to objects, most design patterns are focused on OO design

Consequences - centralized control, easy to change
how requests are handled in a consistent manner,
moves logic out of individual pages into controller
(which can become complex)

cfinterface specifies the methods a component provides (API) but not how they behave. cfcomponent *implements* the interface to specify the behavior. An interface can have many implementations. But duck typing is more powerful and appropriate for
ColdFusion - onMissingMethod() lets you implement any methods dynamically.

-- Sean Corfield

However, this is starting at the wrong end. When you
learn patterns by focusing on the solutions they
present, it makes it hard to determine the situations in
which a pattern applies. This only tells us what to do
but not when to use it or why to do it.”
-- Alan Shalloway

Creational patterns
Abstract Factory, Builder, Factory Method,
Prototype, Singleton
Structural patterns
Adapter, Bridge, Composite, Decorator, Facade,
Flyweight, Proxy
Behavioral patterns
Chain of Responsibility, Command, Interpreter,
Iterator, Mediator, Memento, Observer, State,
Strategy, Template Method, Visitor

Frameworks are designed to solve common problems
• Application frameworks usually implement several patterns
• Front Controller - everything goes through index.cfm
• Model-View-Controller - segregation of the presentation and
business tiers

ColdSpring
• Chain of Responsibility - each “aspect” calls methods on the next
“aspect” until the underlying business object is reached
• Identity Map - cache of objects accessed by “id” (bean name)
• Proxy - same API as your business objects but intercepts method
calls to execute before, after or around “advice”