Book Image

Hands-On Design Patterns with Delphi

By : Primož Gabrijelčič
Book Image

Hands-On Design Patterns with Delphi

By: Primož Gabrijelčič

Overview of this book

Design patterns have proven to be the go-to solution for many common programming scenarios. This book focuses on design patterns applied to the Delphi language. The book will provide you with insights into the language and its capabilities of a runtime library. You'll start by exploring a variety of design patterns and understanding them through real-world examples. This will entail a short explanation of the concept of design patterns and the original set of the 'Gang of Four' patterns, which will help you in structuring your designs efficiently. Next, you'll cover the most important 'anti-patterns' (essentially bad software development practices) to aid you in steering clear of problems during programming. You'll then learn about the eight most important patterns for each creational, structural, and behavioral type. After this, you'll be introduced to the concept of 'concurrency' patterns, which are design patterns specifically related to multithreading and parallel computation. These will enable you to develop and improve an interface between items and harmonize shared memories within threads. Toward the concluding chapters, you'll explore design patterns specific to program design and other categories of patterns that do not fall under the 'design' umbrella. By the end of this book, you'll be able to address common design problems encountered while developing applications and feel confident while building scalable projects.
Table of Contents (18 chapters)
Title Page
Copyright and Credits
About Packt


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, no matter how you look at it. It is unreadable: the data is global; every class uses every other class, except for the code that no one uses at all; and so on and so on. If you are ever hired to work on such a project, find a better job (just some friendly advice).

Another anti-pattern is the blob. It occurs when the problem was not correctly decomposed. One class is doing most of the work, while others represent just small fragments that don't do anything significant. In Delphi, we can find this anti-pattern in badly organized projects where most of the functionality is implemented in the main form of class. Such a project can usually be saved by applying SOLID design principles, which I'll discuss in the next section.


The golden hammer anti-pattern happens when a programmer uses one technology to solve everything. I've seen projects where every data structure was a TStringList and others where all data structures were implemented with in-memory datasets. The best way of rescuing such projects is to put them in the hands of programmers with a wide knowledge of programming, data structures, and available tools.

Everyone who programmed in old-school BASIC has an intimate knowledge of a spaghetti code pattern: the code jumps here and there, doesn't follow any logic, and definitely does not use standard flow-control constructs, such as while. It is usually too difficult to decode and fix such an implementation. A better approach is to write a decent set of unit tests and then rewrite the problematic part from scratch. The last anti-pattern I want to mention is called copy and pasteprogramming. A typical sign of this anti-pattern is longer sequences of code that are frequently repeated in the source. There are almost no shared methods; everything is copied all over the place. This is a direct violation of the DRY design principle, which will be described in the next section and can be more-or-less simply solved by applying the same principle.