当前位置：首页 > news >正文

设计模式复习

news 2025/7/8 18:15:22

一、模式所采用的关系（e.g.继承…）

UML图例

二、各模式的特点、优缺点

1.创建型（5种创建型口诀:

抽象工厂按照工厂方法，建造单例原型）

将对象的使用和创建分离，使用对象时无需知道对象的创建细节，使得创建过程可以多次复用，且修改两者中的一个对另一个影响为0或很少。

软件系统运行时，类将实例化为对象，并由对象来协作完成各项业务功能。创建型模式对类的实例化过程进行了抽象，能够将软件模块中对象的创建和使用进行分离。

外界只需知道他们的共同接口而无需知道具体的细节，符合单一职责原则。

1.简单工厂（依赖、继承）

优点：

（1）实现对责任的分割

（2）客户端无需知道具体产品类的类名，只需知道对应参数即可，对于一些复杂的类名，可以减少使用者的记忆量

（3）通过引入配置文件，可以在不修改任何客户端代码的情况下更换，增加新的具体的产品类，一定程度上提高了系统的灵活性

缺点：

（1）工厂类集中了所有产品的创建逻辑，一旦不能正常工作，整个系统都要受影响

（2）会增加系统中类的个数，一定程度上增加了系统的复杂度和理解难度

（3）系统拓展困难，一旦增加新产品就不得不修改工厂逻辑，产品类型较多时，有可能会使工厂逻辑过于复杂，不利于系统的拓展和维护

（4）由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构

适用环境：

（1）创建对象少

（2）客户端对创建对象不关心

2.工厂方法（依赖、继承）

优点：

（1）用户无需关心细节，无需知道具体类名

（2）多态性设计，工厂可以自主确定创建何种对象，而细节完全封装在具体工厂内部，又被称为多态工厂模式，所有的工厂类都具有同一抽象父类

（3）在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口,无须修改客户端,也无须修改其他的具体工厂和具体产品,而只要添加一个具体工厂和具体产品即可。系统的可扩展性也就变得非常好,符合“开闭原则”。

缺点：
(1)在添加新产品时,需要编写新的具体产品类,而且还要提供与之对应的具体工厂类,系统中类的个数将成对增加,在一定程度上增加了系统的复杂度,有更多的类需要编译和运行,会给系统带来一些额外的开销。

(2)由于考虑到系统的可扩展性,需要引入抽象层,在客户端代码中均使用抽象层进行定义,增加了系统的抽象性和理解难度,且在实现时可能需要用到 DOM、反射等技术,增加了系统的实现难度。

适用情况:

(1)一个类不知道它所需要的对象的类:在工厂方法模式中,客户端不需要知道具体产品类的类名,只需要知道所对应的工厂即可,具体的产品对象由具体工厂类创建;客户端需要知道创建具体产品的工厂类。

(2)一个类通过其子类来指定创建哪个对象:在工厂方法模式中,对于抽象工厂类只需要提供一个创建产品的接口,而由其子类来确定具体要创建的对象,利用面向对象的多态性和里氏代换原则,在程序运行时,子类对象将覆盖父类对象,从而使得系统更容易扩展。

(3)将创建对象的任务委托给多个工厂子类中的某一个,客户端在使用时可以无须关心是哪一个工厂子类创建产品子类,需要时再动态指定,可将具体工厂类的类名存储在配置文件或数据库中。

3.抽象工厂方法（依赖、继承）

优点：

(1)抽象工厂模式隔离了具体类的生成,使得客户并不需要知道什么被创建。由于这种隔离,更换一个具体工厂就变得相对容易。所有的具体工厂都实现了抽象工厂中定义的那些公共接口,因此只需改变具体工厂的实例,就可以在某种程度上改变整个软件系统的行为。另外,应用抽象工厂模式可以实现高内聚低耦合的设计目的,因此抽象工厂模式得到了广泛的应用。

