pp看书笔记---设计模式之禅第二版 第一章【单一职责原则】

定义

有且仅有一个原因引起类的变更！

书中示例

表示电话的类中有拨号、通话、挂断三个功能

第一变：
一个IPhone接口，里面包含拨号、通话、挂断功能，Phone类来继承实现

---

第一变想法：
理所应当，手机所有的功能放在一个手机的类中实现、管理

---

第二变：
一个IConnectManager接口，包含拨号，挂断功能，一个ConnectManager类继承实现

一个IDataTransfer接口，包含通话功能，该功能参数是IConnectManager类型对象，一个DataTransfer类继承实现

一个Phone类，其中合成ConnectManager类对象、DataTransfer类对象

---

第二变想法：
职责不同：
拨号、挂断功能属于协议管理，通话属于数据传递

职责会引起类变化：
协议的接通、断开都会影响协议的一种状态，而这种状态状态当然也属于所在类，那换句话来说，协议管理会引起类的变化
数据传递的时间、信息量等状态同上（自己感悟）

职责间有无影响：
从逻辑日常生活中来说，没有影响，协议管理去连接电信、移动是协议管理的事；
但只要连通了，数据传递只传递数据（但如果你较真，不同的协议也许数据传递的方式不同，我不知道，但即使是这样，那可以模仿IL一样，对应各种情况，写各种情况的数据传递，而这时你只需要告诉我你的协议是什么即可）
从代码来说，数据传递本来需要协议的对象，传入即可，依赖关系，达到解耦

---

第三变：
第二变中省去两个中间类，由Phone类继承两个接口实现

---

第三变想法：
面向接口编程，把单一职责体现在接口上
类的数量减少—>代码复杂程度降低—>可读性没有降低

---

示例后精炼作者总结：
1. 接口一定要做到单一职责
2. 类的实现要根据实际情况调整
3. 方法可以借鉴单一原则（粒度小）

---

我学到的知识：
1.重视UML◆——->合成，——->依赖，———▷继承
2.对面向接口编程有一点感受，如果示例中设计与我来说，就是第一变，一个类搞定了手机所有事情，加入了接口：
—–(1)可读性增强：
a.我把所有功能直接写在Phone类中，该类肯定会有实现，要实现就会使该cs文件有很多行语句，即使我Ctrl+M+O将代码折叠，也不如看一眼接口中的成员能更快的清楚明了

b.如果我的类也有同样的情况，我划分了职责，放在多个接口，可读性增强，如果我会去画UML图会显得更合理，可读性又增强
—–(2)易于实现
a.因为职责明确、专注，知道不会耦合，就会易于实现，不会做着a想着b
b.因为职责明确，我明天需要一个发短信的功能，我一想是传递数据的事，我就会想着IDataTransfer接口怎么改，Phone相应实现部分怎么改，我都不会去想连接、挂断的事情(DateTime.Now我再想，真让我实现发短信，需要发短信的号码，怎么连通……唉，这是设计，不要考虑的那么细，如果也考虑，IConnectManager添加发短信的连通即可，实际也很明确怎么做)

---

我的实践：
当我今天看完这第一章，在review我的代码，修改了其中一个“快捷拷贝的功能”，因为我发现可以减少一个依赖变化的因果，修改后带来的好处是：
1.少了一个成员属性，少了一个if，代码减少2行
2.事件做到按需加载

逻辑更合理，性能提升

---

我的感受：
虽然仅是少了两行代码，但意义不仅于此，心中没有这个原则的意识造成的后果，米开朗琪罗说的，完美不是细节，细节成就完美，开展我学习设计模式的路，既然干这一行，也要将代码变成艺术，早日码农翻身成地主。

---