iOS设计模式 - (1)概述

最近可自由安排的时间比较多, iOS应用方面, 没什么好点子, 就先放下, 不写了。花点时间学学设计模式。

之后将会写一系列博文, 记录设计模式学习过程。

当然, 因为我自己是搞iOS的, 所以之后设计代码部分, 将尽量与objective-c相结合。

iOS设计模式 - 概述           by Colin丶

转载请注明出处:              http://blog.csdn.net/hitwhylz/article/details/40372113

一。定义

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。

使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 

毫无疑问，

• 设计模式于己于他人于系统都是多赢的；
• 模式使代码编制真正工程化；
• 设计模式是软件工程的基石脉络，如同大厦的结构一样。

二。目的

其目的就是一方面教你如何利用真实可靠的设计来组织代码的模板。 简单地说，就是从前辈们在程序设计过程中总结、抽象出来的通用优秀经验。

主要目的一方面是为了增加程序的灵活性、可重用性。 

 另一方面也有助于程序设计的标准化和提高系统开发进度。

也有人忠告：不要过于注重程序的“设计模式”。 有时候，写一个简单的算法，要比引入某种模式更容易。在多数情况下，程序代码应是简单易懂，甚至清洁工也能看懂。不过呢, 在大项目或者框架中，没有设计模式来组织代码，别人是不易理解的。

一个软件设计模型也仅仅只是一个引导。它必须根据程序设计语言和你的应用程序的特点和要求而特别的设计。

三。原则

面向对象有几个原则：

• 开闭原则（Open Closed Principle，OCP）
• 里氏代换原则（Liskov Substitution Principle，LSP）
• 依赖倒转原则（Dependency Inversion Principle，DIP）
• 接口隔离原则（Interface Segregation Principle，ISP）
• 合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）
• 最小知识原则（Principle of Least Knowledge，PLK，也叫迪米特法则）

开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。其他几条，则可以看做是开闭原则的实现方法。
设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。

1）"开-闭"原则( Open - ClosedPrinciple 缩写:OCP )：对扩展开放，对修改关闭

意思是,在一个系统中,对于扩展是开放的,对于修改是关闭的,一个好的系统是在不修改源代码的情况下,可以扩展你的功能..而实现开闭原则的关键就是抽象化.

通过扩展已有软件系统，可以提供新的行为，以满足对软件的新的需求，使变化中的软件有一定的适应性和灵活性。已有软件模块，特别是最重要的抽象层模块不能再修改，这使变化中的软件系统有一定的稳定性和延续性。
在"开-闭"原则中,不允许修改的是抽象的类或者接口,允许扩展的是具体的实现类,抽象类和接口在"开-闭"原则中扮演着极其重要的角色..即要预知可能变化的需求.又预见所有可能已知的扩展..所以在这里"抽象化"是关键!!!

可变性的封闭原则:找到系统的可变因素,将它封装起来..这是对"开-闭"原则最好的实现..不要把你的可变因素放在多个类中,或者散落在程序的各个角落..你应该将可变的因素,封套起来..并且切忌不要把所用的可变因素封套在一起..最好的解决办法是,分块封套你的可变因素!!避免超大类,超长类,超长方法的出现!!给你的程序增加艺术气息,将程序艺术化是我们的目标!!

2） 里氏代换原则:任何基类可以出现的地方,子类也可以出现

Liskov Substitution Principle（里氏代换原则）：子类能够必须能够替换基类能够从出现的地方。子类也能在基类 的基础上新增行为。这yi讲的是基类和子类的关系，只有这种关系存在时，里氏代换原则才存在。正方形是长方形是理解里氏代换原则的经典例子。

3） 依赖倒转原则:：要依赖抽象,而不要依赖具体的实现.

依赖倒置（Dependence Inversion Principle）原则讲的是：要依赖于抽象，不要依赖于具体。简单的说，依赖倒置原则要求客户端依赖于抽象耦合。原则表述：
（1）抽象不应当依赖于细节；细节应当依赖于抽象；
（2）要针对接口编程，不针对实现编程。
如果说开闭原则是目标,依赖倒转原则是到达"开闭"原则的手段..如果要达到最好的"开闭"原则,就要尽量的遵守依赖倒转原则..可以说依赖倒转原则是对"抽象化"的最好规范!!我个人感觉,依赖倒转原则也是里氏代换原则的补充..你理解了里氏代换原则,再来理解依赖倒转原则应该是很容易的..

4）合成/聚合复用原则（CARP）:要尽量使用合成/聚合原则,而不是继承关系达到软件复用的目的

合成/聚合复用原则（Composite/Aggregate ReusePrinciple或CARP）经常又叫做合成复用原则（Composite ReusePrinciple或CRP），就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对象通过向这些对象的委派达到复用已有功能的目的。简而言之，要尽量使用合成/聚合，尽量不要使用继承。
要尽量使用合成/聚合原则,而不是继承关系达到软件复用的目的。此原则和里氏代换原则氏相辅相成的,两者都是具体实现"开-闭"原则的规范..违反这一原则:就无法实现"开-闭"原则..先来看看什么是合成,什么是聚合.

