最近前辈推荐我读《设计模式之禅》这本书，原因是我写的代码质量实在是一言难尽，开发速度很快，但是bug数就很多了，设计原则这种知识就需要掌握
写这篇文主要是记录自己的学习以及督促自己
第一章【单一职责】
从我理解的层面来谈谈单一原则：明确每个类每个方法的任务，只做一件事，不能一法两用
这也是我最大的一点感受
尤其是在看这张图的时候，如果是我的话，我肯定会写在一起，不可能分的这么细，所以单一职责的难点就是：很难划分职责
其次他的好处：
● 类的复杂性降低，实现什么职责都有清晰明确的定义；
● 可读性提高，复杂性降低
● 变更引起的风险降低
我认为不好的点：
维护性并不是特别高吧，当业务很复杂的情况下，这种拆分，会变得很冗余，物极必反可能是这个道理
实际应用：
"我的建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化"这是作者原话，看完后我就记得我写过的一段代码，通过传type跳转不同业务逻辑的方案，看完后我就会把单一原则和封装结合在一起去想，什么是可以进行封装的？业务逻辑的复用吗?那也算是完成很多不同的事，这样封装又不满足单一职责了，不知道评论区的大佬能不能帮我解答一下，非常感谢！！！！