Software Design Patterns

Software Design is easy enough to understand but what the heck is a pattern when thinking about software design. Is it repetition, a template, a basic design paradigm, just what the heck is it. It turns out that a software design pattern is all of the above and more.

Christopher Alexander has been credited with being the first to use the term “design patterns”. He first used the term in 1964 to describe architectural patterns, a solution to a commonly occurring architectural problem. He saw the same problems appearing over and over in different architectural projects, i.e., how many windows does a room need, and the same solutions being used for these problems, i.e., the number of windows needed depends on the function of the room (context), the desires of the customer, and the buildings products available. Alexander further stated that “a pattern described a problem that occurs over and over again and the core solution to that problem is such a way that you can use the solution a million times over without doing it the same way twice”.

As Christopher Alexander continued his examination of design patterns he coined the term “pattern language” which is simply a collection of design patterns that relate to a particular field. More precisely, pattern language is a structured method of describing good design practices within a field of expertise. This is what is referred to in today’s software environment as “best practices”. Emulating good design decisions while steering away from bad design decisions (anti-patterns).
According to Alexander every pattern we define must be formulated in the form of a rule, which establishes a relationship between a context, a system of forces that arises in that context and a configuration that allows these forces to resolve themselves in that context.

Pattern language as applied to software was further defined by what is known as the “Gang of Four”, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. They wrote a book, Design Patterns: Elements of Reusable Object-Oriented Software. In this book, published in the mid 1990’s the Gang of Four used the premises put forth by Christopher Alexander to describe reusable solutions to commonly recurring problems in software design. Reusing design patterns helps prevent issues that cause major problems (using best practices or learning from other’s mistakes).

This all sounds interesting but how does this apply to software design. I think it all boils down to this, you don’t have to reinvent the wheel! In today’s world, software design patterns are most often applied at the architectural level and one of the most often used patterns is the Model-View-Controller (MVC) pattern. However, there are many more design patterns relevant to software design. I personally like the three-tier architecture, a client-server architecture with distinct processes for the presentation, the application processing, and the data management.

The three-tier architecture has three distinct layers or tiers that are independent of each other but are connected by defined interfaces. This design allows for the tiers to be upgraded or replaced independently of the others as the need may arise, such as a change in requirements or technology.

The presentation tier is at the top. This tier displays (presents) the information to the user. Typically, this involves HTML pages and JSPs. This is what the user sees and interacts with. The application tier (Logic tier in the diagram below) controls the flow of the software application. This tier is sometimes referred to as the business rules tier because it is here that the business rules are implemented. The application tier controls the flow of data between the presentation tier and the data tier. The third tier is the data management tier. This is where the databases are found, where the data is stored and retrieved.

A diagram of the Three Tier Design Pattern.

There is a definite difference between the MCV design pattern and the Three Tier Architecture design pattern. In the Three Tier architecture design pattern the client tier does not communicate directly with the data tier, all communication must pass through the application tier. In contrast, in the Model View Controller design pattern, each object communicates with the other objects, which means less independence and modularity.