单一职责原则
2022-06-24 10:08:49 17 举报AI智能生成
登录查看完整内容
设计模式之单一职责原则
作者其他创作
大纲/内容
一个类只负责完成一个职责或者功能
不要设计大而全的类，要设计粒度小、功能单一的类
定义
不同的应用场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定，可能都是不一样的。在某种应用场景或者当下的需求背景下，一个类的设计可能已经满足单一职责原则了，但如果换个应用场景或着在未来的某个需求背景下，可能就不满足了，需要继续拆分成粒度更细的类。
我们可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，我们就可以将这个粗粒度的类，拆分成几个更细粒度的类。这就是所谓的持续重构（
如何判断类的职责是否足够单一？
类中的代码行数、函数或者属性过多；
类依赖的其他类过多，或者依赖类的其他类过多；
私有方法过多；
比较难给类起一个合适的名字；
类中大量的方法都是集中操作类中的某几个属性。
设计不满足单一职责原则
单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、低耦合。但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。
类的职责是否设计得越单一越好？
单一职责原则
开闭原则
里式替换原则
接口隔离原则
依赖反转原则
SOLID 原则
单一职责原则（SRP）
收藏
0 条评论
回复 删除
下一页
