Design Patterns Explained

Design patterns are high-level abstract solution templates. Think of them as blueprints for solutions rather than the solutions themselves. You won’t find a framework that you can simply apply to your application; instead, you will typically arrive at design patterns through refactoring your code and generalizing your problem.

Design patterns aren’t just applicable to software development; design patterns can be found in all areas of life from engineering to architecture. In fact, it was the architect Christopher Alexander who introduced the idea of patterns in 1970 to build a common vocabulary for design discussion. He wrote:

"The elements of this language are entities called patterns. Each pattern describes a
problem that occurs over and over again in our environment and then describes the
core of the solution to that problem in such a way that you can use this solution a
million times over without ever doing it the same way twice."

Alexander’s comments are just as applicable to software design as they are to buildings and town planning.

Origins

 The origins of the design patterns that are prevalent in software architecture today were born from the experiences and knowledge of programmers over many years of using object-oriented programming languages. A set of the most common patterns were catalogued in a book entitled "Design Patterns: Elements of Reusable Object-Oriented Software", more affectionately known as the "Design Patterns Bible". This book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, better known as the Gang of Four.

They collected 23 design patterns and organized them into 3 groups:

• Creational Patterns: These deal with object construction and referencing.
• Structural Patterns: These deal with the relationships between objects and how they interact with each other to form larger complex objects.
• Behavioral Patterns: These deal with the communication between objects, especially in terms of responsibility and algorithms.

Necessity

Patterns are essential to software design and development. They enable the expression of intent through a shared vocabulary when problem solving at the design stage as well as within the source code. Patterns promote the use of good object-oriented software design, as they are built around solid object-oriented design principles.

Patterns are an effective way to describe solutions to complex problems. With solid knowledge of design patterns, you can communicate quickly and easily with other members of a team without having to be concerned with the low-level implementation details.

Patterns are language agnostic; therefore, they are transferable over other object-oriented languages. The knowledge you gain through learning patterns will serve you in any first-class object-oriented language you decide to program in.

Usefulness

The useful and ultimate value of design patterns lies in the fact that they are tried and tested solutions, which gives confidence in their effectiveness. If you are an experienced developer and have been programming in .NET or another object-oriented language for a number of years, you might find that you are already using some of the design patterns mentioned in the Gang of Four book. However, by being able to identify the patterns you are using, you can communicate far more effectively with other developers who, with an understanding of the patterns, will understand the structure of your solution.

Design patterns are all about the reuse of solutions. All problems are not equal, of course, but if you can break down a problem and find the similarities with problems that have been solved before, you can then apply those solutions. After decades of object-oriented programming, most of the problems you’ll encounter will have been solved countless times before, and there will be a pattern available to assist in your solution implementation. Even if you believe your problem to be unique, by breaking it down to its root elements, you should be able to generalize it enough to find an appropriate solution.

The name of the design pattern is useful because it reflects its behavior and purpose and provides a common vocabulary in solution brainstorming. It is far easier to talk in terms of a pattern name than in detail about how an implementation of it would work.

What They Are Not

Design patterns are no silver bullet. You have to fully understand your problem, generalize it, and then apply a pattern applicable to it. However, not all problems require a design pattern. It’s true that design patterns can help make complex problems simple, but they can also make simple problems complex.

After reading a patterns book, many developers fall into the trap of trying to apply patterns to everything they do, thus achieving quite the opposite of what patterns are all about — making things simple. The better way to apply patterns, as stated before, is by identifying the fundamental problem you are trying to solve and looking for a solution that fits it. This book will help with the identification of when and how to use patterns and goes on to cover the implementation from an ASP.NET point of view.

You don’t always have to use design patterns. If you have arrived at a solution to a problem that is simple but not simplistic and is clear and maintainable, don’t beat yourself up if it doesn’t fit into one of the 23 Gang of Four design patterns. Otherwise, you will overcomplicate your design.

This talk of patterns might seem rather vague at the moment, but as you progress through the book, you will learn about the types of problems each pattern was designed to solve and work through implementations of these patterns in ASP.NET. With this knowledge, you can then apply the patterns to your applications.