携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第26天,点击查看活动详情
1.目录:
- 单例模式(Singleton Pattern)
- 工厂方法模式(Factory Method Pattern)
- 抽象工厂模式(Abstract Factory)
- 构造器模式(Builder Pattern)建造者模式
- 原型模式(Prototype Pattern)
延伸模式“简单工厂模式(Simple Factory Pattern)”
2.总结:
创建型模式,就是用来创建对象的模式,抽象了实例化的过程。它帮助了一个系统独立于如何创建、组合和表示它的那些对象
3.所有的创建型模式都有两个主题:
- 第一,它们都将系统使用哪些具体类的信息封装起来
- 第二,它们隐藏了这些类的实例是如何被创建和组织的。外界对于这些对象只知道它们共同的接口,而不清楚其具体的实现细节。正因如此,创建型模式在创建什么(what),由谁(who)来创建,以及何时(when)创建这些方面,都为软件设计者提供了尽可能大的灵活性。
4.创建型模式的作用可以概括为如下三点:
- 封装创建逻辑,绝不仅仅是new一个对象那么简单。
- 封装创建逻辑变化,客户代码尽量不修改,或尽量少修改。
- 使用创建模式是为了提高代码的可维护性(即应对未来修改的能力)。
5.为什么需要创建型模式:
- 系统的演化应当依赖于组合,而不是继承;这就提出了将类的实例化委托给一个对象的要求,因此创建型模式将变的越来越重要。
- 创建型模式属于对象创建型。所谓对象创建模型就是说将实例化的工作委托给另一个对象来做。与之相对应的是类创建模型,这事一种通过继承改变被实例化的类。
6.创建型模式两个重要的特点:
- 客户不知道创建的具体类是什么(除非看源代码)
- 隐藏了类的实例是如何被创建的
7.常见的五种创建型模式:
- 单例模式(Singleton Pattern)解决的是实体对象的个数问题,其他的都是解决new所带来的耦合关系问题。
- 工厂方法模式(Factory Pattern)在工厂方法中,工厂类成为了抽象类,其实际的创建工作将由其具体子类来完成。工厂方法的用意是定义一个创建产品对象的工厂接口,将实际创建工作推迟到子类中去,强调的是“单个对象”的变化。
- 抽象工厂模式(Abstract Factory)抽象工厂是所有工厂模式中最为抽象和最具有一般性的一种形态。抽象工厂方法可以向客户提供一个接口,使得客户可以在不必指定产品的具体类型的情况下,创建多个产品族中的产品对象,强调的是“系列对象”的变化。
- 构造器模式(Builder Pattern)把构造对象实例的逻辑移到了类的外部,在这个类的外部定义了这个类的构造逻辑。它把一个复杂对象的构造过程从对象的表示中分离出来。其直接效果是将一个复杂的对象简化为一个比较简单的目标对象。它强调的是产品的构造过程。
- 原型模式(Prototype Pattern)和工厂模式一样,同样对客户隐藏了对象创建工作,但是,与通过对一个类进行实例化来构造新对象不同的是,原型模式是通过拷贝一个现有对象生成新对象的。
8.抽象工厂模式:
- 意图:提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们的具体的类
- 使用场景:
- 一个系统要独立于它的产品的创建、组合和表示时
- 一个系统要由多个产品系列中的一个来配置时
- 当你要强调一系列相关的产品对象的设计以便进行联合使用时
- 当你提供一个产品类库,而只想显示它们的接口而不是实现时
9.抽象工厂模式效果:
1. 分离了具体的类,通过抽象接口将客户与具体的类分离
2. 易于交换产品系列
3. 有利于产品的一致性
10.构造器模式:
- 意图:将一个复杂对象的构造与它的表示相分离,使得同样的构建过程可以创建不同的表示(或者说产品)
- 使用场景:
- 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时
- 当构造过程必须允许被构造的对象有不同的表示时
- 效果:
- 可以使你改变一个对象的内部表示
- 构造代码和表示代码分开
- 可以构造过程进行更精细的控制
11.工厂方法模式:
- 意图:定义一个用于创建对象的接口,让子类决定实例化具体哪一个类。
- 使用场景:
- 当一个类不知道它所必须创建的对象的类的时候,让子类来决定
- 当一个类希望由它的子类来决定所创建的对象的时候
- 效果:
- 为子类提供回调函数
- 连接平行的类层次
- 创建函数可以接收参数来决定创建什么产品
12.原型模式:
- 意图:通过原型实例指定创建对象的种类,并通过拷贝这些原型来创建新的对象
- 适用场景:
- 要实例化的类是运行时刻指定的,比如动态装载
- 为了避免创建一个与产品层次平行的工厂类层次
- 当一个类的实例只能有几个不同的状态组合中的一种时,建立相应数目的原型并克隆它们可能比每次用合适的状态手工化该类更方便一些
- 效果:
- 运行时动态增加或者删除产品
- 减少子类的构造数目
- 用类动态配置应用
- 动态指定新的对象,通过改变结构或者值
- 缺陷在于每一个Prototype的子类都需要实现clone操作
无论java还是C#都从语言层次内置了对prototype模式的支持。具体不在详述。
13.对简单工厂模式的进一步阐述:
在GOF的设计模式中并没有简单工厂,而是将其作为工厂方法的一个特例加以解释的。可以这样理解,简单工厂是参数化的工厂方法。简单工厂的作用是实例化对象,而不需要客户了解这个对象属于那个具体子类。
- 优点:可以使用户根据参数获得对象的类的实例,避免了用户直接实例化类,降低了耦合性。
- 缺点:可实例化的类型在编译期间已绑定,如果新增新类型,则需要修改工厂。简单工厂需要知道所有要生成的类型,当子类过多或者子类层次过多时不适合使用。
14.对工厂方法模式的进一步阐述:
当一个类不知道它所必须创建对象的的类或一个类希望有子类指定它所创建的类型时(也就是说一个类中的某个对象需要由子类来创建时),可以使用工厂方法模式。
- 优点:工厂方法使类中的代码不依赖于它必须创建的类,代码只知道要创建类的接口。
- 缺点:新增加一个需要创建的类就需要增加一个相应的子类。工厂方法与工厂对象不同,工厂对象的作用是专门负责其他类的实例化,如抽象工厂的对象或者简单工厂的对象,即实例化对象是工厂对象的唯一职责,而工厂方法所存在的类则不同,只有工厂方法负责实例化相关类型的实例。除此之外,这个类的对象还具有其他职责,也就是说出了工厂方法外,还有其他方法。
15.对抽象工厂模式的进一步阐述:
工厂方法针对的仅仅是一种“产品”,或者称为“类”,而抽象工厂实际上针对很多平行的产品,因此层次不同。抽象工厂才是名副其实的“工厂”,即不仅仅只生产一种产品,抽象工厂是层次较高的模式,针对应用中需要使用的一系列相关的类给出一个创建接口。抽象工厂分离了具体的类:
- 使产品系列容易交换,只要更换相应的具体工厂即可(经常用工厂方法来实现);
- 有利于产品的一致性,由抽象工厂创建的产品必须符合相同的接口,任何在子类中的特殊功能都不能体现在同一的接口中;
- 难以支持新产品的类型,如果抽象工厂的基类要发生变换,那么针对每个产品的具体工厂也都要发生变化,显然这是比较麻烦的。
16.桥接模式的效果:
- 桥接模式可以保持客户端程序的接口不变,而允许读者修改显示类或要使用的类。这可以防止重新编译一系列复杂的用户接口模块,而只需要重新编译Bridge和实际的最终显示类。
- 可以分别扩展实现类和Bridge类,二者之间通常不会有相互作用。
- 对客户端程序很容易隐藏实现细节。
17.总结:
使用创建型模式是为了提高系统的可维护性和可扩展性,提高应对需求变化的能力!