Leveraging Design Patterns

Design patterns (DP) are helpful, especially once you start to see them in action and recognize them as such. DP convey standard ways of solving problems encountered by software architects. Once you have build and maintained applications for awhile, you see "cowboy coding" for what it is, lazy or perhaps uninformed approaches to solving problems. The MVC pattern is one of the first that you need to grok or get your head around. This mature pattern promotes solid tiered or layered programming where the key parts of your application are separated (data, bus logic and presentation). Design patters are not a solution to a problem but a way of viewing the problem and seeing its solution.

Do not be discouraged if you do not immediately see the payoff or even the need for a pattern at first, these are not always obvious and take time to internalize before you see them or the payoff in following or implementing one.

ColdFusion has evolved into a OO language that lends itself to design patterns. If you use cfinclude in your programming then you are already following a design pattern of reuse. If you see the benefit of putting code into a file and sharing that file in multiple places, rather than retrying the code in each place, you are on your way to being a better programmer or architect.

Singleton Pattern - Some objects only need to be created once during the life of the user session, objects like services or application setup services are called singletons. They do not have to keep any state. For example, if i am tracking site visits in a log file or DB, i would only want a single record of that visit, not each time the user does something during their visit. When a user logs into a system, their information is retrieved and stored only once during their visit.

Factory pattern - Just give me what i need and its dependencies. I build objects and their dependency objects. If i am creating a DAO or Gateway object, then i will create also its service object.

Facade pattern - a front end that encapsulates dependencies with object dependencies. When creating a API or interface to my objects, i don't need to share all the details about how things work, just how to use it. The facade is a happy public face that hides the real complexity of the object.

Data Access pattern - data access objects like DAOs only know about the persistence layer or database. The data access pattern often includes helper methods to simplify the way the service layer see it and calls it.