什么是合成?
合成:是指一个整体对依托他而存在的关系,例如:一个人对他的房子和家具,其中他的房子和家具是不能被共享的,因为那些东西都是他自己的..并且人没了,这个也关系就没了..这个例子就好像,乌鸡百凤丸这个产品,它是有乌鸡和上等药材合成而来的一样..也比如网络游戏中的武器装备合成一样,多种东西合并为一种超强的东西一样..

什么是聚合?
聚合:聚合是比合成关系的一种更强的依赖关系,聚合是一个整体对个体的部分,例如,一个奔驰S360汽车,对奔驰S360引擎,奔驰S360轮胎的关系..这些关系就是带有聚合性质的..因为奔驰S360引擎和奔驰S360轮胎他们只能被奔驰S360汽车所用,离开了奔驰S360汽车,它们就失去了存在的意义..在我们的设计中,这样的关系不应该频繁出现..这样会增大设计的耦合度..

明白了合成和聚合关系,再来理解合成/聚合原则应该就清楚了..要避免在系统设计中出现,一个类的继承层次超过3次..如果这样的话,可以考虑重构你的代码,或者重新设计结构..当然最好的办法就是考虑使用合成/聚合原则...

5）迪米特法则:系统中的类,尽量不要与其他类互相作用,减少类之间的耦合度

迪米特法则（Law of Demeter或简写LoD）又叫最少知识原则（Least Knowledge Principle或简写为LKP），也就是说，一个对象应当对其它对象有尽可能少的了解。
其它表述：只与你直接的朋友们通信，不要跟"陌生人"说话。一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的public方法，我就调用这么多，其他的一概不关心。
迪米特法则与设计模式Facade模式、Mediator模式使民无知
系统中的类,尽量不要与其他类互相作用,减少类之间的耦合度,因为在你的系统中,扩展的时候,你可能需要修改这些类,而类与类之间的关系,决定了修改的复杂度,相互作用越多,则修改难度就越大,反之,如果相互作用的越小,则修改起来的难度就越小..例如A类依赖B类,则B类依赖C类,当你在修改A类的时候,你要考虑B类是否会受到影响,而B类的影响是否又会影响到C类..如果此时C类再依赖D类的话,呵呵,我想这样的修改有的受了..

6）接口隔离法则:这个法则与迪米特法则是相通的

接口隔离原则（Interface Segregation Principle）讲的是：使用多个专门的接口比使用单一的总接口总要好。换而言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。
过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。
迪米特法则是目的,而接口隔离法则是对迪米特法则的规范..为了做到尽可能小的耦合性,我们需要使用接口来规范类,用接口来约束类.要达到迪米特法则的要求,最好就是实现接口隔离法则,实现接口隔离法则,你也就满足了迪米特法则...

四。分类

设计模式分为三种类型，共23种。

• 创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。
• 结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
• 行为型模式：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式、访问者模式。

按字典序排列简介如下。

• Abstract Factory（抽象工厂模式）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
• Adapter（适配器模式）：将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
• Bridge（桥接模式）：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
• Builder（建造者模式）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
• Chain of Responsibility（职责链模式）：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
• Command（命令模式）：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
• Composite（组合模式）：将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。
• Decorator（装饰模式）：动态地给一个对象添加一些额外的职责。就扩展功能而言， 它比生成子类方式更为灵活。
• Facade（外观模式）：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
• Factory Method（工厂模式）：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其子类。
• Flyweight（享元模式）：运用共享技术有效地支持大量细粒度的对象。
• Interpreter（解析器模式）：给定一个语言, 定义它的文法的一种表示，并定义一个解释器, 该解释器使用该表示来解释语言中的句子。
• Iterator（迭代器模式）：提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。
• Mediator（中介模式）：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
• Memento（备忘录模式）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
• Observer（观察者模式）：定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。
• Prototype（原型模式）：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
• Proxy（代理模式）：为其他对象提供一个代理以控制对这个对象的访问。
• Singleton（单例模式）：保证一个类仅有一个实例，并提供一个访问它的全局访问点。 单例模式是最简单的设计模式之一，但是对于Java的开发者来说，它却有很多缺陷。在九月的专栏中，David Geary探讨了单例模式以及在面对多线程（multi-threading）、类装载器（class loaders）和序列化（serialization）时如何处理这些缺陷。
• State（状态模式）：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
• Strategy（策略模式）：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
• Template Method（模板方法模式）：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
• Visitor（访问者模式）：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

虽然这篇文章看起来比较头大, 都是文字。但它确实是学习设计模式需要了解的一些的。

当然, 我这里的资料也是从网上copy来的。 摘录了一些我觉得有必要了解的。

对于这些知识, 看着理解就好了。

学习的路上, 与君共勉