Design patterns are insurance policies for software development. Insurance policies work by trading a little cost now to avoid the possibility of a lot of cost later. The premium you pay to insure a car against theft, for example, costs a few percent of the value of the car, but when the car is stolen, your overall costs are minimized. You still have to go through the inconvenience of having your car stolen, but at least you dont have to bear the financial loss as well.
In software development, design patterns are insurance against the time taken to solve problems. The premium is the time it takes to add extra flexibility to your code now, and the payout is avoiding a painful and protracted rewrite to change the way the application works later. Like real insurance policies, you may not benefit from paying the premium because the problem you anticipate might never happen, but software development rarely goes smoothly and problems often arise, so that additional flexibility is usually a good investment.
This is a book for hands-on professional programmers. I focus on the practical applications of design patterns and focus on code examples instead of abstract descriptions. I describe the most important design patterns and demonstrate how they can be applied to iOS using Swift. Some of the patterns I describe are already implemented in the Cocoa framework classes, and I show you how use them to create more robust and adaptable applications.
By the time you have finished reading this book, you will understand the most important design patterns in contemporary software development, the problems they are intended to solve, and how to apply them to your Swift projects.
Putting Design Patterns into Context
Every experienced programmer has a set of informal strategies that shape their coding style. These strategies are insurance policies against the recurrence of problems from earlier projects. If you have spent a week dealing with a last-minute database schema change, for example, then you will take a little extra time on future projects making sure that dependencies on the schema are not hard-coded throughout the application, even though you dont know for certain that the schema will change this time around. You pay a little premium now to avoid the potential for a bigger cost in the future. You may still have to make changes, but the process will be more pleasant, just like the process of shopping for a replacement car is made more pleasant when the insurance company pays for the stolen one.
There are two problems with informal strategies. The first problem is inconsistency . Programmers with similar experiences may have different views about what the nature of a problem is and will disagree about the best solution.
The second problem is that informal strategies are driven by personal experiences, which can be associated with strong emotions. Describing the difficulty of fixing a problem rarely conveys the pain and misery you endured, and that makes it hard to convince others of the need to invest in preventative measures. It also makes it difficult to be objective about the importance of the problem. Bad experiences linger, and you may find it hard to accept that there is little support for making the changes that would avoid problems you have encountered on previous projects.
Introducing Design Patterns
A design pattern identifies a common software development problem and provides a strategy for dealing with it, rather like the informal approach that I described earlier but that is expressed objectively, consistently, and free from emotional baggage.
The strategies that design patterns describe are proven to work, which means you can compare your own approach to them. And, since they cover the most common problems, you will find that there are design patterns for problems that you have not had to personally endure.
Most of the other design patterns in this book originate from a classic book called Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Addison-Wesley, 1995). The authors of this book are referred to as the Gang of Four ( GoF ) , and the patterns they describe are some of the most important and fundamental in modern software development.
The GoF book is worth reading but is somewhat academic in nature. Design patterns are expressed abstractly without reference to a particular programming language or platform. This abstraction makes them hard to use; it can be difficult to figure out whether a pattern describes a problem that you are concerned about and difficult to be sure that you have correctly implemented the solution.
My goal in this book is to put design patterns in context and give you all the information you need to easily identify and apply the patterns that you need, along with a Swift implementation that you can apply directly to your project.
Understanding the Structure of a Design Pattern
Most design patterns apply to small groups of objects in an application and solve a problem that arises when one objectknown as the calling component needs to perform an operation on one or more other objects in the application.
For each of the design patterns in this book, I describe the problem the pattern solves, explain how the pattern works, and show you how to implement the pattern using Swift. I also describe common variations on the pattern and describe the pitfalls most closely associated with the pattern.
WHERE IS THE UML?
The Unified Modeling Language (UML) is often used to describe patterns, but I dont use it in this book. I am not a fan of UML for several reasons. First, most developers dont completely understand UML and take in little information from a UML diagram. There are exceptions, of course, and these tend to be people who work in large corporations where there is a detailed analysis and design phase before development commences. For the rest of the world, UML is a poorly defined and misinterpreted mess of boxes and lines.
I find that UML is good for expressing some kinds of relationship but fails dismally at representing others. To a great extent, understanding patterns means understanding where logic that represents knowledge of other components exists, which is hard to convey using UML.
Finally, and rather less objectively, UML is symptomatic of many aspects of software development that I dont like. All too often, UML is used as a weapon to enforce static and inflexible designs and inhibits adapting a development process to meet evolving customer needs because the UML becomes an unchanging reference point.
For these reasons, as subjective as they are, I dont use UML in this book. Instead, Ill use free-form diagrams to illustrate the points that I want to emphasize.
Quantifying the Value of Design Patterns
It is easy to accept that design patterns are a good thing. Everyone understands the appeal of proven solutions used on countless projects to solve difficult problems. It is much harder to convince other programmers on the team that a specific pattern should be adopted in a project.
You can assess whether an insurance policy represents value for money by asking yourself some questions:
![Freeman Pro design patterns in Swift: [learn how to apply classic design patterns to iOS app development using Swift]](https://litark.com/uploads/posts/book/201359/freeman-pro-design-patterns-in-swift-learn-how.jpg)
![Freeman - Pro design patterns in Swift: [learn how to apply classic design patterns to iOS app development using Swift]](/uploads/posts/book/201359/thumbs/freeman-pro-design-patterns-in-swift-learn-how.jpg)