(2)当一个产品族中的多个对象被设计成一起工作时,它能够保证客户端始终只使用同一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说,是一种非常实用的设计模式。

(3)增加新的具体工厂和产品族很方便,无须修改已有系统,符合“开闭原则”

缺点：

在添加新的产品对象时,难以扩展抽象工厂来生产新种类的产品,这是因为在抽象工厂角色中规定了所有可能被创建的产品集合,要支持新种类的产品就意味着要对该接口进行扩展,而这将涉及对抽象工厂角色及其所有子类的修改,显然会带来较大的不便。

适用环境

(1)一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节,这对于所有类型的工厂模式都是重要的。用户无须关心对象的创建过程,将对象的创建和使用解耦。

(2)系统中有多于一个的产品族,而每次只使用其中某一产品族。可以通过配置文件等方式来使得用户可以动态改变产品族,也可以很方便地增加新的产品族。

(3)属于同一个产品族的产品将在一起使用,这一约束必须在系统的设计中体现出来,同一个产品族中的产品可以是没有任何关系的对象,但是它们都具有一些共同的约束,如同一操作系统下的按钮和文本框,按钮与文本框之间没有直接关系,但它们都是属于某一操作系统的,此时具有一个共同的约束条件:操作系统的类型。

(4)系统提供一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖于具体实现。对于这些产品,用户只需要知道它们提供了哪些具体的业务方法,而不需要知道这些对象的创建过程,在客户端代码中针对抽象编程,而将具体类写人配置文件中。

4.建造者模式（聚合、依赖、继承）

优点

(1)在建造者模式中,客户端不必知道产品内部组成的细节,将产品本身与产品的创建过程解耦,使得相同的创建过程可以创建不同的产品对象。

(2)每一个具体建造者都相对独立,与其他的具体建造者无关,因此可以很方便地替换具体建造者或增加新的具体建造者,用户使用不同的具体建造者即可得到不同的产品对象。

(3)可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰,也更方便使用程序来控制创建过程。

(4)增加新的具体建造者无须修改原有类库的代码,指挥者类针对抽象建造者类编程系统扩展方便,符合“开闭原则”

缺点

(1)建造者模式所创建的产品一般具有较多的共同点,其组成部分相似。如果产品之间的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制。

(2)如果产品的内部变化复杂,可能会导致需要定义很多具体建造者类来实现这种变化,导致系统变得很庞大。

适用环境

(1)需要生成的产品对象有复杂的内部结构,这些产品对象通常包含多个成员属性。

(2)需要生成的产品对象的属性相互依赖,需要指定其生成顺序。

(3)对象的创建过程独立于创建该对象的类。在建造者模式中引人了指挥者类,将创建过程封装在指挥者类中,而不在建造者类中。

(4)隔离复杂对象的创建和使用,并使得相同的创建过程可以创建不同的产品。

5.原型模式（关联、依赖、继承）

优点

(1)当创建新的对象实例较为复杂时,使用原型模式可以简化对象的创建过程,通过一个已有实例可以提高新实例的创建效率。

(2)可以动态增加或减少产品类。由于创建产品类实例的方法是产品类(具体原型类)内部具有的,因此增加新产品对整个结构没有影响。在原型模式中提供了抽象原型类,在客户端可以针对抽象原型类进行编程,而将具体原型类写在配置文件中,增加或减少产品类对原有系统都没有任何影响。

(3)原型模式提供了简化的创建结构。工厂方法模式常常需要有一个与产品类等级结构相同的等级结构,而原型模式就不需要这样,原型模式中产品的复制是通过封装在原型类中的 clone()方法实现的,无须专门的工厂类来创建产品。

(4)可以使用深克隆的方式保存对象的状态。使用原型模式将对象复制一份并将其状态保存起来,以便在需要的时候使用(如恢复到某一历史状态)。

缺点

(1)需要为每一个类配备一个克隆方法,而且这个克隆方法需要对类的功能进行通盘考虑,这对全新的类来说不是很难,但对已有的类进行改造时,不一定是件容易的事,必须修改其源代码,违背了“开闭原则”。

