《敏捷软件开发》学习笔记（三）

一、Null Object 模式（空对象模式）

        我们在开发系统的过程中，可能经常需要对某些接口返回的对象进行判空检查，如果不为空，然后调用相关的方法（获取值或者是执行默写操作），完成某种逻辑。然而，这样的代码在系统中出现很多次时，就不是一个好现象。为了解决这个问题，我们可以引入空对象（Null Object）。

        空对象（Null Object）模式有助于消除对这种判空检查的需要，从而简化代码结构。由于消除了对判空的检查，因此在某些情况下，能够提升程序效率。

类结构图：

       当然，这种设计模式最主要是消除了一些if判断语句，提高了代码可读性，使得设计更加具有OO的味道。感觉并没有什么实际用途似的，因此难免有些人觉得其被称为设计模式是否有大题小做之嫌。呵呵，理解不多，不加评论。不过这种模式我在实际编码中，还真很少刻意的去重构趋向之，可能是我们已经习惯了OO中夹杂些过程式代码。真所谓”入鲍鱼之肆，久闻而不知其臭“吧。

二、单例模式（Singleton）和 单状态模式（monostate）

这里主要比较一下这两种设计模式的优缺点和异同：

 SingletonMonostate意图单例模式强调某类只能有一个实例。不管这些对象是什么，只要创建了多份，就是严重的逻辑错误。单态模式则强调某类的所有实例始终具有相同的状态，即这些实例属于不同的对象（在C++中其地址/内存块不同），但是这些实例具有相同的状态。实现单例模式的实现通常是通过为类定义静态成员函数instance() 和静态成员变量，并提供私有的构造函数（防止被外部实例化）。单态模式则提供了公有的构造函数和非静态公有成员函数，但是其保存状态的成员数据都是静态的。从而保证了其所有的实例都具有相同的状态。优点适用于任何类
延迟求值透明性
可派生
多态性代价推毁方法未定义
效率问题
不透明性效率问题（多次的创建和推毁开销）
内存占用   

三、外观模式（Facade）

       Facade模式主要用于想要为一组具有复杂且全面的接口的对象（子系统）提供一个简单且特定的接口。从而使得客户端调用代码不用关心这个子系统的细节，只需要与facade类打交道就可以了。

       例如，可以为java.sql包提供一个访问数据库的DB类，DB类就是一个facade。DB类使得应用程序类不需要了解java.sql包的内部细节。它把java.sql包的所有全面性和复杂性隐藏在一个非常简单且特定的接口后面。当然，DB这样的Facade类对java.sql包的使用施加了许多策略；也对应用程序调用类的使用施加了它的策略。基于约定，DB类成为了java.sql包的唯一代理。

      这是迪米特法则（Law of Demeter）的一个典型应用。

四、中介者模式（Mediator）

        中介者模式定义：用一个中介者对象来封装一系列（两个或更多）对象之间的交互（更新）。这个中介者对象的引入使得这一系列对象之间不再需要相互知晓对方了，而是都通过这个中介者对象来传话以达到沟通的目的。这也是迪米特法则（Law of Demeter）的一个典型应用。

        外观（facade）模式和中介者（mediator）模式的区别：

       外观模式和中介者模式都是迪米特法则的一个体现，目的是降低类或模块之间的耦合，使它们都可以独立的变化，已达到灵活可维护的目的。但是facade模式和mediator模式也有本质的区别：

1）外观模式是应用程序类与子系统（或一组复杂类）的沟通渠道，它相对来说比较倾向于应用程序类。目的是让应用程序类更好的访问该子系统（一组复杂类）。

2）但是中介者模式相对来说只是两个或多个类之间的沟通桥梁，没有任何倾向性，对于中介者来说，每个类的地位都是平等的。

3）外观模式主要用于封装一个复杂的第三方库（子系统），方便应用程序的调用；而中介者模式主要用于这些对象不方面或不能直接联系的情形。

五、模板方法模式（Template Method）

       先介绍一概念——基于差异编程（prograam by difference）：对于某一个满足了我们大部分需要的类，可以创建一个它的子类，并只改变其中我们不期望的部分。这常常是通过多态来实现的。

       模板方法（Template Method）模式：在（抽象）基类中定义一个算法的通用步骤，并把其中可能有变化的步骤留到其子类中去实现。模板方法模式使得代码具有良好的可扩展性，并最大程度的去掉了重复。它是开闭原则（OCP）、依赖倒置原则（DIP）、好莱坞法则（Hollywood Principle）、不要重复你自己（DRY）等原则的应用。

      模板方法（Template Method）模式其实是一种很简单的模式，我们在实际的编程中或多或少的都用到了。只不过你可能不知道它就是模板方法模式而已。

      但简单并不意味着不会犯错，由于模板方法模式是通过继承来达到重用的目的的，但继承是一种非常强的耦合关系，因此，该模式也经常的被误用。

      而策略（Strategy）模式则可以通过委托来封装变化，达到重用这种通用的算法结构。

六、策略模式（Strategy）

      策略（Strategy）模式定义：定义一个算法的抽象接口，而具体的算法实现留待子类中去实现。Context类持有一个抽象类型的变量（实际指向某一个具体的算法子类）。调用端（客户）代码可以通过依赖注入（是依赖注入吗？）将符合需要的合适的具体算法类设置给 Context类。

     粗略模式是开闭原则的一个应用。将”可变化的部分"封装起来，而变化的就是实现。

     附：“对扩展开放，对修改关闭”的理解——我们修改一个软件直接修改的就是实现,而非抽象(实际上也不应该也没有必要对抽象进行修改。如果你的工程存在对抽象的修改,那就只能说明,当初在定义抽象的时候压根定义的抽象就是不合理的抽象（即架构分析时概念出了问题）。真正合理的抽象将使用者客户和现有代码极大地解偶，这使得以后的修改工作只需在低端实现进行而无须触动高端)。——摘自《软件设计原则与设计模式问题》（http://dev.gameres.com/Program/Other/bcxszyforgameres/bcxszy/xisofts.sinaapp.com/@p=227.htm#i-5）

七、命令模式（Command）