设计模式开篇和工厂方法模式

设计模式开篇和工厂方法模式

开篇之言

最近准备将23种设计模式用ruby和javascript两种语言分别实现，为什么要这么做

一.公司由于代码风格不统一造成的沟通问题而开展的全公司学设计模式。二.作为学习后笔记用。三.选择ruby和javascript是因为我现在主要使用这两门语言。四.作为体会各种模式的适用点。

设计模式用途

为什么要学设计模式？这里谈谈自己对设计模式看法

一.设计模式本质就是屏蔽变化点。（很精辟的悟点，看设计模式最佳角度，感谢易博士）二.没有一种设计模式是万能的,所以谈论哪种设计模式最好是无用的，没有最好，只有刚刚好。（基于第一条）三.设计模式不是为了耍酷，而是为了方便和其他OOA程序员沟通而制定一个标准名词和标准动作。

废话完成，进入正文

工厂方法（factory method）

首先来看看我们UML

概述

在软件系统中，经常面临着"某个对象"的创建工作，由于需求的变化，这个对象的具体实现经常面临着剧烈的变化， 但是它却拥有比较稳定的接口。如何应对这种变化？提供一种封装机制来隔离出"这个易变对象"的变化， 从而保持系统中"其它依赖该对象的对象"不随着需求的改变而改变？这就是要说的Factory Method模式了。

意图

定义一个用户创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。

屏蔽的变化点

1.工厂类不再负责实例的具体过程，将变化的具体构造过程，交给子类来实现。 2.将到底实例哪个类，交给调用者来决定

ruby的实现

class Car   def self.factory typeName      const_get(typeName).new #查询祖先链，如果查到返回这个静态值   endendclass BMW < Car  def drive      p "my it's BMW"  endendclass Benz < Car   def drive     p "my it's Benz"   endend

javascript实现

var car = car || {}car.BMW = function(){  console.log("my it's BMW")}car.Benz = function(){  console.log("my it's Benz")}car.factory= function(name){  var o = {}  o.method = car[name]  return o}

体会

工厂方法适合一下情景

1.具体方法没有定义或不无法定义，需要子类来实现。2.设计时不知道到底需要实例哪个子类。3.处理大量类似实例

缺点

1.依赖继承链，太过复杂不好测试