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