【设计模式之禅】单一职责

最近前辈推荐我读《设计模式之禅》这本书,原因是我写的代码质量实在是一言难尽,开发速度很快,但是bug数就很多了,设计原则这种知识就需要掌握

  写这篇文主要是记录自己的学习以及督促自己

  第一章【单一职责】

  从我理解的层面来谈谈单一原则:明确每个类每个方法的任务,只做一件事,不能一法两用

  这也是我最大的一点感受

 

  尤其是在看这张图的时候,如果是我的话,我肯定会写在一起,不可能分的这么细,所以单一职责的难点就是:很难划分职责

  其次他的好处:

    ● 类的复杂性降低,实现什么职责都有清晰明确的定义;

    ● 可读性提高,复杂性降低

    ● 变更引起的风险降低

  我认为不好的点:

    维护性并不是特别高吧,当业务很复杂的情况下,这种拆分,会变得很冗余,物极必反可能是这个道理

  实际应用:

    "我的建议是接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化"这是作者原话,看完后我就记得我写过的一段代码,通过传type跳转不同业务逻辑的方案,看完后我就会把单一原则和封装结合在一起去想,什么是可以进行封装的?业务逻辑的复用吗?那也算是完成很多不同的事,这样封装又不满足单一职责了,不知道评论区的大佬能不能帮我解答一下,非常感谢!!!!

 

热门相关:有个人爱你很久   不科学御兽   不科学御兽   拒嫁豪门,前妻太抢手   不科学御兽