The concept of a pattern is simple to define. A pattern is something that you did in the past, was successful, and can be applied to multiple situations. Patterns capture experiences in software development that have been proven to work again and again, and thus provide a solution to specific problems. They are not invented: they arise from practical experience.

When many programmers are trying to solve similar problems, they arrive again and again at a solution that works best. Such a solution is later distilled into a solution template, something that we programmers then use to approach similar problems in the future. Such solution templates are often called patterns.

Good patterns are problem and language agnostic. In other words, they apply to C++ and Delphi, and to Haskell and Smalltalk. In practice, as it turns out, lots of patterns are at least...

This is not a book about the theory behind patterns; rather, this book focuses on the aspects of their implementation. Before I scare you all off with all this talk about design patterns, their history, modern advances, anti-patterns, and so on, I have decided to present a very simple pattern using an example. A few lines of code should explain why a pattern—based approach to problem solving can be a good thing.

In the code archive for this chapter, you'll find a simple console application called DesignPatternExample. Inside, you'll find an implementation of a sparse array, as shown in the following code fragment:

type
  TSparseRec = record
  IsEmpty: boolean;
  Value : integer;
end;

TSparseArray = TArray<TSparseRec>;

Each array index can either be empty (in which case IsEmpty will be set to True), or it can contain a value (in which case...

The design pattern movement (as it applies to programming) was started by the Gang of Four. By Gang of Four, we don't mean the Chinese Cultural Revolution leaders from the seventies or a post-punk group from Leeds, but four authors of a prominent book: Design Patterns: Elements of Reusable Object-Oriented Software. This book, written by Erich Gamma, Richard Helm, Ralph Johson, and John Vlissides, was published in 1994, and thoroughly shook the programming community.

Back in 1994, when C++ was becoming more and more prominent, object orientation was all the rage, and people were programming in Smalltalk. Programmers were simply not thinking in terms of patterns. Every good programmer, of course, had their own book of recipes that work, but they were not sharing them or trying to describe them in a formal way. The GoF book, as it is mostly called...

The original Gang of Four book separated patterns into three categories: creational, structural, and behavioral. To these three, another large category was added in recent years, concurrency patterns. Some concurrency patterns were covered in another classic book: Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects, Volume 2, by Douglas C Schmidt, Michael Stal, Hans Rohnert, and Frank Buschmann.

Creational patterns deal with delegation. They are focused on creating new objects and groups of related objects. These patterns will create objects for you, meaning that you don't have to create them directly.

The focus of structural patterns is aggregation. They define ways to compose objects in a way that creates new functionality from the constituent parts. They help us create software components.

Behavioral patterns are big...

While design patterns are undoubtedly a useful tool, many prominent computer scientists have expressed criticism directed both at the Design Patterns: Elements of Reusable Object-Oriented Software book and at the general way patterns are used in practice.

Over the years, programmers have learned that the patterns in the GoF book really aren't as widely applicable as the authors thought. Lots of them only apply to the object-oriented world. If we try to use them with a functional language, they are largely useless. They can also be greatly simplified when used in aspect-oriented languages.

Delphi, however, is an object-oriented language, so we can reuse most of the Gang of Four observations. Still, it is important to keep in mind how patterns should be used in practice.

As a main rule, you should never use design patterns to architect the software. Design patterns...

Every yin has its yang, and every hero has their dark side, and so the very existence of patterns suggest that there exists the opposite. We could simply call it a mess, but programmers try to find an order to everything, even in chaos, and so they cataloged the mess and described the many kinds of anti-patterns. I will only briefly touch on this topic, as the goal of this book is to teach you about order, not disorder, but there is always something to learn from bad examples.

Design patterns are nicely classified, and most programmers agree on how they should be named and defined. Anti-patterns, on the other hand, are messier. They hide behind different names and they provide mere sketches of behavior, not fully defined templates.

The nastiest of the anti-patterns is sometimes called a big ball of mud. A typical sign of this anti-pattern is that the code is a mess...

Patterns are not the only way of formalizing metaprogramming concepts. Patterns address specific problems, but sometimes we would like to express ideas that are not problem specific. Such formalizations are called principles. If they are related to program design, we call them, quite obviously, design principles.

Principles provide a view of a problem that is complementary to patterns. They don't give specific instructions on how to solve problems but rather instruct us how to write good code. A good programmer should, therefore, know both design patterns and design principles by heart. An excellent programmer, of course, also knows when to use patterns and principles and when to ignore them, but that's another story. You can only get such a level of knowledge by practicing programming for a long time.

Still, everyone has to start somewhere, and at...

This chapter provided a brief overview of a topic that will be discussed in the rest of the book: design patterns. We took a look at the broader picture and found that patterns are everywhere and that design patterns are only part of a larger group of programming patterns. We also learned about architectural patterns, which function on a higher level, and idioms, which are very low-level patterns. (We will talk more about architectural patterns in Chapter 11, Other Kinds of Patterns. Delphi idioms are introduced throughout this book, starting with this chapter.)

We then learned about at the history of patterns, and were introduced to Gang of Four and their Design Patterns book. We learned that patterns are not fixed in time, but are evolving, and that many patterns, especially ones dealing with parallel programming, were documented after that book was published.

After...