Pro Design Patterns in Swift

所需积分/C币:10 2018-01-29 23:16:01 5.69MB PDF
收藏 收藏

The Swift programming language has transformed the world of iOS development and started a new age of modern development. Pro Design Patterns in Swift shows you how to harness the power and flexibility of Swift to apply the most important and enduring design patterns to your applications, taking your
Contents at a Glance About the author About the technical reviewer Part I: Getting Ready mann 1 Chapter 1: Understanding design patterns mmmmmm 3 Chapter 2: Getting Used to Xcode 9 Chapter 3: Creating the SportsStore App ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 25 Part i the creation patterns Chapter 4: The object Template Pattern mmammmmammmmmmm.55 Chapter 5: The Prototype Pattern ■■■■■■■国■■ ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■国■■ Chapter 6: The Singleton Pattern aammmmmmn 113 Chapter 7: The object Pool Pattern ng137 Chapter8:0 bject Pool variati0ns…,,,,,,,,…,,,,,,…,,157 Chapter 9: The Factory Method Pattern 187 Chapter 10: Abstract Factory Pattern ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 207 Chapter 11: The Builder Pattern mmRRRRIBRRIRBR EEIIRRRIRIIRIRIIIIIIn 233 Contents at a glance Partl:ThestructuralPatterns251 Chapter 12: The Adapter Pattern ■■■■ ■■■■■口■■■ ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■口■■■■■■ 253 Chapter 13: The Bridge Pattern ■■■■■■■■■■■■■■■■■■■■口■■■■■口■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 271 Chapter 14: The Decorator Pattern 293 Chapter 15: The composite Pattern.ammmmammmmmmammaaaaaaaamamaam 311 Chapter 16: The Facade Pattern ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■口■ 325 Chapter 17: The Flyweight Pattern mamammammmmmamaaaammnn 339 Chapter 18: The Proxy Patternmmmamma mamamIRIna 357 Part va the behavioral patterns Chapter 19: The Chain of Responsibility Pattern 383 Chapter 20: The command Pattern.mmmmmmm EIRIIaI 401 Chapter 21: The Mediator Pattern ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 423 Chapter 22: The observer Pattern an 「■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 447 Chapter 23: The Memento Pattern mmmmmmmmmmmam naa 473 Chapter 24: The Strategy Pattern ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■口■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 491 Chapter 25: The visitor Pattern mBm mmmm503 Chapter 26: The Template Method Pattern mmmm 517 Part v: The mvc pattern…n… ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 525 Chapter 27: The Model/view/Controller Pattern 527 Index 553 Part Getting ready Chapter Understanding Design Patterns 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 don 't 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 don't 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 CHAPTER 1: Understanding Design Patterns 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 ith 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 object- known 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 CHAPTER 1: Understanding Design Patterns WHERE IS THE UML? The Unified Modeling Language(UML) is often used to describe patterns, but I don't use it in this book. I am not a fan of UML for several reasons. First, most developers don 't 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 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 don 't 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, don' t use UML in this book. Instead, I'll 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 Does the policy address something bad that is likely to happen to me? How often does the bad thing occur? Is the cost of the policy a small fraction of the cost of dealing with the bad thing? These simple questions make it easy to understand that there is no point in buying car insurance if you don't have a car or if there are no car thieves in your town. They also highlight the poor value in paying $10,000 per year to insure an $11,000 car unless you anticipate multiple thefts(in which case, you might also consider moving to a different area) The point is clear even though this is a simplistic view of insurance: don't buy a policy unless it offers some benefit. The same is true for design patterns: dont adopt a pattern unless it offers value that you can quantify and articulate to others. the questions needed to assess the value for design patterns are similar Does the pattern identify a problem that I am likely to encounter? How often does this problem occur? Do I care enough about avoiding the risk of having to fix the problem in the future to undertake the work of implementing the design pattern today? CHAPTER 1: Understanding Design Patterns It can be hard to answer these questions. There are no actuarial tables for software development and it can be hard to estimate the amount of future effort that will be required to fix a problem especially one that may not arise) Instead, it can be easier to focus on the immediate benefits that a design pattern can offer For example, those patterns that increase the modularity of an application generally do so to minimize the effect of a future change, but a modular application has fewer tightly coupled components which means that it is easy to isolate units of code. Being able to isolate units of code is essential for effective unit testing, and so adopting a change-insurance pattern has an immediate benefit of improving the testability of code Equally, design patterns that increase the amount of abstraction in an application allow new features to be added with less effort and less code duplication almost everyone can agree that quicker and easier development is a good thing, even if they dont agree with the need to avoid the problem that a design pattern is intended to guard against There are no easy answers, however, and the final decision to adopt a design pattern will be driven by the combined experience of the development team, the confidence in the completeness of the specification, and the competence of individual developers Using a Design Pattern After the Problem Occurred You will find it hard to drive the adoption of patterns if you are the sole voice promoting them in a team that has no experience of them and little time to consider them. The chances are that you will fail to convince others don t be frustrated My advice is not to push too hard. If you force the team into following new practices, you will be held accountable for every problem and delay they cause, which will be especially difficult if the problem you are trying to guard against never happens. Advocates for design patterns are, sadly, often seen predictors of unlikely doom Don't lose hope, but put this book away and wait. If the problem you are concerned about doesnt occur-if, for example, the database schema doesn't change-then take pleasure in that the project dodged a bullet and move on to the next assignment Don't worry if the problem does occur; you can still benefit from design patterns. Your project is noy in a situation that you had hoped to avoid, but you can use the patterns as a framework for digging yourself out of the hole. Select the most appropriate design pattern and use it as a framework to structure the clean code around which you drive the resolution of the problem In this way, you can leverage a bad situation to introduce the team to a proven solution to the problem. This isn,'t as good as avoiding the problem in first place, but at least you will be able to create a long-term solution and lend some credibility to your enthusiasm for design patterns Understanding the Limitations of Design Patterns There is a lot to like about design patterns, but they have their limitations. By their nature, design patterns are solutions to problems that other people have encountered on other projects Design patterns are a starting point for avoiding or solving a problem and not a precisely tailored solution That doesn't mean they are not useful, but they do require some work in order to adapt them to fit into your project CHAPTER 1: Understanding Design Patterns Treat design patterns as recipes. Tinker, adapt, and adjust a pattern, and you will end up with something that works for you. You might need to refine your implementation a few times, and you use of a pattern is likely to get better with insight gained from several projects, but you'll end up with something that improves on your starting position and that helps minimize the impact of a common problem Some programmers treat design patterns as immutable laws. They are pattern zealots, someone who promotes the use of patterns as an inflexible"best practice"that should always be followed and cannot be adapted. That s rubbish. Applying patterns that you don't need or resisting adapting a pattern to fit into a project misses the point entirely There is no point trying to argue with a pattern zealot They get their pleasure from being able to reference ever more obscure sources, and there is no effective way to ground their views in reality My advice is to ignore them and focus on building good software by making it robust, scalable, and flexible enough to cope with changes, all of which can be aided by the design patterns described in this book About this book In this book, I describe how to use the most important design patterns using Swift and the Cocoa frameworks. Swift has attracted many new developers to the apple platform, so I have written this book to provide all of the information you will need about Swift and the Cocoa classes I use. I also show you how to create the example projects using Xcode, which can be a confusing tool if you are new to the world of Swift development. You can download all of the examples from Apress. com if you don't want to type in the code yourself What do you need to know You need to be an experienced developer to follow the concepts in book. No prior experience of Swift is required, but you should understand the basic concepts of object-oriented programming and have used a modern language such as Objective-C, C#, Java, or JavaScript What Software Do you need? You need to have a Mac running Os X 10.10 (Yosemite) and have downloaded and installed Xcode 6.1.TogetXcode,youwillneedtosignupasanAppleDeveloper,whichyoucandoathttps:// developer. apple. com. Don't worry if you are new to Xcode; I,'ll show you everything you need to know to follow the examples in Chapter 2 What is the structure of this book? This book is split into five parts, each of which covers a set of related topics. Part 1 contains this chapter and an Xcode primer for the techniques you will need to follow for the example in this book. I also build an example application called Sports store that I return to throughout this book to demonstrate how to apply design pattern in context

试读 127P Pro Design Patterns in Swift
立即下载 低至0.43元/次 身份认证VIP会员低至7折
    braveHeart_bob 还行,就是swift版本比较老!
    关注 私信 TA的资源
    Pro Design Patterns in Swift 10积分/C币 立即下载
    Pro Design Patterns in Swift第1页
    Pro Design Patterns in Swift第2页
    Pro Design Patterns in Swift第3页
    Pro Design Patterns in Swift第4页
    Pro Design Patterns in Swift第5页
    Pro Design Patterns in Swift第6页
    Pro Design Patterns in Swift第7页
    Pro Design Patterns in Swift第8页
    Pro Design Patterns in Swift第9页
    Pro Design Patterns in Swift第10页
    Pro Design Patterns in Swift第11页
    Pro Design Patterns in Swift第12页
    Pro Design Patterns in Swift第13页
    Pro Design Patterns in Swift第14页
    Pro Design Patterns in Swift第15页
    Pro Design Patterns in Swift第16页
    Pro Design Patterns in Swift第17页
    Pro Design Patterns in Swift第18页
    Pro Design Patterns in Swift第19页
    Pro Design Patterns in Swift第20页


    10积分/C币 立即下载 >