最近前辈推荐我读《设计模式之禅》这本书，原因是我写的代码质量实在是一言难尽，开发速度很快，但是bug数就很多了，设计原则这种知识就需要掌握
写这篇文主要是记录自己的学习以及督促自己
第一章【单一职责】
从我理解的层面来谈谈单一原则：明确每个类每个方法的任务，只做一件事，不能一法两用
这也是我最大的一点感受
尤其是在看这张图的时候，如果是我的话，我肯定会写在一起，不可能分的这么细，所以单一职责的难点就是：很难划分职责
其次他的好处：
● 类的复杂性降低，实现什么职责都有清晰明确的定义；
● 可读性提高，复杂性降低
● 变更引起的风险降低
我认为不好的点：
维护性并不是特别高吧，当业务很复杂的情况下，这种拆分，会变得很冗余，物极必反可能是这个道理
实际应用：
”我的建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化”这是作者原话，看完后我就记得我写过的一段代码，通过传type跳转不同业务逻辑的方案，看完后我就会把单一原则和封装结合在一起去想，什么是可以进行封装的？业务逻辑的复用吗?那也算是完成很多不同的事，这样封装又不满足单一职责了，不知道评论区的大佬能不能帮我解答一下，非常感谢！！！！
1.本站内容仅供参考，不作为任何法律依据。用户在使用本站内容时，应自行判断其真实性、准确性和完整性，并承担相应风险。
2.本站部分内容来源于互联网，仅用于交流学习研究知识，若侵犯了您的合法权益，请及时邮件或站内私信与本站联系，我们将尽快予以处理。
3.本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
4.根据《计算机软件保护条例》第十七条规定“为了学习和研究软件内含的设计思想和原理，通过安装、显示、传输或者存储软件等方式使用软件的，可以不经软件著作权人许可，不向其支付报酬。”您需知晓本站所有内容资源均来源于网络，仅供用户交流学习与研究使用，版权归属原版权方所有，版权争议与本站无关，用户本人下载后不能用作商业或非法用途，需在24个小时之内从您的电脑中彻底删除上述内容，否则后果均由用户承担责任；如果您访问和下载此文件，表示您同意只将此文件用于参考、学习而非其他用途，否则一切后果请您自行承担，如果您喜欢该程序，请支持正版软件，购买注册，得到更好的正版服务。
5.本站是非经营性个人站点，所有软件信息均来自网络，所有资源仅供学习参考研究目的，并不贩卖软件，不存在任何商业目的及用途
暂无评论内容