javascript 原型模式的工作原理 到 对象模式的探寻(下)

上篇文章中提到这篇将要对编程语言设计进行一些讨论,但是笔者在学习过程中发现,需要学习的知识太多,根本不是一篇blog能说清的。所以也只能暂时放下,有机会的话,会将学习笔记整理到blog上来。笔者目前也只是学习阶段,欢迎感兴趣的同学讨论。附上两本这方面的书籍供大家参考:

  1. 世界著名计算机教材精选:编译器构造
  2. 程序设计语言:实践之路(第3版)

第一本书主要讲一些编译原理,编译器编写的知识,第二本书则主要讲了怎样设计一门编程语言,包括类型系统,面对对象的封装继承等等知识。

好了,言归正传,这篇blog主要会总结一下设计模式中的创建型。主要来自于 《设计模式-可复用面向对象软件的基础》一书和guisu的BLOG

设计模式,描述了一个重复发生的问题,以及该问题的解决发难的核心。

常见的23种设计模式按照其目的来说主要分为三大类型:创建型,结构型,行为型。本文在这里只对创建型模式进行大概的总结和归纳。具体关于设计模式可以参考前面提到的BLOG专栏。另外设计模式主要在于实践,会用才算懂了。

随着分工越来越细,对象的创建和使用在设计过程中被独立开来。

创建型模式抽象了实例化过程,探讨了如何高效的创建对象。

创建型模式中也分为多种:

  • Factory Method(工厂方法)
  • Abstract Factory (抽象工厂)
  • Builder(生成器)
  • Prototype(原型)
  • Singleton(单例)

工厂方法
定义一个用于创建对象的接口,让子类决定将哪一个类实例化。Factory Method让一个类的实例化延迟到子类
Factory Method 中将工厂抽象成接口,让具体的工厂类实现这个接口,在具体的工厂类中去实例化产品。

工厂方法UML类图

抽象工厂
提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
Abstract Factory的出现主要是为了解决Factory Method中产品类型只有一种这个缺陷。如下图所示 Abstract Factory中可以有多个产品类型

抽象工厂UML类图

当然在这里需要注意的一点是 对于工厂模式的实现来说(不论是Factory Method 或 Abstract Factory),一般我们都会加上Reflection 机制。这样 对于客户端来说就不需要通过重复的代码来选择哪个具体的工厂,一切的选择都到了配置文件中,通过 IOC可以注入不同的工厂实例。

生成器

将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。Builder模式非常适合于以下情况:

  1. 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
  2. 当构造过程必须允许被构造的对象有不同的表示时。

通俗点讲,就是当一个产品或者说对象的构造过程可以抽象成几个步骤的时候,且面对不同的情况,每个步骤采取的方式又有可能不同的时候,采用Builder模式是非常有效的。

构造器模式UML类图

  • Builder:抽象生成器角色,这是一个抽象接口,定义了创建负责对象的各个组成部分的公共接口。这个接口应该足够普遍,以便具体的生成器能够通过实现这个抽象接口的不同方式和不同部分生成不同的产品。
  • ConcreateBuilder:具体生成器角色,继承并实现抽象生成器的接口,完成具体产品部件的建造。除此以外,具体生成器还需要额外提供一个检索产品的方法,以便指导者能在产品生成后获得它。这个方法通常包含的是复杂产品的装配逻辑。
  • Director:指导者角色,指导具体生成器来一步一步完成产品的创建。需要特别指出的是,指导者并不需要指导具体生成器生成的产品,它只需要了解如何使用生成器制造产品,制造出的产品的细节,只有具体生成器才知道。
  • Product:产品,被创建出来的复杂的产品。由 ConcreteBuilder创建这个复杂产品的内部表示并定义它的装配过程。通常,Product定义了它的组成部件的类,以及将这些部件装配成最终 产品的接口。一个系统中可能还有多个Product类,而且这些类之间不一定会有共同的接口,可以是完全互不相关的。

在这里Director在指导的时候会根据客户端来装配不同的ConcreateBuilder,当然我们也可以通过IOC及Reflection来进行配置装配,把所有需要修改代码才能解决的问题放到配置文件当中去。、
附: 对于Abstract Factory来说,Builder模式最大的不同就是,生成的Product不需要实现相同的接口,只需要有类似的构造过程即可。

原型
这也是这几篇文章的核心,Prototype模式。Portotype原理很简单,就是通过复制(克隆、拷贝)一个指定类型的对象来创建更多同类型的对象。这个指定的对象可被称为“原型”对象。运用场景如下:

  • 当一个系统应该独立于它的产品创建、构成和表示时。
  • 当要实例化的类是在运行时刻指定时,例如,通过动态装载;
  • 为了避免创建一个与产品类层次平行的工厂类层次时
  • 当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。

原型模式UML类图

如上图所示,Prototype的UML图也非常清晰的体现除了 clone 的概念。另,原型对象的clone 分为两种 一种是只clone 原型对象值类型成员和引用类型成员的引用,称为浅拷贝。另外一种是深拷贝,则需要将引用类型成员所引用的对象也clone一次。

附: 对于需要动态装载的产品来说,一般会加入Prototype Management 来控制动态的生成不同的clone对象。
原型模式UML类图

单例
单件模式保证应用只有一个全局惟一的实例,并且提供一个访问它的全局访问点。在下面的情况下使用singleton模式:

  • 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。
  • 当这个唯一实例应该是通过子类化可扩展的,并且客户应该无需更改代码就能使用一个扩展的实例时。

单例模式UML类图

如UML图所示,实现方法:

  • 私有构造函数防止在外部实例化。
  • 保存惟一实例的静态的私有变量。
  • 初始化并获得惟一实例的静态方法。

以上就是创建型模式的一些总结,笔者认为,设计模式的学习还是最好在实践中学习,在一些日常的项目中还是能使用很多设计模式的概念的,或者我们也可以通过学习一些成熟框架中的设计模式思想。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值