李嘉 (Justin)

摘要： 第14章 State模式 我们在开发软件时有时会遇到有限状态机（FSM），我们需要使用高效的方式来实现有限状态机。但是，在更多的时候，我们却忽视了有限状态机，忘记了使用FSM来对复杂的软件行为进行建模。实际上，FSM是软件宝库中最有用的抽象之一，它们提供了一个简单、优雅的方法去提示和定义复杂系统的行为。FSM同样也提供了一个易于理解、易于修改的有效实现策略。本章中学习的State模式正是研究如何优... 阅读全文

摘要： 第13章 Factory模式族 13.1 为什么需要Factory？ 在前面的几章中，我们已经学习了几种常用的设计模式。我们不难发现，设计模式的一个核心思想就是：努力实现“依赖抽象原则”，即客户代码应该依赖于抽象接口编程，而不是依赖于具体实现类编程。但是，在学习这些设计模式的过程中，我们也有意忽略一个必须解决的问题：抽象接口是无法实例化的，只有具体实现类才能被实例化，因此客户代码虽然依赖于抽象接口... 阅读全文

摘要： 第12章 Null Object模式 在C++和Java编程中，我们经常要判断一个对象引用是否为NULL/null。只有在它不为NULL/null的前提下，我们才对它时行相应的操作。下面是分别使用Java和C++来写出的同一段逻辑。 C++ Employee* e = DBFacade::getEmployee("Bob"); if (e != NULL && e->isTimeToPay(tod... 阅读全文

摘要： 第10章 Facade模式 在我们编写软件时，我们常常需要与一些复杂子系统打交道。这些复杂子系统往往提供了完备而通用的API，从而满足各种客户代码的需要。站在子系统的角度看，这样做是正确的，因为它不应该对客户代码如何使用它作出太多的假定或限定，而是应该为客户代码提供尽可能全面的功能，至于客户代码怎样使用和取舍这些功能，那是客户代码所要考虑的问题了。 再站到客户代码的角度来看。特定的客户代码在使用一... 阅读全文

摘要： 第9章 Template Method模式和Strategy模式 在许多实际问题中，我们都会碰到这样的情况：问题的解决方案有一个大体的框架或通用的流程，但是在一些具体的细节上需要具体问题具体分析，采取不同的措施或策略。换言之，我们已经构思出了一个通用的算法来解决一类问题，但是其中的某些细节又是与具体的问题相关的。我们希望能够把通用算法与具体的上下文相分离，这样，通用算法部分将是稳定的可重用的，而由... 阅读全文

摘要： 第8章 Command模式 在近几年记述过的所有设计模式中，Command模式是最简单、最优雅的模式之一。Command模式的适用范围很广，我们首先通过一个实例来学习它的最主要的一个应用场合：对用户的操作建模。 例子：处理雇员信息数据库系统的用户命令 假设我们在开发一个雇员信息数据库系统。该系统的1.0版本采用的是命令行界面。下面给出几个常用的用户命令。 加入新的雇员 % add_emp ID i... 阅读全文

摘要： 第6章 接口隔离原则 接口隔离原则（Interface Segregation Principle）可被表述为：客户模块不应该被强迫依赖于不使用的方法。 在前一章中，我们学习了依赖抽象原则，并且指出：客户模块给服务提供者模块设定要求，这种要求以抽象接口的形式表示。那么，接口隔离原则就进一步指出：抽象接口必须准确地反映客户模块的要求，不能把客户模块不需要或用不到的服务也包括到抽象接口中来。 为什么不... 阅读全文

摘要： 第4章 里氏替换原则里氏替换原则（Liskov Substitution Principle）可以如下表述：子类必须能够顶替它的父类。里氏替换原则关注的是面向对象设计中的一个重要方面：继承关系。里氏替换原则是判断是否应该使用把两个类建模成继承关系的准则。在具体应用里氏替换原则，我们最关键的是应用“行为分析”，即判断子类的行为是否与父类的行为完全一样。如果两者在行为上有哪怕一点点偏差，那么就应该怀疑它们之间是否真地应该被建模成继承关系。一个经典的例子是矩形和正方形。由于受数学观念中“正方形是矩形”这一思想的影响，人们在使用计算机对两者建模时也习惯性地把正方形建模成矩形的子类。但是，正如里氏替换原 阅读全文

摘要： 第3章 开放封闭原则 开放封闭原则（Open-Closed Principle）可以被表述如下：软件实体（类，模块，函数，等等）应该对扩展开放，对修改封闭。 开放封闭原则的要义是：软件应该能够在不修改或尽量少修改现在有源代码的情况下，实现易扩展性。 实际上，基于共性变性分析所获得的设计就是遵守开放封闭原则的。例如，对于前一章的Student类的例子，如果我们现在需要按CSV格式产生学生信息报告，那... 阅读全文

摘要： 第2章 单一职责原则 单一职责原则（Single Responsibility Principle）可以如下表述：一个class只能有唯一一个引起它改变的原因。 换言之，如果你可以想到有超过一个动因来修改一个class，那么这个class就有不止一个职责，它就违反了单一职责原则。 单一职责原则说起来简单，但要真正贯彻却不容易，因为我们都习惯于把一套（而不是一个）职责指派给一个class。因此在实际... 阅读全文