精华内容
下载资源
问答
  • 2013-03-21整理出来的23个设计模式优缺点,部分地方的理解可能不是很到位。 简单的介绍了23个设计模式的优点和缺点,以及使用场景,同时举了该设计模式的经典例子。
  • 主要参考:图说设计模式 文章目录面向对象设计模式的六大原则创建型模式1. 简单工厂模式4简单工厂模式的主要优缺点简单工厂模式的应用场景2. 工厂方法模式5工厂模式的主要优缺点:工厂模式的主要应用场景3. 抽象工厂...

    design-patterns
    主要参考:

    文章目录

    面向对象设计模式的六(7)大原则

    1. 开闭原则(Open Close Principle)

      开闭原则的意思是:对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。简言之,是为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点。

    2. 里氏代换原则(Liskov Substitution Principle)

      里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。LSP 是继承复用的基石,只有当派生类可以替换掉基类,且软件单位的功能不受到影响时,基类才能真正被复用,而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化,而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。

    3. 依赖倒置原则(Dependence Inversion Principle)

      这个原则是开闭原则的基础,具体内容:针对接口编程,依赖于抽象而不依赖于具体。

    4. 接口隔离原则(Interface Segregation Principle)

      这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。它还有另外一个意思是:降低类之间的耦合度。由此可见,其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想,它强调降低依赖,降低耦合。

    5. 迪米特法则,又称最少知道原则(Demeter Principle)

      最少知道原则是指:一个实体应当尽量少地与其他实体之间发生相互作用,使得系统功能模块相对独立。

    6. 合成复用原则(Composite Reuse Principle)

      合成复用原则是指:尽量使用对象组合、聚合、关联,而不是继承来达到复用的目的。

    7. 单一职责原则(Single-Responsibility Principle ):

      1. 一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中
      2. 就一个类而言,应该仅有一个引起它变化的原因。

    创建型模式

    创建型模式(Creational Pattern)对类的实例化过程进行了抽象,能够将软件模块中对象的创建和对象的使用分离。为了使软件的结构更加清晰,外界对于这些对象只需要知道它们共同的接口,而不清楚其具体的实现细节,使整个系统的设计更加符合单一职责原则。

    创建型模式在创建什么(What),由谁创建(Who),何时创建(When)等方面都为软件设计者提供了尽可能大的灵活性。创建型模式隐藏了类的实例的创建细节,通过隐藏对象如何被创建和组合在一起达到使整个系统独立的目的。

    包含模式

    • 简单工厂模式(Simple Factory)

      重要程度:4 (5为满分)

    • 工厂方法模式(Factory Method)

      重要程度:5

    • 抽象工厂模式(Abstract Factory)

      重要程度:5

    • 建造者模式(Builder)

      重要程度:2

    • 原型模式(Prototype)

      重要程度:3

    • 单例模式(Singleton)

      重要程度:4

    1. 简单工厂模式4

    在这里插入图片描述

    简单工厂模式的主要优缺点

    1. 简单工厂模式最大的优点在于实现对象的创建和对象的使用分离,将对象的创建交给专门的工厂类负责,
    2. 但是其最大的缺点在于工厂类不够灵活,增加新的具体产品需要修改工厂类的判断逻辑代码(违反开闭原则),而且产品较多时,工厂方法代码将会非常复杂。

    简单工厂模式的应用场景

    1. 简单工厂模式适用情况包括:工厂类负责创建的对象比较少;客户端只知道传入工厂类的参数,对于如何创建对象不关心。

    2. 工厂方法模式5

    工厂方法(FactoryMethod)模式的定义:定义一个创建产品对象的工厂接口,将产品对象的实际创建工作推迟到具体子工厂类当中。这满足创建型模式中所要求的“创建与使用相分离”的特点。

    工厂模式-日志记录实例 类图
    在这里插入图片描述
    在这里插入图片描述

    工厂模式的主要优缺点:

    1. 工厂方法模式的主要优点是增加新的产品类时无须修改现有系统,并封装了产品对象的创建细节,系统具有良好的灵活性和可扩展性;
    2. 其缺点在于增加新产品的同时需要增加新的工厂,导致系统类的个数成对增加,在一定程度上增加了系统的复杂性。

    工厂模式的主要应用场景

    1. 工厂方法模式适用情况包括:一个类不知道它所需要的对象的类;一个类通过其子类来指定创建哪个对象;将创建对象的任务委托给多个工厂子类中的某一个,客户端在使用时可以无须关心是哪一个工厂子类创建产品子类,需要时再动态指定。

    3. 抽象工厂模式5

    抽象工厂(AbstractFactory)模式的定义:是一种为访问类提供一个创建一组相关或相互依赖对象的接口,且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。
    在这里插入图片描述
    在这里插入图片描述

    抽象工厂模式的主要优缺点:

    1. 抽象工厂模式的主要优点是隔离了具体类的生成,使得客户并不需要知道什么被创建,而且每次可以通过具体工厂类创建一个产品族中的多个对象,增加或者替换产品族比较方便,增加新的具体工厂和产品族很方便;
    2. 主要缺点在于增加新的产品等级结构很复杂,需要修改抽象工厂和所有的具体工厂类,对“开闭原则”的支持呈现倾斜性。

    抽象工厂模式的主要应用场景

    1. 抽象工厂模式适用情况包括:一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节;系统中有多于一个的产品族,而每次只使用其中某一产品族;属于同一个产品族的产品将在一起使用;系统提供一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖于具体实现。

    4. 原型模式3

    原型(Prototype)模式的定义如下:用一个已经创建的实例作为原型,通过复制该原型对象来创建一个和原型相同或相似的新对象。在这里,原型实例指定了要创建的对象的种类。用这种方式创建对象非常高效,根本无须知道对象创建的细节。例如,Windows 操作系统的安装通常较耗时,如果复制就快了很多。在生活中复制的例子非常多,这里不一一列举了。
    在这里插入图片描述

    参考:https://www.cnblogs.com/haizai/p/12404326.html

    浅拷贝的介绍

    1)对于数据类型是基本数据类的成员变量,浅拷贝会直接进行值传递,也就是将该属性值复制一份给新的对象。
    2)对于数据类型是引用数据类型的成员变量,比如说成员变量是某个数组、某个类的对象等,那么浅拷贝会进行引用传递,也就是只是将该成员变量的引用值(内存地址)复制一份给新的对象。因为实际上两对象的该成员变量都指向同一个实例。在这种情况下,在一个对象中修改该成员变量会影响到另一个对象的该成员变量值
    3)前面的克隆羊是浅拷贝
    4)浅拷贝是使用默认的clone()方法来实现
    sheep = (Sheep)supper.clone();

    深拷贝基本介绍

    1)复制对象的所有基本数据类型的成员变量值
    2)为所有引用数据类型的成员变量申请存储空间,并复制每个引用数据类型成员变量所引用的对象,直到该对象可达的所有对象。也就是说,对象进行深拷贝要对整个对象进行拷贝
    3)深拷贝实现方式1 :重写clone方法来实现深拷贝
    4)深拷贝实现方式2 :通过对象序列化实现深拷贝

    原型模式的主要应用场景

    大体上有两种使用场景

    1. 在需要一个类的大量对象的时候,使用原型模式是最佳选择,因为原型模式是在内存中对这个对象进行拷贝,要比直接new这个对象性能要好很多,在这种情况下,需要的对象越多,原型模式体现出的优点越明显。

    2. 如果一个对象的初始化需要很多其他对象的数据准备或其他资源的繁琐计算,那么可以使用原型模式。

    3. 当需要一个对象的大量公共信息,少量字段进行个性化设置的时候,也可以使用原型模式拷贝出现有对象的副本进行加工处理。

    注:原型模式的拷贝是从内存(堆内存)中以二进制流的方式进行拷贝,重新分配一个内存块,并不会执行任何构造函数。

    5. 单例模式4

    单例(Singleton)模式的定义:指一个类只有一个实例,且该类能自行创建这个实例的一种模式。例如,Windows 中只能打开一个任务管理器,这样可以避免因打开多个任务管理器窗口而造成内存资源的浪费,或出现各个窗口显示内容的不一致等错误。
    在这里插入图片描述

    单例模式的主要优缺点:

    1. 单例模式的主要优点在于提供了对唯一实例的受控访问并可以节约系统资源;
    2. 其主要缺点在于因为缺少抽象层而难以扩展,且单例类职责过重。

    单例模式的主要应用场景

    1. 系统只需要一个实例对象;客户调用类的单个实例只允许使用一个公共访问点。(一个具有自动编号主键的表可以有多个用户同时使用,但数据库中只能有一个地方分配下一个主键编号,否则会出现主键重复,因此该主键编号生成器必须具备唯一性,可以通过单例模式来实现。)

    结构型模式

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

    结构型模式可以分为类结构型模式对象结构型模式

    • 类结构型模式关心类的组合,由多个类可以组合成一个更大的系统,在类结构型模式中一般只存在继承关系和实现关系。

    • 对象结构型模式关心类与对象的组合,通过关联关系使得在一 个类中定义另一个类的实例对象,然后通过该对象调用其方法。

    根据“合成复用原则”,在系统中尽量使用关联关系来替代继承关系,因此大部分结构型模式都是对象结构型模式

    包含模式

    • 适配器模式(Adapter)

      重要程度:4

    • 桥接模式(Bridge)

      重要程度:3

    • 组合模式(Composite)

      重要程度:4

    • 装饰模式(Decorator)

      重要程度:3

    • 外观模式(Facade)

      重要程度:5

    • 享元模式(Flyweight)

      重要程度:1

    • 代理模式(Proxy)

      重要程度:4

    1. 适配器模式4

    适配器模式(Adapter)的定义如下:将一个类的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类能一起工作。适配器模式分为类结构型模式和对象结构型模式两种,前者类之间的耦合度比后者高,且要求程序员了解现有组件库中的相关组件的内部结构,所以应用相对较少些。

    在这里插入图片描述

    适配器模式的主要优缺点

    1. 适配器模式的主要优点是将目标类和适配者类解耦,增加了类的透明性和复用性,同时系统的灵活性和扩展性都非常好,更换适配器或者增加新的适配器都非常方便,符合“开闭原则”;
    2. 类适配器模式的缺点是适配器类在很多编程语言中不能同时适配多个适配者类,对象适配器模式的缺点是很难置换适配者类的方法。

    适配器模式的主要应用场景

    1. 适配器模式适用情况包括:系统需要使用现有的类,而这些类的接口不符合系统的需要;想要建立一个可以重复使用的类,用于与一些彼此之间没有太大关联的一些类一起工作

    实例:

    Sun公司在1996年公开了Java语言的数据库连接工具JDBC,JDBC使得Java语言程序能够与数据库连接,并使用SQL语言来查询和操作数据。JDBC给出一个客户端通用的抽象接口,每一个具体数据库引擎(如SQL Server、Oracle、MySQL等)的JDBC驱动软件都是一个介于JDBC接口和数据库引擎接口之间的适配器软件。抽象的JDBC接口和各个数据库引擎API之间都需要相应的适配器软件,这就是为各个不同数据库引擎准备的驱动程序。

    2. 桥接模式3

    桥接(Bridge)模式的定义如下:将抽象与实现分离,使它们可以独立变化。它是用组合关系代替继承关系来实现,从而降低了抽象和实现这两个可变维度的耦合度。

    在这里插入图片描述

    桥接模式的主要优缺点

    1. 桥接模式的主要优点是分离抽象接口及其实现部分,是比多继承方案更好的解决方法,桥接模式还提高了系统的可扩充性,在两个变化维度中任意扩展一个维度,都不需要修改原有系统,实现细节对客户透明,可以对用户隐藏实现细节;
    2. 其主要缺点是增加系统的理解与设计难度,且识别出系统中两个独立变化的维度并不是一件容易的事情。

    桥接模式的主要应用场景

    1. 需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的继承联系;抽象化角色和实现化角色可以以继承的方式独立扩展而互不影响;一个类存在两个独立变化的维度,且这两个维度都需要进行扩展;设计要求需要独立管理抽象化角色和具体化角色;不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统。

    桥接模式实例:

    如果需要开发一个跨平台视频播放器,可以在不同操作系统平台(如Windows、Linux、Unix等)上播放多种格式的视频文件,常见的视频格式包括MPEG、RMVB、AVI、WMV等。现使用桥接模式设计该播放器。

    3. 组合模式4

    组合(Composite)模式的定义:有时又叫作部分-整体模式,它是一种将对象组合成树状的层次结构的模式,用来表示“部分-整体”的关系,使用户对单个对象和组合对象具有一致的访问性。

    组合模式的实现根据所实现的接口的区别分为两种形式,分别称为安全式透明式

    在这里插入图片描述

    组合模式的主要优点有:

    1. 组合模式使得客户端代码可以一致地处理单个对象和组合对象,无须关心自己处理的是单个对象,还是组合对象,这简化了客户端代码;
    2. 更容易在组合体内加入新的对象,客户端不会因为加入了新的对象而更改源代码,满足“开闭原则”;

    组合模式的主要应用场景

    这种组合模式正是应树形结构而生,所以组合模式的使用场景就是出现树形结构的地方。比如:文件目录显示,多及目录呈现等树形结构数据的操作。

    两种实现方式的选择

    **这里所说的安全式组成模式是指:**从客户端使用组成模式上看是否更安全,如果是安全的,那么就不会有发生误操作的可能,能访问的方法都是被支持的。
    **这里所说的透明性组成模式是指:**从客户端使用组成模式上,是否需要区分到底是“树枝对象”还是“树叶对象”。如果是透明的,那就不用区分,对于客户而言,都是Component对象,具体的类型对于客户端而言是透明的,是无需关心的。

    对于组合模式而言,在安全性和透明性上,会更看重透明性,毕竟组合模式的目的是:让客户端不再区分操作的是树枝对象还是树叶对象,而是以一个统一的方式来操作。

    而且对于安全性的实现,需要区分的是树枝对象还是树叶对象。有时候,需要将对象进行类型转换,却发现类型信息丢失了,只好强行转换,这种类型转换必然是不够安全的。

    因此在使用组合模式的时候,建议多采用透明式的实现方式。

    4. 装饰模式3

    装饰(Decorator)模式的定义:指在不改变现有对象结构的情况下,动态地给该对象增加一些职责(即增加其额外功能)的模式,它属于对象结构型模式。

    在这里插入图片描述

    装饰模式的主要优缺点

    装饰(Decorator)模式的主要优点有:

    • 采用装饰模式扩展对象的功能比采用继承方式更加灵活。
    • 可以设计出多个不同的具体装饰类,创造出多个不同行为的组合。

    其主要缺点是:装饰模式增加了许多子类,如果过度使用会使程序变得很复杂。

    装饰模式的主要应用场景

    • 当需要给一个现有类添加附加职责,而又不能采用生成子类的方法进行扩充时。例如,该类被隐藏或者该类是终极类或者采用继承方式会产生大量的子类。
    • 当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时,采用继承关系很难实现,而采用装饰模式却很好实现。
    • 当对象的功能要求可以动态地添加,也可以再动态地撤销时。

    装饰模式的实例

    装饰模式在 Java 语言中的最著名的应用莫过于 Java I/O 标准库的设计了。例如,InputStream 的子类 FilterInputStream,OutputStream 的子类 FilterOutputStream,Reader 的子类 BufferedReader 以及 FilterReader,还有 Writer 的子类 BufferedWriter、FilterWriter 以及 PrintWriter 等,它们都是抽象装饰类。

    5. 外观模式5

    外观模式的主要优缺点

    外观模式主要优点在于对客户屏蔽子系统组件,减少了客户处理的对象数目并使得子系统使用起来更加容易,它实现了子系统与客户之间的松耦合关系,并降低了大型软件系统中的编译依赖性,简化了系统在不同平台之间的移植过程;

    其缺点在于不能很好地限制客户使用子系统类,而且在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”。

    外观模式的主要应用场景

    外观模式适用情况包括:要为一个复杂子系统提供一个简单接口;客户程序与多个子系统之间存在很大的依赖性;在层次化结构中,需要定义系统中每一层的入口,使得层与层之间不直接产生联系。

    外观模式的实例

    6. 享元模式1

    享元模式(Flyweight Pattern):运用共享技术有效地支持大量细粒度对象的复用。系统只使用少量的对象,而这些对象都很相似,状态变化很小,可以实现对象的多次复用。由于享元模式要求能够共享的对象必须是细粒度对象,因此它又称为轻量级模式,它是一种对象结构型模式。

    • 类图

    在这里插入图片描述

    • 时序图

    在这里插入图片描述

    享元模式的主要优缺点

    享元模式主要优点在于它可以极大减少内存中对象的数量,使得相同对象或相似对象在内存中只保存一份;

    其缺点是使得系统更加复杂,并且需要将享元对象的状态外部化,而读取外部状态使得运行时间变长。

    享元模式的主要应用场景

    一个系统有大量相同或者相似的对象,由于这类对象的大量使用,造成内存的大量耗费;对象的大部分状态都可以外部化,可以将这些外部状态传入对象中;多次重复使用享元对象。

    享元模式的实例:

    享元模式在编辑器软件中大量使用,如在一个文档中多次出现相同的图片,则只需要创建一个图片对象,通过在应用程序中设置该图片出现的位置,可以实现该图片在不同地方多次重复显示。

    7. 代理模式4

    代理模式(Proxy Pattern) :给某一个对象提供一个代 理,并由代理对象控制对原对象的引用。代理模式的英 文叫做Proxy或Surrogate,它是一种对象结构型模式。

    代理模式的定义:由于某些原因需要给某对象提供一个代理以控制对该对象的访问。这时,访问对象不适合或者不能直接引用目标对象,代理对象作为访问对象和目标对象之间的中介。

    • 代理模式类图:
      在这里插入图片描述
    • 代理模式时序图
      在这里插入图片描述

    代理模式的主要优缺点

    代理模式的主要优点有:

    • 代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用;能够协调调用者和被调用者,在一定程度上降低了系 统的耦合度。
    • 代理对象可以扩展目标对象的功能,也可以控制对真实对象的使用权限;
    • 远程代理使得客户端可以访问在远程机器上的对象,远程机器 可能具有更好的计算性能与处理速度,可以快速响应并处理客户端请求。;
    • 虚拟代理通过使用一个小对象来代表一个大对象,可以减少系 统资源的消耗,对系统进行优化并提高运行速度。

    其主要缺点是:

    • 在客户端和目标对象之间增加一个代理对象,会造成请求处理速度变慢;
    • 增加了系统的复杂度;

    代理模式的主要应用场景

    • 智能引用(Smart Reference)代理:当一个对象被引用时,提供一些额外的操作,如将此对象被调用的次数记录下来等。

    • 保护(Protect or Access)代理:控制对一个对象的访问,可以给不同的用户提供不同级别的使用权限。

    • Copy-on-Write代理:它是虚拟代理的一种,把复制(克隆)操作延迟 到只有在客户端真正需要时才执行。一般来说,对象的深克隆是一个 开销较大的操作,Copy-on-Write代理可以让这个操作延迟,只有对象被用到的时候才被克隆。

    • 虚拟(Virtual)代理:如果需要创建一个资源消耗较大的对象,先创建一个消耗相对较小的对象来表示,真实对象只在需要时才会被真正创建。

    • 远程(Remote)代理:为一个位于不同的地址空间的对象提供一个本地 的代理对象,这个不同的地址空间可以是在同一台主机中,也可是在 另一台主机中,远程代理又叫做大使(Ambassador)。

    代理模式的实例

    动态代理

    • 动态代理是一种较为高级的代理模式,它的典型应用就是Spring AOP。
    • 在传统的代理模式中,客户端通过Proxy调用RealSubject类的request()方法,同时还在代理类中封装了其他方法(如preRequest()和postRequest()),可以处理一些其他问题。
    • 如果按照这种方法使用代理模式,那么真实主题角色必须是事先已经存在的,并将其作为代理对象的内部成员属性。如果一个真实主题角色必须对应一个代理主题角色,这将导致系统中的类个数急剧增加,因此需要想办法减少系统中类的个数,此外,如何在事先不知道真实主题角色的情况下使用代理主题角色,这都是动态代理需要解决的问题。
    • 动态代理模式的结构图

    行为型模式

    行为型模式(Behavioral Pattern)是对在不同的对象之间划分责任和算法的抽象化。

    行为型模式不仅仅关注类和对象的结构,而且重点关注它们之间的相互作用。

    通过行为型模式,可以更加清晰地划分类与对象的职责,并研究系统在运行时实例对象 之间的交互。在系统运行时,对象并不是孤立的,它们可以通过相互通信与协作完成某些复杂功能,一个对象在运行时也将影响到其他对象的运行。

    行为型模式分为类行为型模式和对象行为型模式两种:

    • 类行为型模式:类的行为型模式使用继承关系在几个类之间分配行为,类行为型模式主要通过多态等方式来分配父类与子类的职责。
    • 对象行为型模式:对象的行为型模式则使用对象的聚合关联关系来分配行为,对象行为型模式主要是通过对象关联等方式来分配两个或多个类的职责。根据“合成复用原则”,系统中要尽量使用关联关系来取代继承关系,因此大部分行为型设计模式都属于对象行为型设计模式

    包含模式

    • 职责链模式(Chain of Responsibility)

      重要程度:3

    • 命令模式(Command)

      重要程度:4

    • 解释器模式(Interpreter)

      重要程度:1

    • 迭代器模式(Iterator)

      重要程度:5

    • 中介者模式(Mediator)

      重要程度:2

    • 备忘录模式(Memento)

      重要程度:2

    • 观察者模式(Observer)

      重要程度:5

    • 状态模式(State)

      重要程度:3

    • 策略模式(Strategy)

      重要程度:4

    • 模板方法模式(Template Method)

      重要程度:3

    • 访问者模式(Visitor)

      重要程度:1

    1. 职责链模式3(也叫责任链模式。)

    责任链(Chain of Responsibility)模式的定义:为了避免请求发送者与多个请求处理者耦合在一起,将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链;当有请求发生时,可将请求沿着这条链传递,直到有对象处理它为止。
    类图:
    a

    责任链模式的主要优缺点

    责任链模式是一种对象行为型模式,其主要优点如下。

    1. 降低了对象之间的耦合度。该模式使得一个对象无须知道到底是哪一个对象处理其请求以及链的结构,发送者和接收者也无须拥有对方的明确信息。
    2. 增强了系统的可扩展性。可以根据需要增加新的请求处理类,满足开闭原则。
    3. 增强了给对象指派职责的灵活性。当工作流程发生变化,可以动态地改变链内的成员或者调动它们的次序,也可动态地新增或者删除责任。
    4. 责任链简化了对象之间的连接。每个对象只需保持一个指向其后继者的引用,不需保持其他所有处理者的引用,这避免了使用众多的 if 或者 if···else 语句。
    5. 责任分担。每个类只需要处理自己该处理的工作,不该处理的传递给下一个对象完成,明确各类的责任范围,符合类的单一职责原则。

    其主要缺点如下。

    1. 不能保证每个请求一定被处理。由于一个请求没有明确的接收者,所以不能保证它一定会被处理,该请求可能一直传到链的末端都得不到处理。
    2. 对比较长的职责链,请求的处理可能涉及多个处理对象,系统性能将受到一定影响。
    3. 职责链建立的合理性要靠客户端来保证,增加了客户端的复杂性,可能会由于职责链的错误设置而导致系统出错,如可能会造成循环调用。

    责任链模式的主要应用场景

    1. 有多个对象可以处理一个请求,哪个对象处理该请求由运行时刻自动确定。
    2. 可动态指定一组对象处理请求,或添加新的处理者。
    3. 在不明确指定请求处理者的情况下,向多个处理者中的一个提交请求。

    责任链模式的实例

    2. 命令模式4

    命令模式(Command Pattern):将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通,这样方便将命令对象进行储存、传递、调用、增加与管理。

    在软件开发系统中,常常出现“方法的请求者”与“方法的实现者”之间存在紧密的耦合关系。这不利于软件功能的扩展与维护。例如,想对行为进行“撤销、重做、记录”等处理都很不方便,因此“如何将方法的请求者与方法的实现者解耦?”变得很重要,命令模式能很好地解决这个问题

    类图:
    在这里插入图片描述

    命令模式主要优缺点

    命令模式的主要优点如下。

    1. 降低系统的耦合度。命令模式能将调用操作的对象与实现该操作的对象解耦。
    2. 增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类,它满足“开闭原则”,对扩展比较灵活。
    3. 可以实现宏命令。命令模式可以与组合模式结合,将多个命令装配成一个组合命令,即宏命令。
    4. 方便实现 Undo (撤销)和 Redo(准备) 操作。命令模式可以与后面介绍的备忘录模式结合,实现命令的撤销与恢复。

    其缺点是:可能产生大量具体命令类。因为计对每一个具体操作都需要设计一个具体命令类,这将增加系统的复杂性。

    命令模式的主要应用场景

    命令模式通常适用于以下场景。

    1. 当系统需要将请求调用者与请求接收者解耦时,命令模式使得调用者和接收者不直接交互。
    2. 当系统需要随机请求命令或经常增加或删除命令时,命令模式比较方便实现这些功能。
    3. 当系统需要执行一组操作时,命令模式可以定义宏命令来实现该功能。
    4. 当系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作时,可以将命令对象存储起来,采用备忘录模式来实现。

    命令模式的实例

    很多系统都提供了宏命令功能,如UNIX平台下的Shell编程,可以将多条命令封装在一个命令对象中,只需要一条简单的命令即可执行一个命令序列,这也是命令模式的应用实例之一。
    恰饭:
    在这里插入图片描述

    3. 解释器模式1TODO

    4. 迭代器模式5

    迭代器(Iterator)模式的定义:提供一个对象来顺序访问聚合对象中的一系列数据,而不暴露聚合对象的内部表示

    迭代器模式是通过将聚合对象的遍历行为分离出来,抽象成迭代器类来实现的,其目的是在不暴露聚合对象的内部结构的情况下,让外部代码透明地访问聚合的内部数据。

    类图:
    在这里插入图片描述

    迭代器模式的主要优缺点

    主要优点如下。

    1. 访问一个聚合对象的内容而无须暴露它的内部表示。
    2. 遍历任务交由迭代器完成,这简化了聚合类。
    3. 它支持以不同方式遍历一个聚合,甚至可以自定义迭代器的子类以支持新的遍历。
    4. 增加新的聚合类和迭代器类都很方便,无须修改原有代码。
    5. 封装性良好,为遍历不同的聚合结构提供一个统一的接口。

    其主要缺点是:增加了类的个数,这在一定程度上增加了系统的复杂性

    迭代器模式的主要应用场景

    1. 当需要为聚合对象提供多种遍历方式时。
    2. 当需要为遍历不同的聚合结构提供一个统一的接口时。
    3. 当访问一个聚合对象的内容而无须暴露其内部细节的表示时。

    由于聚合与迭代器的关系非常密切,所以大多数语言在实现聚合类时都提供了迭代器类,因此大数情况下使用语言中已有的聚合类的迭代器就已经够了。

    迭代器模式的实例

    java中的Iterator

    5. 中介者模式2

    中介者(Mediator)模式的定义:定义一个中介对象来封装一系列对象之间的交互,使原有对象之间的耦合松散,且可以独立地改变它们之间的交互。中介者模式又叫调停模式,它是迪米特法则的典型应用。

    中介者模式的主要优缺点

    中介者模式是一种对象行为型模式,其主要优点如下。

    1. 降低了对象之间的耦合性,使得对象易于独立地被复用。
    2. 将对象间的一对多关联转变为一对一的关联,提高系统的灵活性,使得系统易于维护和扩展。

    其主要缺点是:当同事类太多时,中介者的职责将很大,它会变得复杂而庞大,以至于系统难以维护。

    中介者模式的主要应用场景

    • 当对象之间存在复杂的网状结构关系而导致依赖关系混乱且难以复用时。
    • 当想创建一个运行于多个类之间的对象,又不想生成新的子类时。

    中介者模式的实例

    6. 备忘录模式2

    备忘录(Memento)模式的定义:在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,以便以后当需要时能将该对象恢复到原先保存的状态。该模式又叫快照模式。

    类图:
    在这里插入图片描述

    package memento;
    public class MementoPattern
    {
        public static void main(String[] args)
        {
            Originator or=new Originator();
            Caretaker cr=new Caretaker();       
            or.setState("S0"); 
            System.out.println("初始状态:"+or.getState());           
            cr.setMemento(or.createMemento()); //保存状态      
            or.setState("S1"); 
            System.out.println("新的状态:"+or.getState());        
            or.restoreMemento(cr.getMemento()); //恢复状态
            System.out.println("恢复状态:"+or.getState());
        }
    }
    //备忘录
    class Memento
    { 
        private String state; 
        public Memento(String state)
        { 
            this.state=state; 
        }     
        public void setState(String state)
        { 
            this.state=state; 
        }
        public String getState()
        { 
            return state; 
        }
    }
    //发起人
    class Originator
    { 
        private String state;     
        public void setState(String state)
        { 
            this.state=state; 
        }
        public String getState()
        { 
            return state; 
        }
        public Memento createMemento()
        { 
            return new Memento(state); 
        } 
        public void restoreMemento(Memento m)
        { 
            this.setState(m.getState()); 
        } 
    }
    //管理者
    class Caretaker
    { 
        private Memento memento;       
        public void setMemento(Memento m)
        { 
            memento=m; 
        }
        public Memento getMemento()
        { 
            return memento; 
        }
    }
    

    备忘录模式的主要优缺点

    主要优点如下。

    • 提供了一种可以恢复状态的机制。当用户需要时能够比较方便地将数据恢复到某个历史的状态。
    • 实现了内部状态的封装。除了创建它的发起人之外,其他对象都不能够访问这些状态信息。
    • 简化了发起人类。发起人不需要管理和保存其内部状态的各个备份,所有状态信息都保存在备忘录中,并由管理者进行管理,这符合单一职责原则。

    主要缺点是:资源消耗大。如果要保存的内部状态信息过多或者特别频繁,将会占用比较大的内存资源。

    备忘录模式的主要应用场景

    1. 需要保存与恢复数据的场景,如玩游戏时的中间结果的存档功能。
    2. 需要提供一个可回滚操作的场景,如 Word、记事本、Photoshop,Eclipse 等软件在编辑时按 Ctrl+Z 组合键,还有数据库中事务操作。

    备忘录模式的实例

    7. 观察者模式5

    观察者(Observer)模式的定义:指多个对象间存在一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。这种模式有时又称作发布-订阅模式、模型-视图模式,它是对象行为型模式。

    类图:
    在这里插入图片描述

    观察者模式的主要优缺点

    观察者模式是一种对象行为型模式,其主要优点如下。

    1. 降低了目标与观察者之间的耦合关系,两者之间是抽象耦合关系。
    2. 目标与观察者之间建立了一套触发机制。

    它的主要缺点如下。

    1. 目标与观察者之间的依赖关系并没有完全解除,而且有可能出现循环引用。
    2. 当观察者对象很多时,通知的发布会花费很多时间,影响程序的效率。

    观察者模式的主要应用场景

    通过前面的分析与应用实例可知观察者模式适合以下几种情形。

    1. 对象间存在一对多关系,一个对象的状态发生改变会影响其他对象。
    2. 当一个抽象模型有两个方面,其中一个方面依赖于另一方面时,可将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。

    观察者模式的实例

    在JDK的java.util包中,提供了Observable类以及Observer接口,它们构成了Java语言对观察者模式的支持。

    1. Observable类

    Observable 类是抽象目标类,它有一个 Vector 向量,用于保存所有要通知的观察者对象,下面来介绍它最重要的 3 个方法。

    1. void addObserver(Observer o) 方法:用于将新的观察者对象添加到向量中。
    2. void notifyObservers(Object arg) 方法:调用向量中的所有观察者对象的 update。方法,通知它们数据发生改变。通常越晚加入向量的观察者越先得到通知。
    3. void setChange() 方法:用来设置一个 boolean 类型的内部标志位,注明目标对象发生了变化。当它为真时,notifyObservers() 才会通知观察者。

    2. Observer 接口

    Observer 接口是抽象观察者,它监视目标对象的变化,当目标对象发生变化时,观察者得到通知,并调用 void update(Observable o,Object arg) 方法,进行相应的工作。

    图片引用自:http://c.biancheng.net/view/1390.html

    8. 状态模式3

    状态(State)模式的定义:对有状态的对象,把复杂的“判断逻辑”提取到不同的状态对象中,允许状态对象在其内部状态发生改变时改变其行为。

    类图:

    状态模式类图

    状态模式的主要优缺点

    状态模式是一种对象行为型模式,其主要优点如下。

    1. 状态模式将与特定状态相关的行为局部化到一个状态中,并且将不同状态的行为分割开来,满足“单一职责原则”。
    2. 减少对象间的相互依赖。将不同的状态引入独立的对象中会使得状态转换变得更加明确,且减少对象间的相互依赖。
    3. 有利于程序的扩展。通过定义新的子类很容易地增加新的状态和转换。
    4. 允许状态转换逻辑与状态对象合成一体,而不是某一个巨大的条件语句块。

    状态模式的主要缺点如下:

    1. 状态模式的使用必然会增加系统的类与对象的个数。
    2. 状态模式的结构与实现都较为复杂,如果使用不当会导致程序结构和代码的混乱。
    3. 状态模式对“开闭原则”的支持并不太好,对于可以切换状态的状态模式,增加新的状态类需要修改那些负责状态转换的源代码,否则无法切换到新增状态;而且修改某个状态类的行为也需修改对应类的源代码。

    状态模式的主要应用场景

    通常在以下情况下可以考虑使用状态模式。

    • 当一个对象的行为取决于它的状态,并且它必须在运行时根据状态改变它的行为时,就可以考虑使用状态模式。
    • 一个操作中含有庞大的分支结构,并且这些分支决定于对象的状态时。

    状态模式的实例

    状态模式在工作流或游戏等类型的软件中得以广泛使用,甚至可以用于这些系统的核心功能设计,如在政府OA办公系统中,一个批文的状态有多种:尚未办理;正在办理;正在批示;正在审核;已经完成等各种状态,而且批文状态不同时对批文的操作也有所差异。使用状态模式可以描述工作流对象(如批文)的状态转换以及不同状态下它所具有的行为。

    9. 策略模式4

    策略(Strategy)模式的定义:该模式定义了一系列算法,并将每个算法封装起来,使它们可以相互替换,且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式,它通过对算法进行封装,把使用算法的责任和算法的实现分割开来,并委派给不同的对象对这些算法进行管理。

    类图:
    策略模式

    策略模式的主要优缺点

    策略模式的主要优点如下。

    1. 多重条件语句不易维护,而使用策略模式可以避免使用多重条件语句。
    2. 策略模式提供了一系列的可供重用的算法族,恰当使用继承可以把算法族的公共代码转移到父类里面,从而避免重复的代码。
    3. 策略模式可以提供相同行为的不同实现,客户可以根据不同时间或空间要求选择不同的。
    4. 策略模式提供了对开闭原则的完美支持,可以在不修改原代码的情况下,灵活增加新算法。
    5. 策略模式把算法的使用放到环境类中,而算法的实现移到具体策略类中,实现了二者的分离。

    其主要缺点如下。

    1. 客户端必须理解所有策略算法的区别,以便适时选择恰当的算法类。
    2. 策略模式造成很多的策略类。

    策略模式的主要应用场景

    策略模式在很多地方用到,如 Java SE 中的容器布局管理就是一个典型的实例,Java SE 中的每个容器都存在多种布局供用户选择。在程序设计中,通常在以下几种情况中使用策略模式较多。

    1. 一个系统需要动态地在几种算法中选择一种时,可将每个算法封装到策略类中。
    2. 一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的形式出现,可将每个条件分支移入它们各自的策略类中以代替这些条件语句。
    3. 系统中各算法彼此完全独立,且要求对客户隐藏具体算法的实现细节时。
    4. 系统要求使用算法的客户不应该知道其操作的数据时,可使用策略模式来隐藏与算法相关的数据结构
    5. 多个类只区别在表现行为不同,可以使用策略模式,在运行时动态选择具体要执行的行为。
    6. 如果系统中某个类的对象存在多种状态,不同状态下行为有差异,而且这些状态之间可以发生转换时使用状态模式;如果系统中某个类的某一行为存在多种实现方式,而且这些实现方式可以互换时使用策略模式。

    策略模式的实例

    10. 模板方法模式3

    模板方法(Template Method)模式的定义如下:定义一个操作中的算法骨架,而将算法的一些步骤延迟到子类中,使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。它是一种类行为型模式。

    类图:
    在这里插入图片描述

    模版方法模式的主要优缺点

    该模式的主要优点如下。

    1. 它封装了不变部分,扩展可变部分。它把认为是不变部分的算法封装到父类中实现,而把可变部分算法由子类继承实现,便于子类继续扩展。
    2. 它在父类中提取了公共的部分代码,便于代码复用。
    3. 部分方法是由子类实现的,因此子类可以通过扩展方式增加相应的功能,符合开闭原则。

    该模式的主要缺点如下。

    1. 对每个不同的实现都需要定义一个子类,这会导致类的个数增加,系统更加庞大,设计也更加抽象。
    2. 父类中的抽象方法由子类实现,子类执行的结果会影响父类的结果,这导致一种反向的控制结构,它提高了代码阅读的难度。

    模版方法模式的主要应用场景

    模板方法模式通常适用于以下场景。

    1. 算法的整体步骤很固定,但其中个别部分易变时,这时候可以使用模板方法模式,将容易变的部分抽象出来,供子类实现。
    2. 当多个子类存在公共的行为时,可以将其提取出来并集中到一个公共父类中以避免代码重复。首先,要识别现有代码中的不同之处,并且将不同之处分离为新的操作。最后,用一个调用这些新的操作的模板方法来替换这些不同的代码。
    3. 当需要控制子类的扩展时,模板方法只在特定点调用钩子操作,这样就只允许在这些点进行扩展。

    模版方法模式的实例

    11. 访问者模式1TODO

    FAQ

    1. 关于为什么使用工厂模式,而不是直接new

    目前我的理解主要由两点:

    1. 降低代码复杂度:工厂模式下,**不仅仅只有实例化功能,**可以对new的对象进行一些其他操作,比如工厂类创建的圆形,可以添加一些额外的设置,圆的名称,圆的颜色等(这里只是简单举例,有些可能涉及复杂的操作,比如计算设置圆的周长,面积):组合优先于继承相比于继承,我们更优先使用组合——对于组合的好处,可以参考“状态模式(State Pattern)”,一个类可能需要非常多的组件,工厂模式可以降低使用者的代码复杂度和理解难度
    2. 根据DP(迪米特法则)其实调用者并不知道有一个Circle类的存在,他只需要知道这个IShape接口可以计算圆面积,而不需要知道;圆这个类到底是什么类名——他只知道给定一个”circle"字符串的参数,IShape接口可以自动计算圆的面积就可以了!

    2. 抽象工厂模式和工厂模式的区别

    1. 抽象工厂模式与工厂方法模式最大的区别在于,工厂方法模式针对的是一个产品等级结构,而抽象工厂模式则需要面对多个产品等级结构。
    展开全文
  • 1、 原型模式实现机制原型模式在设计模式中相对比较简单,它直接通过实现 Cloneable接口,再重写 clone()方法返回想要的对象就OK 了。一起来看下代码 :public class ProtoType implements Cloneable {public ...

    1、 原型模式实现机制

    原型模式在设计模式中相对比较简单,它直接通过实现 Cloneable接口,再重写 clone()方法返回想要的对象就OK 了。

    一起来看下代码 :

    public class ProtoType implements Cloneable {

    public ProtoType(){

    System.out.println("new ");

    }

    /**

    * 重写clone

    * @return

    * @throws CloneNotSupportedException

    */

    @Override

    protected Object clone() throws CloneNotSupportedException {

    System.out.println("clone");

    return (ProtoType)super.clone();

    }

    //测试 : 依次打印 new clone

    public static void main(String[] args) throws CloneNotSupportedException {

    //通过new 方式

    ProtoType protoType = new ProtoType();

    //通过clone方式,注意不走构造函数

    ProtoType protoType2 =(ProtoType) protoType.clone();

    // false 两个对象是不同引用

    System.out.println(protoType ==protoType2);

    }

    }

    可以看到,我们需要多少对象,直接调用clone()克隆即可。

    2、优缺点分析

    优点: 它是在运行时操作对象,操作的是内存中的二进制流,在创建大对象时,相比 new 一个对象,性能优势明显。

    缺点:必须实现Cloneable接口

    3、使用场景

    希望以一个对象为原型,创建其他近似的对象的时候;

    代码优化场景, 业务中用的比较少,一般很少单独使用,会结合工厂方法模式使用;

    多个调用者使用时,并且需要修改对象中的值,可以考虑原型模式来提供对象;

    ok,很简单吧🤙🤙🤙

    展开全文
  • 文章转自:http://www.tools138.com/create/article/20150929/020009847.html ... 单利模式优缺点和使用场景首先介绍一下单例模式: 单例模式(Singleton),也叫单子模式,是一种常用的软件设计模...

     

     

    文章转自:http://www.tools138.com/create/article/20150929/020009847.html

                 :http://www.cnblogs.com/damsoft/p/6105122.html

    单利模式的优缺点和使用场景 

    首先介绍一下单例模式: 
        单例模式(Singleton),也叫单子模式,是一种常用的软件设计模式。在应用这个模式时,单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个的全局对象,这样有利于我们协调系统整体的行为。比如在某个服务器程序中,该服务器的配置信息存放在一个文件中,这些配置数据由一个单例对象统一读取,然后服务进程中的其他对象再通过这个单例对象获取这些配置信息。这种方式简化了在复杂环境下的配置管理。 

    实现单例模式的思路是: 
        一个类能返回对象一个引用(永远是同一个)和一个获得该实例的方法(必须是静态方法,通常使用getInstance这个名 称);当我们调用这个方法时,如果类持有的引用不为空就返回这个引用,如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用;同时我们 还将该类的构造函数定义为私有方法,这样其他处的代码就无法通过调用该类的构造函数来实例化该类的对象,只有通过该类提供的静态方法来得到该类的唯一实例。 

    需要注意的地方: 
        单例模式在多线程的 应用场合下必须小心使用。如果当唯一实例尚未创建时,有两个线程同时调用创建方法,那么它们同时没有检测到唯一实例的存在,从而同时各自创建了一个实例, 这样就有两个实例被构造出来,从而违反了单例模式中实例唯一的原则。 解决这个问题的办法是为指示类是否已经实例化的变量提供一个互斥锁(虽然这样会降低效率)。 

    优点: 
        1.在单例模式中,活动的单例只有一个实例,对单例类的所有实例化得到的都是相同的一个实例。这样就 防止其它对象对自己的实例化,确保所有的对象都访问一个实例 
        2.单例模式具有一定的伸缩性,类自己来控制实例化进程,类就在改变实例化进程上有相应的伸缩性。 
        3.提供了对唯一实例的受控访问。 
        4.由于在系统内存中只存在一个对象,因此可以 节约系统资源,当 需要频繁创建和销毁的对象时单例模式无疑可以提高系统的性能。 
        5.允许可变数目的实例。 
        6.避免对共享资源的多重占用。 
    缺点: 
        1.不适用于变化的对象,如果同一类型的对象总是要在不同的用例场景发生变化,单例就会引起数据的错误,不能保存彼此的状态。 
        2.由于单利模式中没有抽象层,因此单例类的扩展有很大的困难。 
        3.单例类的职责过重,在一定程度上违背了“单一职责原则”。 
        4.滥用单例将带来一些负面问题,如为了节省资源将数据库连接池对象设计为的单例类,可能会导致共享连接池对象的程序过多而出现连接池溢出;如果实例化的对象长时间不被利用,系统会认为是垃圾而被回收,这将导致对象状态的丢失。 
    使用注意事项: 
        1.使用时不能用反射模式创建单例,否则会实例化一个新的对象 
        2.使用懒单例模式时注意线程安全问题 
        3.饿单例模式和懒单例模式构造方法都是私有的,因而是不能被继承的,有些单例模式可以被继承(如登记式模式) 
    适用场景: 
        单例模式只允许创建一个对象,因此节省内存,加快对象访问速度,因此对象需要被公用的场合适合使用,如多个模块使用同一个数据源连接对象等等。如: 
        1.需要频繁实例化然后销毁的对象。 
        2.创建对象时耗时过多或者耗资源过多,但又经常用到的对象。 
        3.有状态的工具类对象。 
        4.频繁访问数据库或文件的对象。 
    以下都是单例模式的经典使用场景: 
        1.资源共享的情况下,避免由于资源操作时导致的性能或损耗等。如上述中的日志文件,应用配置。 
        2.控制资源的情况下,方便资源之间的互相通信。如线程池等。 
    应用场景举例: 
        1.外部资源:每台计算机有若干个打印机,但只能有一个PrinterSpooler,以避免两个打印作业同时输出到打印机。内部资源:大多数软件都有一个(或多个)属性文件存放系统配置,这样的系统应该有一个对象管理这些属性文件 
        2. Windows的Task Manager(任务管理器)就是很典型的单例模式(这个很熟悉吧),想想看,是不是呢,你能打开两个windows task manager吗? 不信你自己试试看哦~ 
        3. windows的Recycle Bin(回收站)也是典型的单例应用。在整个系统运行过程中,回收站一直维护着仅有的一个实例。 
        4. 网站的计数器,一般也是采用单例模式实现,否则难以同步。 
        5. 应用程序的日志应用,一般都何用单例模式实现,这一般是由于共享的日志文件一直处于打开状态,因为只能有一个实例去操作,否则内容不好追加。 
        6. Web应用的配置对象的读取,一般也应用单例模式,这个是由于配置文件是共享的资源。 
        7. 数据库连接池的设计一般也是采用单例模式,因为数据库连接是一种数据库资源。数据库软件系统中使用数据库连接池,主要是节省打开或者关闭数据库连接所引起的效率损耗,这种效率上的损耗还是非常昂贵的,因为何用单例模式来维护,就可以大大降低这种损耗。 
        8. 多线程的线程池的设计一般也是采用单例模式,这是由于线程池要方便对池中的线程进行控制。 
        9. 操作系统的文件系统,也是大的单例模式实现的具体例子,一个操作系统只能有一个文件系统。 
        10. HttpApplication 也是单位例的典型应用。熟悉ASP.Net(IIS)的整个请求生命周期的人应该知道HttpApplication也是单例模式,所有的HttpModule都共享一个HttpApplication实例. 
       
    实现单利模式的原则和过程: 
        1.单例模式:确保一个类只有一个实例,自行实例化并向系统提供这个实例 
        2.单例模式分类:饿单例模式(类加载时实例化一个对象给自己的引用),懒单例模式(调用取得实例的方法如getInstance时才会实例化对象)(java中饿单例模式性能优于懒单例模式,c++中一般使用懒单例模式) 
        3.单例模式要素: 
            a.私有构造方法 
            b.私有静态引用指向自己实例 
            c.以自己实例为返回值的公有静态方法 

    1.饿汉式:单例实例在类装载时就构建,急切初始化。(预先加载法) 

    /**
    * 饿汉式(推荐)
    *
    */
    public class Test {
            private Test() {
            }
            public static Test instance = new Test();
            public Test getInstance() {
                    return instance;
            }
    }
    


    优点 
        1.线程安全 
        2.在类加载的同时已经创建好一个静态对象,调用时反应速度快 
    缺点 
        资源效率不高,可能getInstance()永远不会执行到,但执行该类的其他静态方法或者加载了该类(class.forName),那么这个实例仍然初始化 


    2.懒汉式:单例实例在第一次被使用时构建,延迟初始化。 

    class Test {
            private Test() {
            }
            public static Test instance = null;
            public static Test getInstance() {
                    if (instance == null) {
                  //多个线程判断instance都为null时,在执行new操作时多线程会出现重复情况
                            instance = new Singleton2();
                    }
                    return instance;
            }
    }


    优点: 
        避免了饿汉式的那种在没有用到的情况下创建事例,资源利用率高,不执行getInstance()就不会被实例,可以执行该类的其他静态方法。 
    缺点: 
        懒汉式在单个线程中没有问题,但多个线程同事访问的时候就可能同事创建多个实例,而且这多个实例不是同一个对象,虽然后面创建的实例会覆盖先创建的实例,但是还是会存在拿到不同对象的情况。解决这个问题的办法就是加锁synchonized,第一次加载时不够快,多线程使用不必要的同步开销大。 

    3.双重检测 

    class Test {
            private Test() {
            }
            public static Test instance = null;
    
            public static Test getInstance() {
                    if (instance == null) {
                            synchronized (Test.class) {
                                    if (instance == null) {
                                            instance = new Test();
                                    }
                            }
                    }
                    return instance;
            }
    }


    优点 
        资源利用率高,不执行getInstance()就不被实例,可以执行该类其他静态方法 
    缺点 
        第一次加载时反应不快,由于java内存模型一些原因偶尔失败 


    4.静态内部类 

    class Test {
            private Test() {
            }
    
            private static class SingletonHelp {
                    static Test instance = new Test();
            }
    
            public static Test getInstance() {
                    return SingletonHelp.instance;
            }
    }


    优点 
        资源利用率高,不执行getInstance()不被实例,可以执行该类其他静态方法 
    缺点 
        第一次加载时反应不够快 

    总结: 
        一般采用饿汉式,若对资源十分在意可以采用静态内部类,不建议采用懒汉式及双重检测 

     转载请注明出处: http://renyuan-1991.iteye.com/admin/blogs/2246557 

    转载于:https://www.cnblogs.com/up-farm/p/7637425.html

    展开全文
  • 工厂方法是最常用的设计模式之一,很多开源框架和API类库的核心模式。 优点:  1、用户只需要关心所需产品对应的工厂,无需关心创建细节,甚至无需知道具体产品类名;  2、所有的具体工厂类都具有同一抽象父类...
  • 创建型#简单工厂模式 概述:  简单工厂模式提供了工厂类用于创建对象,将对象的创建和对象的使用分开;...缺点:  1、职责过重,一旦程序出错,整个系统都不能运行;  2、引入新的工厂,会导致增加了...
  • 创建型#抽象工厂模式 ... 2、当一个产品族中的多个对象被设计成一起工作时,它能够保证客户端始终只使用同一产品族中的对象;  3、增加新的产品族很方便,无需修改已有系统代码,符合开闭原则; 缺...
  • 什么是设计模式 这个问题我问过的面试者不下数十次,回答五花八门,在我看来,模式就是经验,涉及模式就是涉及经验,有了这些经验,我们就能在特定情况下使用特定的设计、组合设计。这样可以大大节省我们的设计时间...
  • 单例设计模式优缺点 设计思想 举例表示
  • 设计模式及其优缺点

    千次阅读 2018-06-29 16:31:10
    设计模式 1.单例模式: 实现方式: a) 将被实现的类的构造方法设计成private的。 b) 添加此类引用的静态成员变量,并为其实例化。 c) 在被实现的类中提供公共的CreateInstance函数,返回实例化的此类,就是b...
  • singleton设计模式by Navdeep ... 让我们研究一下Singleton设计模式优缺点 (Let’s examine the pros and cons of the Singleton design pattern) Design patterns are conceptual tools for solving complex soft...
  • 主要介绍了C++设计模式编程中策略模式的优缺点及实现,文中讨论了策略模式中设计抽象接口的继承和组合之间的区别,需要的朋友可以参考下
  • 缺点:一是如果需要生产的产品过多,此模式会导致工厂类过于庞大,承担过多的职责,变成超级类; ​ 二是当生成新产品时,必须在工厂类中添加新的分支。这违背了开闭原则 工厂方法模式 工厂方法模式就是将简单工厂的...
  • 比较几种创建型模式优缺点,仔细考察这几种模式的区别和相关性。    第一类是工厂模式,工厂模式专门负责将大量有共同接口的类实例化。工厂模式可以动态决定将哪一个类实例化,不必事先知道每次要实例化哪一个...
  • 原型模式是一个创建型的模式。用原型实例指定创建对象的种类,并且通过拷贝这些原型,创建新的对象。原型模式多用于创建复杂的或者构造耗时的实例,因为这种情况下,复制一个已经存在的实例可使程序运行更高效。原型...
  • 设计模式优缺点(二)

    热门讨论 2018-02-06 09:37:01
    前言上篇博客描述的是创建型模式和结构型模式中的模式优缺点及适用场景,接下来就再学习一下行为型模式模式优缺点和适用场景吧。正文1. 观察者模式优点:松耦合,使各自的变化不会影响另一边的变化 缺点:不...
  • 各位小伙伴好,今天给大家主要介绍一下简单工厂模式、工厂模式和抽象工厂模式的区别及各自的优缺点。(本文实现语言为Python3)【前言】 众所周知今天所讲的内容是设计模式的一类;对于设计模式这个概念,我想首先请...
  • 设计模式-单例设计模式 应用场景及优缺点,扩展,多种写法 设计模式就是对未知变化的一种封装方式: 主要的设计原则:1.单一职责原则(这个基本扯淡,实际开发中尽量吧);2.开闭原则;3.里氏替换原则;4.迪米特法则;5.接口...
  • MVC设计模式优缺点

    2019-09-28 12:58:26
    1)优点: 各司其职、互不干涉; 有利于开发中的分工;...2)缺点: 系统结构和实现复杂; 视图与控制器过于紧密; 不适用于小型甚至中型应用程序; 转载于:https://www.cnblogs.com/yuzc/p/8798376.html...
  • 什么是单例设计模式? 单例模式,是一种常用的软件设计模式。它的核心思想是指,一个类只允许产生一个实例化对象。 单例设计模式实现要求: 1、构造方法私有化,保证在类的外部不能通过使用new关键字来实例化对象 2...
  • 单例模式(Singleton),也叫单子模式,是一种常用的软件设计模式。在应用这个模式时,单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个全局对象,这样有利于我们协调系统整体的行为。 比如在...
  • 转载请注明出处:http://blog.csdn.net/woshizisezise/article/details/50358924单例模式是运用频率很高的模式,但是,由于在客户端通常没有...1.Double Check Lock(DCL)实现单例DCL方式实现单例模式的优点是既能够在需
  • 1、单例(Singleton)模式:某个类只能生成一个实例,该类提供了一个全局访问点供外部获取该实例,其拓展是有限多例模式。 2、原型(Prototype)模式:将一个对象作为原型,通过对其进行复制而克隆出多个和原型类似...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,529
精华内容 1,811
关键字:

设计模式优缺点