基本信息
编辑推荐
设计模式应用的价值和时机。
经典设计模式解析，包括单例模式、抽象工厂模式、责任链模式和观察者模式。
有待挖掘的潜力型设计模式，包括备忘录模式、命令模式和中介者模式。
如何利用Swift语言精髓让代码易于理解、易于测试、易于维护，并且拥有良好的架构。
如何利用Cocoa API实现经典设计模式。
Swift应用的难点和易错点。
内容简介
作译者
Adam Freeman
资深技术人员，畅销技术图书作家。除本书外还著有《HTML5权威指南》《ASP.NET 4高级程序设计（第4版）》等备受读者推崇的畅销书。
丘远乐
编程爱好者，iOS开发者，偶尔也写点Python。
资深技术人员，畅销技术图书作家。除本书外还著有《HTML5权威指南》《ASP.NET 4高级程序设计（第4版）》等备受读者推崇的畅销书。
丘远乐
编程爱好者，iOS开发者，偶尔也写点Python。
目录
第一部分 准备工作
第1章 设计模式 2
1.1 将设计模式置于上下文中 2
1.1.1 设计模式简介 3
1.1.2 设计模式的结构 3
1.1.3 量化设计模式 4
1.1.4 问题出现之后使用设计模式 4
1.1.5 设计模式的局限 5
1.2 关于本书 5
1.2.1 读者需要哪些知识背景 5
1.2.2 读者需要哪些软件 5
1.2.3 本书的结构 6
1.2.4 获取示例代码 6
1.3 总结 6
第2章 熟悉Xcode的使用 7
2.1 使用Xcode Playground 7
2.1.1 创建Playground 7
2.1.2 查看变量取值的历史记录 9
2.1.3 使用取值时间轴 11
2.1.4 在Playground中使用UI组件 13
第1章 设计模式 2
1.1 将设计模式置于上下文中 2
1.1.1 设计模式简介 3
1.1.2 设计模式的结构 3
1.1.3 量化设计模式 4
1.1.4 问题出现之后使用设计模式 4
1.1.5 设计模式的局限 5
1.2 关于本书 5
1.2.1 读者需要哪些知识背景 5
1.2.2 读者需要哪些软件 5
1.2.3 本书的结构 6
1.2.4 获取示例代码 6
1.3 总结 6
第2章 熟悉Xcode的使用 7
2.1 使用Xcode Playground 7
2.1.1 创建Playground 7
2.1.2 查看变量取值的历史记录 9
2.1.3 使用取值时间轴 11
2.1.4 在Playground中使用UI组件 13
书摘
设计模式
设
计模式相当于软件开发中的保险单。保险的运作原理就是现在支付小额保费，以避免日后可能出现的巨大损失。例如，给汽车购买盗抢险时，你所需要支付的保险费只相当于汽车价值的百分之几，可一旦汽车被盗了，你的整体损失会降到最低。虽然仍会有汽车被盗带来的不便，但至少不必再承受经济损失了。
在软件开发当中，设计模式就是对解决问题耗时的投保。保险费就是你当下为提升代码灵活性而付出的努力，其回报则是避免了以后痛苦而又漫长的重写程序的过程。你预计的问题可能永远也不会发生，因此即使你支付了保险费也不一定能够从中受益，这点与现实中的保险类似。不同的是，开发软件的过程很少一帆风顺，问题倒是时常出现，因此提升软件灵活性通常是一项不错的投资。
本书是针对有实际工作经验的专业程序员而编写的，重点讲解设计模式的实际应用和代码实例，而不是一味地对其进行抽象描述。在本书中，我会讲解最重要的设计模式，并使用Swift语言演示如何将这些设计模式应用到iOS开发中去。本书介绍的部分设计模式已经在Cocoa框架类中得到实现，我也会进一步演示如何利用这些模式开发稳定性和适应性更强的应用。
读完本书，你将了解现代软件开发中一些最重要的设计模式，了解这些模式所能解决的问题以及如何将它们应用到Swift项目中去。
1.1将设计模式置于上下文中
每位有经验的程序员都有一系列塑造了自己编码风格的非正式策略。这些策略从某种意义上说也相当于保险单，旨在避免先前项目中的问题反复出现。举个例子，如果你之前花了一个星期去解决临到上线前最后一刻修改数据库模式导致的问题，那么就算不能确定这个数据库模式以后是否会发生变化，你也会在日后的项目中再费点心思，以便确保整个应用中依赖该模式的部分没有硬编码。现在支付保险费是为了避免以后可能出现的更大损失。尽管以后你可能仍然需要对应用程序做一些改变，但是这个过程会更愉快一点。这就像保险公司对被盗汽车支付了赔偿之后，你再去购买一辆新车的过程一样。
这些非正式的策略存在两个问题。第一个问题是不一致。即使是经验相似的程序员，他们对于同一个问题的本质也可能会有不同的观点，且对该问题的最佳解决方案也可能会有不同的见解。
第二个问题是，非正式的策略是基于个人经历形成的，因而可能带有强烈的感情色彩。对问题解决难度的描述不足以把整个过程中所经历的痛苦纠结准确地传达出来，因而也很难说服其他人在预防措施上加大投入。同时，对于问题的重要程度，非正式的策略也很难保持客观。痛苦的经历难免留下阴影，在这种情况下，当你为避免重蹈覆辙而对项目做一些改进，却得不到充分支持时，你可能会觉得难以接受。
1.1.1设计模式简介
与之前提到的非正式策略类似，设计模式能够识别软件开发中常见的问题并提供相应的解决策略。但是，设计模式在表达方式上更客观一致，并且不受感情影响。
设计模式描述的策略是经证实的、切实可行的，也就是说，你可以将自己的方法与之进行比对。此外，由于它们覆盖了大部分常见问题，你会发现有些你个人不曾遇过的问题，也有相应的设计模式。
本书中的大部分设计模式源自《设计模式：可复用面向对象软件的基础》一书，它是由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides合著的经典著作。这本书的作者被称为GoF（Gang of Four，四人组 ），他们在书中阐述了现代软件开发中部分最重要和最基本的模式。
GoF的书值得一读，但是多少有些学术理论化。他们对设计模式进行了抽象解释，却并没有涉及某个特定的编程语言或者平台。这种抽象性增加了使用难度，很难让人弄清楚某个模式是否涵盖了你所关注的某个问题，因此也无法确定是否正确地实现了解决方案。
本书的目的就是将设计模式置于上下文中，并为读者提供轻松识别和应用所需要的模式的所有信息。同时，本书还提供了可以直接应用到项目之中的Swift实现。
1.1.2设计模式的结构
大部分设计模式适用于应用程序中的一小组对象，并且解决以下情况中出现的问题：一个对象（通常被称为调用组件，calling component）需要在应用程序中对一个或者多个其他对象进行操作。
对于本书中提到的每个设计模式，我都会阐述其解决的问题和原理，以及如何使用Swift实现。我也会讲解一些模式的常见变体，以及与模式最密切相关的缺陷。
UML哪去了
设
计模式相当于软件开发中的保险单。保险的运作原理就是现在支付小额保费，以避免日后可能出现的巨大损失。例如，给汽车购买盗抢险时，你所需要支付的保险费只相当于汽车价值的百分之几，可一旦汽车被盗了，你的整体损失会降到最低。虽然仍会有汽车被盗带来的不便，但至少不必再承受经济损失了。
在软件开发当中，设计模式就是对解决问题耗时的投保。保险费就是你当下为提升代码灵活性而付出的努力，其回报则是避免了以后痛苦而又漫长的重写程序的过程。你预计的问题可能永远也不会发生，因此即使你支付了保险费也不一定能够从中受益，这点与现实中的保险类似。不同的是，开发软件的过程很少一帆风顺，问题倒是时常出现，因此提升软件灵活性通常是一项不错的投资。
本书是针对有实际工作经验的专业程序员而编写的，重点讲解设计模式的实际应用和代码实例，而不是一味地对其进行抽象描述。在本书中，我会讲解最重要的设计模式，并使用Swift语言演示如何将这些设计模式应用到iOS开发中去。本书介绍的部分设计模式已经在Cocoa框架类中得到实现，我也会进一步演示如何利用这些模式开发稳定性和适应性更强的应用。
读完本书，你将了解现代软件开发中一些最重要的设计模式，了解这些模式所能解决的问题以及如何将它们应用到Swift项目中去。
1.1将设计模式置于上下文中
每位有经验的程序员都有一系列塑造了自己编码风格的非正式策略。这些策略从某种意义上说也相当于保险单，旨在避免先前项目中的问题反复出现。举个例子，如果你之前花了一个星期去解决临到上线前最后一刻修改数据库模式导致的问题，那么就算不能确定这个数据库模式以后是否会发生变化，你也会在日后的项目中再费点心思，以便确保整个应用中依赖该模式的部分没有硬编码。现在支付保险费是为了避免以后可能出现的更大损失。尽管以后你可能仍然需要对应用程序做一些改变，但是这个过程会更愉快一点。这就像保险公司对被盗汽车支付了赔偿之后，你再去购买一辆新车的过程一样。
这些非正式的策略存在两个问题。第一个问题是不一致。即使是经验相似的程序员，他们对于同一个问题的本质也可能会有不同的观点，且对该问题的最佳解决方案也可能会有不同的见解。
第二个问题是，非正式的策略是基于个人经历形成的，因而可能带有强烈的感情色彩。对问题解决难度的描述不足以把整个过程中所经历的痛苦纠结准确地传达出来，因而也很难说服其他人在预防措施上加大投入。同时，对于问题的重要程度，非正式的策略也很难保持客观。痛苦的经历难免留下阴影，在这种情况下，当你为避免重蹈覆辙而对项目做一些改进，却得不到充分支持时，你可能会觉得难以接受。
1.1.1设计模式简介
与之前提到的非正式策略类似，设计模式能够识别软件开发中常见的问题并提供相应的解决策略。但是，设计模式在表达方式上更客观一致，并且不受感情影响。
设计模式描述的策略是经证实的、切实可行的，也就是说，你可以将自己的方法与之进行比对。此外，由于它们覆盖了大部分常见问题，你会发现有些你个人不曾遇过的问题，也有相应的设计模式。
本书中的大部分设计模式源自《设计模式：可复用面向对象软件的基础》一书，它是由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides合著的经典著作。这本书的作者被称为GoF（Gang of Four，四人组 ），他们在书中阐述了现代软件开发中部分最重要和最基本的模式。
GoF的书值得一读，但是多少有些学术理论化。他们对设计模式进行了抽象解释，却并没有涉及某个特定的编程语言或者平台。这种抽象性增加了使用难度，很难让人弄清楚某个模式是否涵盖了你所关注的某个问题，因此也无法确定是否正确地实现了解决方案。
本书的目的就是将设计模式置于上下文中，并为读者提供轻松识别和应用所需要的模式的所有信息。同时，本书还提供了可以直接应用到项目之中的Swift实现。
1.1.2设计模式的结构
大部分设计模式适用于应用程序中的一小组对象，并且解决以下情况中出现的问题：一个对象（通常被称为调用组件，calling component）需要在应用程序中对一个或者多个其他对象进行操作。
对于本书中提到的每个设计模式，我都会阐述其解决的问题和原理，以及如何使用Swift实现。我也会讲解一些模式的常见变体，以及与模式最密切相关的缺陷。
UML哪去了
. 统一建模语言（Unified Modeling Language，UML）通常用来描述设计模式，但是我在本书中不会使用。我个人不是很喜欢UML，原因如下：首先，大多数开发人员并不完全理解UML，他们能从UML图中获得的信息少之又少。当然也有例外，大公司的工作人员就愿意用UML，因为大公司在开始开发之前会有一个详细的分析和设计阶段。但对于其他人而言，UML就是一种定义不清、让人误解的条条框框。
其次，我发现UML适合用于表示一些关系，但在其他方面基本毫无用处。很大程度上，理解模式意味着理解其中的逻辑，即了解其他组件的存在，而这个很难用UML来传达。
最后一点，有些不客观，UML代表了许多我个人不喜欢的软件开发方式。由于UML已经成为一个不变的参照点，并且常常被当作强化静态与僵化设计的武器，导致开发过程无法满足用户不断演进的需求。
基于这些原因（尽管比较主观），我不会在本书中使用UML。相反，我将使用一些形式比较自由的图解来说明想要强调的重点。
1.1.3量化设计模式
设计模式是个好东西，这个观点很容易让人接受。每个人都能认识到成熟方案的吸引力，因为它们确实能够帮助人们解决无数的项目难题。不过，要想说服团队中的其他程序员在项目中使用某个具体的模式却很困难。
通过一些问题，你可以评估某项保险是否具有投保价值。
? 该保险是否涵盖了可能会发生在我身上的不好的事情？
? 这些不好的事情发生的频率如何？
? 所需的保费是否只占处理该问题原需成本的小部分比例？
这些简单的问题能够让你很容易理解，如果你没有汽车或者你所在城市没有偷车贼的话，购买汽车保险是毫无意义的。这些问题还能让你意识到，如果你每年都为价值11 000美元的汽车支付10 000美元的保险费，其回报微乎其微。除非你觉得自己会遭遇多次盗窃，否则这是没有什么价值的。（如果真是这样的话，也许你应该考虑搬家了。）
尽管这个例子将保险概念简单化了，但是其中的道理还是很明晰的：除非能够带来回报，否则不要购买保险。同样的道理也适用于设计模式：除非某种模式提供了相应价值，并且还可以通过量化向他人说明，否则就不要采用该模式。用来评估设计模式的问题与评估保险价值的问题类似。
? 这个模式是否涵盖了我可能会遇到的问题？
? 这个问题发生的频率如何？
? 我对解决未来某个问题的在意程度，是否足以让我现在花费精力去实现这个设计模式？
这些问题很难回答。软件开发领域并没有保险中那样的精算表，因此要评估解决日后某个问题（尤其是可能不会出现的问题）所需的成本总值并不容易。
相反，人们往往容易被那些能够带来眼前利益的设计模式所吸引。例如，有些模式可以提升应用程序的模块化程度故经常被使用，因为它们可以让未来变化的影响最小化。此外，模块化程度高的应用程序中紧耦合的组件较少，这意味着非常容易隔离单元代码。隔离单元代码对高效单元测试而言非常重要，因此采用一个针对变化提供保障的模式有一项即时利益，那就是提升代码的可测试性。
同样，设计模式可以提升应用程序中的抽象程度，让开发人员能够在少花精力和少写重复代码的情况下给应用增加新功能。尽管不是每个人都认同避免设计模式所防范的问题的必要性，但几乎所有人都认同更快速、更简单地开发是件好事。
然而，对于应该采用哪个模式并没有简单直接的答案。最终采用哪个模式，将会是由开发团队的经验、其对规格完整性的信心及个体开发人员的能力共同作用的结果。
1.1.4问题出现之后使用设计模式
如果你是团队中唯一倡导使用设计模式的人，且团队成员又没有使用设计模式的经验，更没什么时间去考虑是否要采用设计模式的话，你会发现很难说服团队成员采用设计模式。一般说来，十有八九是没有说服其他人的可能性的，不过你倒也不用沮丧。
对此，我的建议是别逼得太急。如果强行要求团队采用新的做法，你就要为该做法导致的所有问题和延期负责。如果设计模式所防范的问题从未发生的话，那你就更加难堪了。可悲的是，对设计模式的倡导往往逃不过失败的劫数。
你不必感到绝望，姑且将本书放置一旁，等待时机的到来吧。如果担心的问题没有发生，比如数据库模式没有变，那你应该庆幸该项目躲过了一劫，然后接着完成下一个任务。
如果你担心的问题确实发生了，那也不必焦虑，因为你仍然能够因使用设计模式而受益。虽然现在项目陷入了你当初想要避免的困境，但是你可以把设计模式当作助你摆脱窘境的脚手架。你需要做的是选择最合适的设计模式，并以此为框架围绕问题构建整洁的代码。通过这种方式，你可以利用困境，适时地向团队介绍一个行之有效的解决方案。这种方式虽然不如在最初就避免问题发生，但至少能够形成一个长期性的解决方案，并借此机会坚定你对设计模式的热情。
1.1.5设计模式的局限
设计模式的优点很多，但是它也有自己的局限性。从本质上讲，设计模式就是别人在他们的项目中遇到问题时想出来的解决方案。设计模式是避免或解决问题的起点，而不是为了某个问题量身定制的解决方案。这并不意味着它们没有用，只是确实需要花一些精力对它们进行修正改造，以使其适合你的项目。
我们可以把设计模式看作配方，通过对其进行修正、改造和调整，我们就能获得有用的东西。一开始你也许需要对你的实现进行多次改进，但在多个项目中使用某个设计模式之后，你对它的理解就可能会更深入。最终，你会得到一些与最初的实现相比起来更加完善的方案，而这些方案会有助于将常见问题的影响最小化。
有些程序员将设计模式奉作不可变的法则。这些人是模式狂热者，他们把模式当作“最佳实践”来推广，认为必须对其始终遵循、不可更改。这种做法很不妥。使用不必要的模式或者抵制为了适应项目而对模式做出的修改，都是完全没有抓住问题关键的行为。
与模式狂热者争论这些问题毫无意义。他们很享受引用一些来源不明的言论带来的快乐，但事实上他们根本无法有效地证明自己的观点。我的建议是，无视他们，把精力放在构建优秀的软件上，使其稳定、可扩展、灵活地应对变化，而本书中探讨的设计模式正好可以帮助你实现此目标。
1.2关于本书
我将在本书中使用Swift语言和Cocoa框架讲解如何使用一些最重要的设计模式。Swift已经吸引了许多开发新手加入苹果平台，我写这本书则是想为各位提供关于Swift和Cocoa框架的知识。如果以前没接触过Swift开发，你可能会觉得Xcode是个令人费解的工具，但是我会在书中演示如何使用Xcode创建示例项目。如果不想自己敲代码，可以到Apress.com下载本书中的所有示例代码。
1.2.1读者需要哪些知识背景
要理解书中的概念，你需要一定的开发经验。虽然无需Swift开发经验，但是至少要了解面向对象编程的一些基础概念，并且使用过一门现代编程语言，比如Objective-C、C#、Java或者JavaScript。
1.2.2读者需要哪些软件
你需要有一台搭载了OS X 10.10（Yosemite）的Mac，同时还要下载并安装Xcode 6.1。如需下载Xcode，你可以到https://developer.apple.com注册一个开发者账号。如果没用过Xcode也不用担心，本书会在第2章介绍编写示例代码所需的知识。
1.2.3本书的结构
本书一共分为五部分，每个部分讲解一系列相关的主题。第一部分包含本章以及编写书中的示例代码需要用到的Xcode技巧。在这部分，我还开发了一款名为SportsStore的示例应用，以为演示设计模式的应用提供上下文。
剩下的每个部分都会重点讲解某一具体类型的模式。第二部分讲解创建型设计模式，这类模式是关于如何在应用中创建对象。第三部分探讨结构型设计模式，这类模式是关于定义和管理应用中各对象之间的关系的。第四部分重点研究描述各对象之间如何通信的设计模式。第五部分，我会解析模型/视图/控制器（Model/View/Controller，MVC）模式，该模式涉及整个应用结构，广泛用于Mac OS和iOS平台上的UI应用。
1.2.4获取示例代码
你可以到www.apress.com免费下载本书所有章节的示例代码。下载文件包含创建示例程序需要的所有代码，因此你无需自己动手输入代码。你不一定非要下载代码，但下载下来不仅方便你做实验，也便于你将代码剪切、粘贴到你自己的项目中。
如果确实想动手从头开始编写示例代码，正文部分已经详细列出了创建和修改的代码清单。我决不会让你去参考外部文件，或者挥挥手随便讲讲，把剩下的示例代码作为练习留给你去完成。本书每个例子的所有实现细节都可以在书中找到。
1.3总结
其次，我发现UML适合用于表示一些关系，但在其他方面基本毫无用处。很大程度上，理解模式意味着理解其中的逻辑，即了解其他组件的存在，而这个很难用UML来传达。
最后一点，有些不客观，UML代表了许多我个人不喜欢的软件开发方式。由于UML已经成为一个不变的参照点，并且常常被当作强化静态与僵化设计的武器，导致开发过程无法满足用户不断演进的需求。
基于这些原因（尽管比较主观），我不会在本书中使用UML。相反，我将使用一些形式比较自由的图解来说明想要强调的重点。
1.1.3量化设计模式
设计模式是个好东西，这个观点很容易让人接受。每个人都能认识到成熟方案的吸引力，因为它们确实能够帮助人们解决无数的项目难题。不过，要想说服团队中的其他程序员在项目中使用某个具体的模式却很困难。
通过一些问题，你可以评估某项保险是否具有投保价值。
? 该保险是否涵盖了可能会发生在我身上的不好的事情？
? 这些不好的事情发生的频率如何？
? 所需的保费是否只占处理该问题原需成本的小部分比例？
这些简单的问题能够让你很容易理解，如果你没有汽车或者你所在城市没有偷车贼的话，购买汽车保险是毫无意义的。这些问题还能让你意识到，如果你每年都为价值11 000美元的汽车支付10 000美元的保险费，其回报微乎其微。除非你觉得自己会遭遇多次盗窃，否则这是没有什么价值的。（如果真是这样的话，也许你应该考虑搬家了。）
尽管这个例子将保险概念简单化了，但是其中的道理还是很明晰的：除非能够带来回报，否则不要购买保险。同样的道理也适用于设计模式：除非某种模式提供了相应价值，并且还可以通过量化向他人说明，否则就不要采用该模式。用来评估设计模式的问题与评估保险价值的问题类似。
? 这个模式是否涵盖了我可能会遇到的问题？
? 这个问题发生的频率如何？
? 我对解决未来某个问题的在意程度，是否足以让我现在花费精力去实现这个设计模式？
这些问题很难回答。软件开发领域并没有保险中那样的精算表，因此要评估解决日后某个问题（尤其是可能不会出现的问题）所需的成本总值并不容易。
相反，人们往往容易被那些能够带来眼前利益的设计模式所吸引。例如，有些模式可以提升应用程序的模块化程度故经常被使用，因为它们可以让未来变化的影响最小化。此外，模块化程度高的应用程序中紧耦合的组件较少，这意味着非常容易隔离单元代码。隔离单元代码对高效单元测试而言非常重要，因此采用一个针对变化提供保障的模式有一项即时利益，那就是提升代码的可测试性。
同样，设计模式可以提升应用程序中的抽象程度，让开发人员能够在少花精力和少写重复代码的情况下给应用增加新功能。尽管不是每个人都认同避免设计模式所防范的问题的必要性，但几乎所有人都认同更快速、更简单地开发是件好事。
然而，对于应该采用哪个模式并没有简单直接的答案。最终采用哪个模式，将会是由开发团队的经验、其对规格完整性的信心及个体开发人员的能力共同作用的结果。
1.1.4问题出现之后使用设计模式
如果你是团队中唯一倡导使用设计模式的人，且团队成员又没有使用设计模式的经验，更没什么时间去考虑是否要采用设计模式的话，你会发现很难说服团队成员采用设计模式。一般说来，十有八九是没有说服其他人的可能性的，不过你倒也不用沮丧。
对此，我的建议是别逼得太急。如果强行要求团队采用新的做法，你就要为该做法导致的所有问题和延期负责。如果设计模式所防范的问题从未发生的话，那你就更加难堪了。可悲的是，对设计模式的倡导往往逃不过失败的劫数。
你不必感到绝望，姑且将本书放置一旁，等待时机的到来吧。如果担心的问题没有发生，比如数据库模式没有变，那你应该庆幸该项目躲过了一劫，然后接着完成下一个任务。
如果你担心的问题确实发生了，那也不必焦虑，因为你仍然能够因使用设计模式而受益。虽然现在项目陷入了你当初想要避免的困境，但是你可以把设计模式当作助你摆脱窘境的脚手架。你需要做的是选择最合适的设计模式，并以此为框架围绕问题构建整洁的代码。通过这种方式，你可以利用困境，适时地向团队介绍一个行之有效的解决方案。这种方式虽然不如在最初就避免问题发生，但至少能够形成一个长期性的解决方案，并借此机会坚定你对设计模式的热情。
1.1.5设计模式的局限
设计模式的优点很多，但是它也有自己的局限性。从本质上讲，设计模式就是别人在他们的项目中遇到问题时想出来的解决方案。设计模式是避免或解决问题的起点，而不是为了某个问题量身定制的解决方案。这并不意味着它们没有用，只是确实需要花一些精力对它们进行修正改造，以使其适合你的项目。
我们可以把设计模式看作配方，通过对其进行修正、改造和调整，我们就能获得有用的东西。一开始你也许需要对你的实现进行多次改进，但在多个项目中使用某个设计模式之后，你对它的理解就可能会更深入。最终，你会得到一些与最初的实现相比起来更加完善的方案，而这些方案会有助于将常见问题的影响最小化。
有些程序员将设计模式奉作不可变的法则。这些人是模式狂热者，他们把模式当作“最佳实践”来推广，认为必须对其始终遵循、不可更改。这种做法很不妥。使用不必要的模式或者抵制为了适应项目而对模式做出的修改，都是完全没有抓住问题关键的行为。
与模式狂热者争论这些问题毫无意义。他们很享受引用一些来源不明的言论带来的快乐，但事实上他们根本无法有效地证明自己的观点。我的建议是，无视他们，把精力放在构建优秀的软件上，使其稳定、可扩展、灵活地应对变化，而本书中探讨的设计模式正好可以帮助你实现此目标。
1.2关于本书
我将在本书中使用Swift语言和Cocoa框架讲解如何使用一些最重要的设计模式。Swift已经吸引了许多开发新手加入苹果平台，我写这本书则是想为各位提供关于Swift和Cocoa框架的知识。如果以前没接触过Swift开发，你可能会觉得Xcode是个令人费解的工具，但是我会在书中演示如何使用Xcode创建示例项目。如果不想自己敲代码，可以到Apress.com下载本书中的所有示例代码。
1.2.1读者需要哪些知识背景
要理解书中的概念，你需要一定的开发经验。虽然无需Swift开发经验，但是至少要了解面向对象编程的一些基础概念，并且使用过一门现代编程语言，比如Objective-C、C#、Java或者JavaScript。
1.2.2读者需要哪些软件
你需要有一台搭载了OS X 10.10（Yosemite）的Mac，同时还要下载并安装Xcode 6.1。如需下载Xcode，你可以到https://developer.apple.com注册一个开发者账号。如果没用过Xcode也不用担心，本书会在第2章介绍编写示例代码所需的知识。
1.2.3本书的结构
本书一共分为五部分，每个部分讲解一系列相关的主题。第一部分包含本章以及编写书中的示例代码需要用到的Xcode技巧。在这部分，我还开发了一款名为SportsStore的示例应用，以为演示设计模式的应用提供上下文。
剩下的每个部分都会重点讲解某一具体类型的模式。第二部分讲解创建型设计模式，这类模式是关于如何在应用中创建对象。第三部分探讨结构型设计模式，这类模式是关于定义和管理应用中各对象之间的关系的。第四部分重点研究描述各对象之间如何通信的设计模式。第五部分，我会解析模型/视图/控制器（Model/View/Controller，MVC）模式，该模式涉及整个应用结构，广泛用于Mac OS和iOS平台上的UI应用。
1.2.4获取示例代码
你可以到www.apress.com免费下载本书所有章节的示例代码。下载文件包含创建示例程序需要的所有代码，因此你无需自己动手输入代码。你不一定非要下载代码，但下载下来不仅方便你做实验，也便于你将代码剪切、粘贴到你自己的项目中。
如果确实想动手从头开始编写示例代码，正文部分已经详细列出了创建和修改的代码清单。我决不会让你去参考外部文件，或者挥挥手随便讲讲，把剩下的示例代码作为练习留给你去完成。本书每个例子的所有实现细节都可以在书中找到。
1.3总结
本章介绍了全书的内容和基本结构，并说明了阅读本书所需的经验和软件。在第2章中，我将简单地介绍本书涉及的Xocde知识。
