测试驱动开发系列之三--TDD策略：SOLID，灵活并可测试的设计

S(Single Responsibility Principle)单一职责原则

O(Open Closed Principle)开闭原则

L(Liskov Substitution Principle)列丝科芙代换原则

I(Interface Segregation Principle)接口分离原则

D(Dependency Inversion Principle)依赖倒置原则

有了SOLID的知识，它能帮助我们把代码组织成内部高度内聚并与其他模块松散耦合的一些模块。从而使代码的改动更倾向于发生在局部，而设计则变得更可测。SOLID设计原则帮助你提前展望到一个好的设计，从而使你避免这种恶化。

单一职责原则

是说一个模块应当只有一个单一的职责，它应当只做一件事，并且只有一个理由来改变它。模块与他们的测试仪器讲述他们自己的故事。

开闭原则

是说一个模块应当对扩展开放而对修改关闭。

接口分离原则

建议客户代码不应依赖于臃肿的接口。接口应该按照客户的需要而裁剪。通过裁剪接口我们限制了依赖，使代码更容易移植，并且使得使用这个接口的代码更容易测试。

依赖倒置原则

细节应该依赖于抽象，抽象不应依赖于细节。我们可以通过抽象和接口来断开依赖关系。比如操作系统使用同样的机制来保持OS代码不直接依赖于你的代码。回调函数是依赖倒置的一种形式。

在需要达到以下目的时，我们会使用DIP。

把实现细节隐藏在接口之后

不在接口中揭示实现的细节

客户通过函数指针调用服务

服务能过函数指针来回调客户数据

用ADT来隐藏数据类型的细节

这些相互关联的原则可以给我们提供指导，以避免C编程中那种到处都是可以随意访问的数据结构和函数的情况。

列丝科芙代换原则

LSP的含义是客户模块不应关心它在与什么类型的服务模块一起工作。发起调用的代码不需要有任何特别的知识就可以替换有着同样接口的模块。操作系统隔离层的设计中找到LSP的例子。

11.2C语言中的SOLID模型

单一实例模块

在只需要一个实例的模块中把模块的内部状态封装起来。

头文件中定义了与模块交互所需的所有东西。而用来完成工作的数据结构隐藏在.c文件内可见的变量中。调度器的数据不需要在头文件中出现，因为其他模块不关心。这使得其他模块无法依赖于这个结构，并且确保了它的完备性是调度器的职责。

多实例模块

封装模块的内部状态，并且可以创建多个模块数据的实例。

一个应用程序需要一个模块的几个实例来包含不同的数据和状态。

动态接口

允许模块接口中的函数在运行时值

基于类型的动态接口

允许有同样接口的多个不同类型的模块拥有统一的接口函数。

11.3演进的需求和有问题的设计

对于管理一族相关的数据结构来讲，抽象一个共同的数据类型，用指针强制转换来实现在抽象和具体类型之间的转换。这样就可以实现动态接口了。

11.4 用动态接口来改进设计

动态接口使用一个或多个函数指针来允许在运行时选择某一函数实现来执行。这种单一的间接层次能够提供运行时的灵活性(对于面向对象来讲这是多态的基础)。

应用OCP和LSP:把重复的switch语句通过使用函数指针的设计重构出来，这样会消除对于特定驱动函数的直接依赖。

11.5更灵活的基于类型的动态接口

每一个结构体都需要一族关联的函数指针。不像动态接口模型中那样只有一个接口指针，这也是在C++中实现虚函数的方式。在C++中调用一个声明为Virtual的函数意味着这个函数要通过一个虚函数表(vtable)来调用。

11.6做多少设计才是足够的

在一个新的开发工作的开始阶段，会有相当多的不确定性。最好是尽早开始，尽管有些东西将来会改变。事前想好和优柔寡断只有一线之隔。当你在猜测之上再建立猜测时，想一想你是不是走得太远了，是时候在代码中尝试这些想法了。很多现在遗留代码的问题是随着需求的演进，但测试却没有同时改进来

我们无法预期到所有产品中将要到来的改变，这就是为什么我们必须学好演进设计的技能。这个思想的背后是极限编程的简单设计法则。

极限编程中的简单设计法则

1)运行所有的测试。

代码必须做需要它做的事。如果不需要为什么要写呢？如果代码不能以测试通过的方式来证明其满足了设计意图，那么这些代码对任何人来讲都是没有价值的。

2)表达我们需要表达的每个想法

代码应当自己给自己做文档，以交流程序员的意图。

3)每件事说且只说一次

必须移除重复，这样当有东西发生变化时同一个想法不需要在多处改动。

4)没有多余的部分

这最后的一条仿制我们把还不需要的东西引入。也就是不要过度设计。过早地加入复杂度会推迟功能交付以及集成的机会。