您好，登录后才能下订单哦！
密码登录
登录注册
点击 登录注册 即表示同意《亿速云用户服务条款》
最近准备将23种设计模式用ruby和javascript两种语言分别实现，为什么要这么做
一.公司由于代码风格不统一造成的沟通问题而开展的全公司学设计模式。二.作为学习后笔记用。三.选择ruby和javascript是因为我现在主要使用这两门语言。四.作为体会各种模式的适用点。
为什么要学设计模式？这里谈谈自己对设计模式看法
一.设计模式本质就是屏蔽变化点。（很精辟的悟点，看设计模式最佳角度，感谢易博士）二.没有一种设计模式是万能的,所以谈论哪种设计模式最好是无用的，没有最好，只有刚刚好。（基于第一条）三.设计模式不是为了耍酷，而是为了方便和其他OOA程序员沟通而制定一个标准名词和标准动作。废话完成，进入正文
首先来看看我们UML
在软件系统中，经常面临着“某个对象”的创建工作，由于需求的变化，这个对象的具体实现经常面临着剧烈的变化， 但是它却拥有比较稳定的接口。如何应对这种变化？提供一种封装机制来隔离出“这个易变对象”的变化， 从而保持系统中“其它依赖该对象的对象”不随着需求的改变而改变？这就是要说的Factory Method模式了。
定义一个用户创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。
1.工厂类不再负责实例的具体过程，将变化的具体构造过程，交给子类来实现。 2.将到底实例哪个类，交给调用者来决定
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" endendvar 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.依赖继承链，太过复杂不好测试免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。