设计模式:可复用面向对象软件的基础

最新推荐文章于 2024-09-05 19:30:08 发布

原创

最新推荐文章于 2024-09-05 19:30:08 发布 · 809 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#设计模式

文章目录

设计模式
创建型模式
结构型模式
行为模式

设计模式

设计模式的书我听闻比较经典的有《设计模式:可复用面向对象软件的基础》、《Head first 设计模式》、《设计模式之禅》、《大话设计模式》、《Python编程实战：运用设计模式、并发和程序库创建高质量程序》。
前两本都看过，看的时候感觉都貌似理解了，当时也能在工作中运用一下。不过过个三五个月就发会现，这些知识又丢了。所以打算搞个便于记忆的摘要出来。没事拿出来翻翻下，勾起下记忆。主要是结构图，适应性，效果。基本上看结构图就能理解了。

我建议大家反复阅读《设计模式:可复用面向对象软件的基础》。其他书适合初学者阅读。
感觉这些模式在客户端开发中体现的比较多。在Web开发中较少。
拿Android来说，
View和ViewGroup其实就是composite模式。
在View和ViewGroup中的事件传递，就是CHAIN OF RESPONSIBILITY。
而Observer更是有现在的接口observer和observable

设计模式有4个基本要素

模式名称
问题：描述了应该在何时使用模式。
解决方案：描述了设计的组成部分，它们之间的相互关系及各自的职责和协作方式。
效果：描述了模式应用的效果及使用模式应权衡的问题。

23个设计模式

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

