Topics

ColdFusion and Design Patterns

Sunday, 5th August 2007 by Simon. Average Reading Time: about 2 minutes.

As we all are well aware, ColdFusion, historically, has been a programming language that has allowed for ‘spaghetti code‘ and poor application design practices. However, with the emergence and maturity of major frameworks, such as Fusebox, Model Glue, Mach-II and ColdSpring, there has been a shift of emphasis from poor coding, to re-usable and extensible development practices. With the maturity of the language comes the search for standard ways of achieving certain tasks. This is where design patterns lend themselves.

In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Not all software patterns are design patterns. Design patterns deal specifically with problems at the level of software design. Other kinds of patterns, such as architectural patterns, for example Model-View-Controller (MVC), Implicit Invocation and Dependency Injection, describe problems and solutions that have alternative scopes. However, for ease, I generally consider software and architecture patterns under the design pattern scope.

Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

Design patterns can be classified in terms of the underlying problem they solve. Examples of problem-based pattern classifications include Creational, Structural and Behavioural Patterns. Creational patterns, such as Singleton, deal with the creation of objects, Structural patterns, such as Facade, deal with the relationships between objects and Behavioural patterns, such as Observer, deal with the communication between objects.

The practical application of design patterns to ColdFusion applications is a new phenomenon and one which requires careful consideration. There is no sense in using a design pattern for the sake of using it, it must first solve the problem you have encountered. Common design patterns that I have used in my day-to-day development have included Singleton, Composite, Model-View-Controller (MVC), Data Access Object (DAO), Gateway, Bean and the Facade Pattern. These I will discuss in later articles.

Share this article with your network

Other articles I recommend

Object-Relational Mapping (or ORM), is a programming technique that links databases to object-oriented language concepts, creating (in effect) a “virtual object database”. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to code their own object-relational mapping for their systems.

The Law of Demeter (LoD), or Principle of Least Knowledge, is a design guideline for developing software applications, particularly object-oriented programs. The guideline can be succinctly summarised as “Only talk to your immediate friends.” The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else, including its sub-components.

With the introduction of ColdFusion MX, the ColdFusion community is maturing. Most CF developers have moved beyond spaghetti code and the mixing of business logic with presentation code. But it can be difficult and wasteful to “re-invent the wheel” for every application you write. Frameworks can help promote good development practices, standards, and a sound foundation for creating an application.

George Bridgeman

Another good design patterns book: Patterns of Enterprise Application Architecture. By Martin Fowler. ISBN 0-321-12742-0. Still working my way through it so can’t give a decent review but enjoying it so far.

Michael White

I am trying to adapt my coding from pseudo-OO to real OO and looking for a good explaination, example of how beans and dao and gateways all interact, and about facade patterns and how they can be used to allow you to better separate your user interface from all the back end logic.

I like the idea, which is basically getting people to think about what they’re doing so that what they produce is balanced between maintainability, performance, and cost.

In fairness, though, there’s a couple things I’d like to disagree with, too. 😉 First, ColdFusion still, to this very day, allows for poorly-written software, as does pretty much every programming language from the 8,000 that exist. You can be thoughtful or not when developing software and, as a result, write well or write poorly. No language prevents people from doing a poor job, just as no tool prevents a carpenter from doing a poor job.

Second, the shift may be growing larger, but people have been producing well-written and even pattern-based software for years with CF. I’m only noting this to be fair to them. It’s not like everything put out by the CF community in the first 7 of the last 10 years was poorly done. A lot of it is encapsulated, reusable code that does its job well.

And that brings me to my final point… things like Fusebox, the ColdFusion Extension API for C++ (CFX), and custom tags are overlooked (in an historical context, anyway) as tools that allowed developers to build software based on either design patterns or architectural patterns. Granted they have become more mature lately and many of us have helped spread the word about MVC and OO and so on, but even way back in the summer of 99, we had some of this stuff available to us.

All in all a good post, and I want to be clear that I’m just trying to contribute to a larger and very important conversation here. 😉

@George. I will try and address the use of beans, DAOs, Gateways and Facade in upcoming posts.

@Jared. I certainly agree with your statement regarding poorly written code. An inherent weekness in any code is the developer used to create the application. This is and area ColdFusion junkies need to address as on so may occassions I get people, largely ignorant of ColdFusion, belittling it due to poor specifications and architecture. Although there is a section of developers out there using good practice, there is also a large, if not dominant, number who do not.