策略模式

策略模式定义了算法家族,分别封装起来,让他们之间可以相互替换,此模式让方法的变化不会影响到使用算法的客户

模式作用:

  1. 所有的这些算法都是做相同的事情,只是实现不同。
  2. 以相同的方式调用所有的方法,减少了各种算法类与使用算法类之间的耦合。
  3. 单独定义算法类,也方便了单元测试。

注意事项:

  1. 不仅可以封装算法,也可以用来封装几乎任何类型的规则,是要在分析过程中需要在不同时间应用不同的业务规则,就可以考虑是要策略模式来处理各种变化。
阅读全文 »

中介者模式

中介者模式(Mediator Pattern):定义一个中介对象来封装系列对象之间的交互。中介者使各个对象不需要显示地相互引用,从而使其耦合性松散,而且可以独立地改变他们之间的交互。
(注意:中介者模式和代理模式字面意思相近,但却是完全不同的模式)

模式作用:

  1. 在软件开发中,中介者是一个行为设计模式,通过提供一个统一的接口让系统不同部分进行通信.一般,如果系统有很多子模块需要直接沟通,都要创建一个中央控制点让其各模块通过中央控制点进行交互.中介者模式可以让这些子模块不需要直接沟通,从而达到进行解耦的目的.

注意事项:

  1. 当系统出现了多对多交互复杂的对象群时,先不急于使用中介者模式,而是思考一下是不是系统设计有问题.
阅读全文 »

按值传递 VS. 按引用传递

按值传递(call by value)是最常用的求值策略:函数的形参是被调用时所传实参的副本。修改形参的值并不会影响实参。

按引用传递(call by reference)时,函数的形参接收实参的隐式引用,而不再是副本。这意味着函数形参的值如果被修改,实参也会被修改。同时两者指向相同的值。

按引用传递会使函数调用的追踪更加困难,有时也会引起一些微妙的BUG。

按值传递由于每次都需要克隆副本,对一些复杂类型,性能较低。两种传值方式都有各自的问题。

阅读全文 »

原型模式

原型模式(prototype)是指原型实例指向对象的种类,并且通过拷贝这些原型创建新的对象

模式作用:

  1. 原型对象本身就是有效地利用了每个构造器创建的对象

注意事项:

  1. 注意的依然是浅拷贝和深拷贝的问题,免得出现引用问题
  2. 现有的文献里查看原型模式的定义,没有针对JavaScript的,你可能发现很多讲解的都是关于类的,但是现实情况是基于原型继承的JavaScript完全避免了类(class)的概念
    阅读全文 »

适配器模式

在计算机编程中,适配器模式(有时候也称包装样式或者包装)将一个类的接口适配成用户所期待的。一个适配允许通常因为接口不兼容而不能在一起工作的类工作在一起,做法是将类自己的接口包裹在一个已存在的类中。

模式作用:

  1. 使用一个已经存在的对象,但其方法与接口不符合你的要求
  2. 创建一个可复用的对象,该对象可以与其他不相关或不可见的对象协同工作
  3. 使用一个已经存在的一个或多个对象,但是不能进行继承已匹配它的接口

注意事项:

  1. 与代理模式的区别,代理模式是不改变原接口,适配模式是原接口不符合规范
    阅读全文 »

迭代器模式

迭代器模式(Iterator),提供一种方法顺序访问一个聚合对象中的各种元素,而又不暴露该对象的内部表示。

模式作用:

  1. 为遍历不同的集合结构提供一个统一的接口,从而支持同样的算法在不同的集合结构上进行操作
  2. 对于集合内部结果常常变化各异,我们不想暴露其内部结构的话,但又想让客户代码透明地访问其中的元素,这种情况下我们可以使用迭代器模式

注意事项:

  1. 一般的迭代,我们至少要有2个方法,hasNext()和Next(),这样才能做到遍历所有对象
  2. 遍历的同时更改迭代器所在的集合结构可能会导致问题(比如C#的foreach不允许修改item)
    阅读全文 »

外观模式

外观模式(Facade),为子系统中的一组接口提供一个一致的界面,定义一个高层接口,这个接口使得这一子系统更加容易使用。

模式作用:

  1. 在设计初期,应该有意识地将不同的两个层分离,比如经典的三层结构
  2. 在开发阶段,子系统往往因为不断的重构演化而变得越来越复杂,增加外观模式可以提供一个简单的接口,减少他们之间的依赖
  3. 在维护一个遗留的大型系统时,为系统开发一个外观Facade类,为设计粗糙和高度复杂的遗留代码一共比较清晰的接口,让新系统和Facade类对象交互

注意事项:

  1. 外观模式被开发者连续使用时会产生一定的性能问题,因为每次调用时都要检测功能的可用性(PS:可用函数的惰性加载来解决)
阅读全文 »

单例模式

单例模式是一种常用的软件设计模式。在它的核心结构中只包含一个被称为单例类的特殊类。通过单例模式可以保证系统中一个类只有一个实例而且该实例易于外界访问,从而方便对实例个数的控制并节约系统资源。如果希望在系统中某个类的对象只能存在一个,单例模式是最好的解决方案。

模式作用:

  1. 模块间通信
  2. 系统中某个类的对象只能存在一个
  3. 保护自己的属性和方法

注意事项:

  1. 注意this的使用
    阅读全文 »

命令模式

在软件系统中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合,比如要对行为进行“记录、撤销/重做、事务”等处理,这种无法抵御变化的紧耦合是不合适的。在这种情况下,如何将“行为请求者”与“行为实现者”解耦?将一组行为抽象为对象,实现二者之间的松耦合。这就是命令模式(Command Pattern)。

模式作用:

  1. 将函数的封装,请求,调用结合为一体
  2. 调用具体的函数解耦命令对象与接收对象
  3. 提高程序模块化的灵活性

注意事项:

  1. 不需要接口一致,直接调用函数即可,以免造成浪费
    阅读全文 »

工厂模式

工厂模式是我们最常用的实例化对象模式了,是用工厂方法代替new操作的一种模式。著名的Jive论坛 ,就大量使用了工厂模式,工厂模式在Java程序系统可以说是随处可见。因为工厂模式就相当于创建实例对象的new,我们经常要根据类Class生成实例对象,如var a=new A() 工厂模式也是用来创建实例对象的,所以以后new时就要多个心眼,是否可以考虑使用工厂模式,虽然这样做,可能多做一些工作,但会给你系统带来更大的可扩展性和尽量少的修改量

模式作用

  1. 对象的构建十分复杂
  2. 需要依赖具体的环境创建不同实例
  3. 处理大量具有相同属性的小对象

注意事项

  1. 不能滥用工厂,有时候仅仅是给代码增加复杂度
阅读全文 »