设计模式分类

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3M3BIyTI-1667554561799)(http://7xr7gu.com1.z0.glb.clouddn.com/2017-01-03-14833524720547.jpg)]

我们根据两条准则(表1-1)对模式进行分类。

目的准则

第一是目的准则,即模式是用来完成什么工作的。
模式依据其目的可分为创建型(Creational)、结构型(Structural)、或行为型(Behavioral)三种。
创建型模式与对象的创建有关;
结构型模式处理类或对象的组合;
行为型模式对类或对象怎样交互和怎样分配职责进行描述。

范围准则

第二是范围准则,指定模式主要是用于类还是用于对象。
类模式处理类和子类之间的关系,这些关系通过继承建立,是静态的,在编译时刻便确定下来了。
对象模式处理对象间的关系,这些关系在运行时刻是可以变化的,更具动态性。从某种意义上来说,几乎所有模式都使用继承机制,所以"类模式"只指那些集中于处理类间关系的模式,而大部分模式都属于对象模式的范畴。

创建型类模式将对象的部分创建工作延迟到子类,而创建型对象模式则将它延迟到另一个对象中。
结构型类模式使用继承机制来组合类,而结构型对象模式则描述了对象的组装方式。
行为型类模式使用继承描述算法和控制流,而行为型对象模式则描述一组对象怎样协作以完成单个对象所无法完成的任务

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PEqNqo5Z-1667554561800)(http://7xr7gu.com1.z0.glb.clouddn.com/2017-01-03-14833528226620.jpg)]

导致重新设计的一般原因，以及解决这些问题的设计模式举例

通过显式地指定一个类来创建对象在创建对象时指定类名将使你受特定实现的约束而不是特定接口的约束。这会使未来的变化更复杂。要避免这种情况,应该间接地创建对象。
设计模式: AbstractFactory , FactoryMethod , Prototype 。
对特殊操作的依赖当你为请求指定一个特殊的操作时,完成该请求的方式就固定下来了。为避免把请求代码写死,你将可以在编译时刻或运行时刻很方便地改变响应请求的方法。
设计模式: ChainofResposibility , Command。
对硬件和软件平台的依赖外部的操作系统接口和应用编程接口(API)在不同的软硬件平台上是不同的。依赖于特定平台的软件将很难移植到其他平台上,甚至都很难跟上本地平台的更新。所以设计系统时限制其平台相关性就很重要了。
设计模式: AbstractFactory , Bridge。
对对象表示或实现的依赖知道对象怎样表示、保存、定位或实现的客户在对象发生变化时可能也需要变化。对客户隐藏这些信息能阻止连锁变化。
设计模式: AbstractFactory , Bridge , Memento, Proxy
算法依赖算法在开发和复用时常常被扩展、优化和替代。依赖于某个特定算法的对象在算法发生变化时不得不变化。因此有可能发生变化的算法应该被孤立起来。
设计模式: Builder, Iterator, Strategy , TemplateMethod , Visitor
紧耦合紧耦合的类很难独立地被复用,因为它们是互相依赖的。紧耦合产生单块的系统,要改变或删掉一个类,你必须理解和改变其他许多类。这样的系统是一个很难学习、移植和维护的密集体。松散耦合提高了一个类本身被复用的可能性,并且系统更易于学习、移植、修改和扩展。设计模式使用抽象耦合和分层技术来提高系统的松散耦合性。
设计模式: AbstractFactory , Command , Facade , Mediator , Observer ,Chainof Responsibility。
通过生成子类来扩充功能通常很难通过定义子类来定制对象。每一个新类都有固定的实现开销(初始化、终止处理等)。定义子类还需要对父类有深入的了解。如,重定义一个操作可能需要重定义其他操作。一个被重定义的操作可能需要调用继承下来的操作。并且子类方法会导致类爆炸,因为即使对于一个简单的扩充,你也不得不引入许多新的子类。一般的对象组合技术和具体的委托技术,是继承之外组合对象行为的另一种灵活方法。新的功能可以通过以新的方式组合已有对象,而不是通过定义已存在类的子类的方式加到应用中去。另一方面,过多使用对象组合会使设计难于理解。许多设计模式产生的设计中,你可以定义一个子类,且将它的实例和已存在实例进行组合来引入定制的功能。
设计模式: Bridge, ChainofResponsibility ,Composite , Decorator , Observer , Str ategy 。
不能方便地对类进行修改有时你不得不改变一个难以修改的类。也许你需要源代码而又没有 (对于商业类库就有这种情况 ),或者可能对类的任何改变会要求修改许多已存在的其他子类。设计模式提供在这些情况下对类进行修改的方法。
设计模式: Adapter , Decorator , Visitor 。

设计模式所支持的设计的可变方面

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dNd1dsQh-1667554561800)(http://7xr7gu.com1.z0.glb.clouddn.com/2017-01-05-14834218177272.jpg)]

设计模式背后的6大设计原则

单一职责原则：一个类只能有一个修改原因，>1个原因就说明需要提取出去。
里氏替换原则：能使用父类的地方，都能替换成子类。
依赖倒置原则：面向接口编程，而不是面向实现编程。就是要抽象，定标准。
接口隔离原则
开闭原则：面向修改封闭，面向扩展开放。就是新需求来了，不要改原来的实现，通过新增类来实现需求。这样影响最小。

创建型模式

创建型模式抽象了实例化过程。它们帮助一个系统独立于如何创建、组合和表示它的那些对象。一个类创建型模式使用继承改变被实例化的类,而一个对象创建型模式将实例化委托给另一个对象。

在这些模式中有两个不断出现的主旋律。第一,它们都将关于该系统使用哪些具体的类的信息封装起来。第二,它们隐藏了这些类的实例是如何被创建和放在一起的。

ABSTRACT FACTORY(抽象工厂)–对象创建型模式

意图
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
别名
Kit
动机略
适用性
在以下情况下可以使用Abstract Factory模式
- 一个系统要独立于它的产品的创建、组合和表示时。
- 一个系统要由多个产品系列中的一个来配置时。
- 当你要强调一系列相关的产品对象的设计以便进行联合使用时。
- 当你提供一个产品类库，而只想显示它们的接口而不是实现时。
结构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-roHpzDUg-1667554561801)(http://7xr7gu.com1.z0.glb.clouddn.com/2017-01-03-14833571344859.jpg)]
参与者略
协作
- 通常在运行时刻创建一个ConcreteFactory类的实例。这一具体的工厂创建具有特定实现的产品对象。为创建不同的产品对象，客户应使用不同的具体工厂。
- AbstractFactory将产品对象的创建延迟到它的ConcreteFactory子类。
效果
AbstractFactory模式有下面的一些优点和缺点:
1. 它分离了具体的类 Abstract Factory模式帮助你控制一个应用创建的对象的类。因为
  一个工厂封装创建产品对象的责任和过程,它将客户与类的实现分离。客户通过它们的抽象接口操纵实例。产品的类名也在具体工厂的实现中被分离;它们不出现在客户代码中。
2. 它使得易于交换产品系列一个具体工厂类在一个应用中仅出现一次— 即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置,这是因为一个抽象工厂创建了一个完整的产品系列,所以整个产品系列会立刻改变。
3. 它有利于产品的一致性当一个系列中的产品对象被设计成一起工作时,一个应用一次只能使用同一个系列中的对象,这一点很重要。而 AbstractFactory 很容易实现这一点。
4. 难以支持新种类的产品难以扩展抽象工厂以生产新种类的产品。这是因为
  AbstractFactory接口确定了可以被创建的产品集合。支持新种类的产品就需要扩展该工厂接口,这将涉及A bstractFactory类及其所有子类的改变。
实现略

BUILDER(生成器)–对象创建型模式

意图将一个复杂对象的构建与它的表示分离，使得现样的构建过程可以创建不同的表示。
动机略
适应性
在以下情况使用Builder模式
- 在创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
- 当构造过程必须允许被构造的对象有不同的表示时。
结构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fjqtKP24-1667554561802)(http://7xr7gu.com1.z0.glb.clouddn.com/2017-01-03-14833583785270.jpg)]
参与者略
协作

客户创建Director对象，并用它所想要的Builder对象进行配置。
一旦产品部件被生成，导向器就会通知生成器。
生成器处理导向器的请求，并将部件添加到该产品中。
客户从生成品中检索产品。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-y8VOV6TE-1667554561803)(http://7xr7gu.com1.z0.glb.clouddn.com/2017-01-03-14833585531301.jpg)]

效果
这里是Builder模式的主要效果：
1. 它使你可以改变一个产品的内部表示。Builder对象提供给导向器一个构造产品的抽象接口。该接口使得生成器可以隐藏这个产品的表示和内部结构。它同时也隐藏了该产品是如何装配的。因为产品是通过抽象接口构造的,你在改变该产品的内部表示时所要做的只是定义一个新的生成器。
它将构造代码和表示代码分开。Builder模式通过封装一个复杂对象的创建和表示方式提高了对象的模块性。客户不需要知道定义产品内部结构的类的所有信息;这些类是不出现在Builder接口中的。每个Con creteBuilder包含了创建和装配一个特定产品的所有代码。这些代码只需要写一次;然后不同的Dir ector可以复用它以在相同部件集合的基础上构作不同的Product。
它使你可对构造过程进行更精细的控制。Builder 模式与一下子就生成产品的创建型模式不同,它是在导向者的控制下一步一步构造产品的。仅当该产品完成时导向者才从生成器中取回它。因此Builder接口相比其他创建型模式能更好的反映产品的构造过程。这使你可以更精细的控制构建过程,从而能更精细的控制所得产品的内部结构。
实现略
代码示例略
已知应用略
相关模式
Abstract Factory与Builder相似，因为它也可以创建复杂对象。主要的区别是Builder模式着重于一步步构造一个复杂对象。而Abstract Factory着重于多个系列的产品对象(简单的或是复杂的)。Builder在最后的一步返回产品，而对于Abstract Factory来说，产品是立即返回的。
Composite通常是用Builder生成的。

FACTORY METHOD(工厂方法) --对象创建型模式

意图定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。
别名虚构造器(Virtual Constructor)
动机框架使用抽象类定义和维护对象之间的关系。这些对象的创建通常也由框架负责。
适用性
在下列情况下可以使用Factory Method模式：
1. 当一个类不知道它所必须创建的对象的类的时候。
2. 当一个类希望由它的子类来指定它所创建的对象的时候。
3. 当类将创建对象的职责委托给多个帮助子类中的一某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。
结构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-r0HJzaXl-1667554561803)(http://7xr7gu.com1.z0.glb.clouddn.com/2017-01-03-14834109567700.jpg)]
参与者
- Product --定义工厂方法所创建的对象的接口
- ContreteProduct–实现Product
- Creator–声明工厂方法，该方法返回一个Product类型的对象;可以调用工厂方法以创建一个Product对象。
- ConcreteCreator–重定义工厂方法以返回一个ConcreteProduct实例。
协作 Creator依赖于它的子类来定义工厂方法，所以它返回一个适当的ConcreteProduct实例。
效果
工厂方法不再将与特定应用有关的类绑定到你的代码中。代码仅处理Product接口；因此它可以与用户定义的任何Concret