AboutWeb has a 3 day class on Design Patterns in CFMX, but Simon will try to boil it down to 40 minutes.

Who's using DP? About 1/5 of the room held up their hand. Room is huge and there may be as many as 200+ people attending.

No application too large or small for DP, no developer too experienced or too new for DP.

Terminology: Architectur, API, Code Reuse, Object (noun:person,place,thing). Object Oriented Programming OOP, Encapsulation, Decouple (code independence), Design Patterns (recurring solutions to common problems), Anti-Patterns (recurring mistakes in SA/DP).

Measuring Success: 4 ways to meausre success... Scalability, Reliability, Extensibility, Timeliness. What matters most to you, to your boss, to your client? Often get different answers. Using OO gives best chance to satisfy all requests. Even CFMX can treated as a very OO language. OOP helps apps scale.

Application Constructs: Many tiers to an app: Clientside presentation tier as UI, Serverside presentation tier as controller, Serverside business logic tier...

Does anyone use MVC? About 1/4 of the hands went up.

Facade pattern? A few hands went up. FP abstracts business logic to larger, less granular controls.

Front Controller: a single central component performs common functions; Receives all requests and performs common functions like logging, passes data to page as request controller which talks with a Model. Page Controller then selects view.

Decorator Pattern: Not much usage among audience. (Joe Rinehart gave a very nice demo of how to use Decorator Pattern in CF yesterday, showing how an object can be passed through a chain where each link in the chain add or removes properties.)

Data Access Objects (DAO): Basic CRUD functionality (Create, Read, Update, Delete) abstracted out to avoid putting SQL everywhere in app.

Business Delegate Pattern: Object factory.

Resource Pool: decrease repetition of object instantiations. All about keeping resources available rather than re-instantiating them, reduces overhead and immproves speed.



Anti-Patterns: Excessive Layering, Leak collections, Overstuffed scopes (choosing the right scope according to lifetime needed), Magic template, Everything is a CFC.

Application Constructs: CFM Files (not protected, parameterized, or encapsulated), Custom Tags (protected, parameterized, semi-encapsulated), CFCs (prot, param, and encap), Event Gateways (prot, param, ecnap), Other external resources (Java: prot, param, encap)

Putting it all together: CFM Files (browsable entry point to app), Custom Tags (encapsulate display tier code and give cfm files easy syntax for calling cfcs), CFCs (encapsulate data and functionality), Event Gateways (access external resources and functionality otherwise inaccessible to CFCs), Other External Resources (feed data to the application). The Flow: Pages only call tags; Tags control flow based on user interaction, bah!!! slide changed :(

Diagram of app flow

Measuring Success (again): reliability - achieved by reuse of pretested objects/tags; Extensibility: Achieved bc reuse of objs and tags, clean seperation of business/presentation logic, use of decoupled components; Timeliness: reuse of pretested objs/tags; Scalability: emphasizing persistant CFCs for functionality and datastorage (crap, slide moved).

Guidelines: Store all data in CFCs (especially if using session); only use variables scope in CFCs; Limit access to CFC functionality (private methods); Never use persistant scopes (application,session) *in* CFCs; write tags to generate any/all display especially recurring displays. Practice, practice, practice. You can get started little by little and even small ways help.