[设计模式之禅读书笔记]001_设计模式六大原则（一）：单一职责原则（Single Responsibility Principle）

序言

   《设计模式之禅》，与这本书结缘是在大三下学期，到图书馆借书的时候，看到一本很新的书，书名带个“禅”字，而当时又比较迷恋乔布斯。于是，不管它写的什么乱七八糟的内容就果断借着，拿回宿舍看。接着，放暑假期间，到金蝶实习，就把这本书带着看，怀着装逼的心态。整个实习两个月期间，这本书基本上没翻过，相反的，却把当时火起来的《山楂树之恋》给看了一遍。实习完回校，果断又把书还回去了。

   今天，我已经快工作一年半了，之前每每想拿起这本书读的时候，总觉得没到火候。现在我觉得似乎到火候了，自己对设计模式有强烈的渴望，有强烈的需求。今天，拿起这本书，一定要老老实实的读完它。

 

单一职责原则

    1. 作者在讲解这一原则的时候，提到了针对两种设计的单一职责：接口设计和类设计。作者给我们的建议是：接口设计一定要做到单一职责，而类设计尽量只有一个原因引起变化。

   2. 作者总结单一职责原则给我们带来的好处是（这里我觉得作者的用语也挺无聊的，估计自己瞎总结的，参考参考）：

a. 类的复杂性降低，实现什么职责都有清晰明确的定义；

b. 可读性提高；

c. 可维护性提高；

d. 变更引起的连锁反应风险降低（这一点挺实在，职责单一了，那引起的变化就少了，于是连锁反应风险就降低了）；

   3. 作者认为单一职责原则的难点：职责的划分。

       这一点，我个人挺赞同的，所谓的职责是很难划分的。

       我做个比喻，关于软件作业的角色，我们有开发工程师和测试工程师这么一说，但是，请观察一下周围的同事和你自己。你是开发工程师的时候，你干的也有测试工程师的工作。你是测试工程师的时候，你也干着开发工程师的工作（这个可能性小一点）。

       所以，在设计我们的软件作业系统时，关于开发工程师和测试工程师的设计我们可以这样设计：规章里的开发工程师和测试工程师是严格独立的单一职责的接口；现实里的开发工程师和测试工程师则是具有混合职责的类。当然，混合职责的类最好做到只有一个因子引起变化。

-以上-