(2)在实现深克隆时需要编写较为复杂的代码。

适用环境

(1)创建新对象成本较大(如初始化需要占用较长的时间,占用太多的 CPU 资源或网络资源),新的对象可以通过原型模式对已有对象进行复制来获得,如果是相似对象,则可以
对其属性稍作修改。

(2)如果系统要保存对象的状态,而对象的状态变化很小,或者对象本身占内存不大的时候,也可以使用原型模式配合备忘录模式(第22章将介绍备忘录模式)来应用。相反,如果对象的状态变化很大,或者对象占用的内存很大,那么采用状态模式会比原型模式更好。

(3)需要避免使用分层次的工厂类来创建分层次的对象,并且类的实例对象只有一个或很少的几个组合状态,通过复制原型对象得到新实例可能比使用构造函数创建一个新实例更加方便。

6.单例模式（聚合、依赖）

优点

(1)提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例,所以它可以严格控制客户怎样以及何时访问它,并为设计及开发团队提供了共享的概念。

(2)由于在系统内存中只存在一个对象,因此可以节约系统资源,对于一些需要频繁创建和销毁的对象,单例模式无疑可以提高系统的性能。

(3)允许可变数目的实例。基于单例模式我们可以进行扩展,使用与单例控制相似的方法来获得指定个数的对象实例。

缺点

(1)由于单例模式中没有抽象层,因此单例类的扩展有很大的困难。

(2)单例类的职责过重,在一定程度上违背了"单一职责原则”。因为单例类既充当了工.厂角色,提供了工厂方法,同时又充当了产品角色,包含一些业务方法,将产品的创建和产品本身的功能融合到一起。

(3)滥用单例将带来一些负面问题,如为了节省资源将数据库连接池对象设计为单例类,可能会导致共享连接池对象的程序过多而出现连接池溢出;现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术,因此,如果实例化的对象长时间不被利用,系统会认为它是垃圾,会自动销毁并回收资源,下次利用时又将重新实例化,这将导致对象状态的丢失。

适用情况

(1)系统只需要一个实例对象,如系统要求提供一个唯一的序列号生成器,或者需要考虑资源消耗太大而只允许创建一个对象。

(2)客户调用类的单个实例只允许使用一个公共访问点,除了该公共访问点,不能通过其他途径访问该实例。

使用单例模式有一个必要条件:在一个系统中要求一个类只有一个实例时才应当使用单例模式。反过来,如果一个类可以有几个实例共存,就需要对单例模式进行改进,使之成为多例模式。

在使用的过程中我们还需要注意以下两个问题

(1)不要使用单例模式存取全局变量,因为这违背了单例模式的用意,最好将全局变量放到对应类的静态成员中。

(2)不要将数据库连接做成单例,因为一个系统可能会与数据库有多个连接,并且在有连接池的情况下,应当尽可能及时释放连接。单例模式由于使用静态成员存储类的实例,所以可能会造成资源无法及时释放,带来一些问题。

2.结构型（7种结构型口诀:

外观装饰按照适配的方式桥接组合，给亨元代理）

结构型模式(Structural Pattern)描述如何将类或者对象结合在一起形成更大的结构，就像搭积木,可以通过简单积木的组合形成复杂的、功能更为强大的结构.

结构型模式可以描述两种不同的东西:类与类的实例(即对象)。
根据这一点,结构型模式可以分为类结构型模式和对象结构型模式。
类结构型模式关心类的组合,由多个类可以组合成一个更大的系统,在类结构型模式中一般只存在继承关系和实现关系;
而对象结构型模式关心类与对象的组合,通过关联关系使得在一个类中定义另一个类的实例对象,然后通过该对象调用其方法。根据“合成复用原则”,在系统中应当尽量使用关联关系来替代继承关系,因此大部分结构型模式都是对象结构型模式。