《敏捷软件开发读书笔记之二》
接下来，我将向大家介绍第三部分“薪水支付案例研究”和第四部分“打包薪水支付系统”这两部分的认识，以及从中得到的收获：
以下是我从第三部分“薪水支付案例研究”中学到的相关知识以及个人的一些总结：
Command模式的简单性掩盖了它的多功能性，此模式可以应用于多种能够不同的美妙用途，范围涉及数据库事物操作，设备控制，多线程核心以及GUI的Do/Undo管理，此模式是在实际的软件开发中是非常有用的。
TEMPLATE METHOD模式和STRATEGY模式都可以用来分离高层的算法和低层的具体 实现细节。都允许高层的算法独立于它的具体实现细节重用。此外，STRATEGY模式也允许具体实现细节独立于高层的算法重用。
FACADE模式适用于范围广并且可见的策略，MEDLATOR模式则适用于隐蔽并且具有针对性的策略。Facdes通常是约定的关注点。Mediator则对用户是隐蔽的，它的策略是既成事实的而不是一项约定事物。
SINGLETON模式使用私有构造函数，一个静态变量，以及一个静态方法对实例化进行控制和限制。MONOSTATE模式只是简单的把对象的所有变量变成静态的。前者适用于透过派生去约束一个现存类，并且不介意他的所有调用者都必须要用instance（）方法来获取访问权；后者则比较适用于类的单一性本质对使用者透明，或者希望使用单一对象的多态派生对象。
使用NULL OBJECT模式可以确保函数总是返回有效的对象，即使失败时也如此。
会话的目的是发起思考活动，并为开发人员提供一个公共的，可以依据其展开工作的智力模型，而不是为了确定设计。
在“薪水支付系统设计”中使用了大量的抽象和多态，使得绝大部分的设计对于薪水支付系统策略的更改做到了封闭。在此过程中，很少考虑是否正在进行分析，设计或者实现。相反，全神贯注于清楚和封闭的问题，在任何可能的地方， 都在尽力找出潜在的抽象。
以下是我从第四部分“打包薪水支付系统”中得到的收获：
“包的设计原则”一章描述了依赖型管理度量可以测量一个设计与我认为“好”的依赖，抽象结构模式间的匹配程度，并且表明。依赖关系是有好坏之分的，该模式反映了此经验。然而，度量不是万能的，它只是一个取代随意标准的测量方法。但是不可否认的是也存在着其它比这种方法更好的度量分法。
“FACTORY模式”是较有效的工具，它使得高层策略模块在创建类的实例时无需依赖于这些类的具体实现。它们同样也使得在一组类的完全不同系列的实现间进行交换成为可能。然而，它会带来复杂性，这种复杂性通常是可以避免的，缺省地使用它们通常不是最好的做法。
“薪水支付案例研究”中揭露了：是否需要对包结构进行管理，取决于程序的规模以及开发团队的规模。即使小的团队，也要对源代码进行划分，以便于开发人员间可以互不干扰，如果没有某种形式的划分结构，大程序就会变成晦涩难懂的源文件堆积。