网站建设单位有哪些,南宁网站建设智能优化,网络平台怎么制作,中国服务器市场系列文章目录
C高性能优化编程系列 深入理解设计原则系列 深入理解设计模式系列 高级C并发线程编程 SRP#xff1a;单一职责原则 系列文章目录1、单一职责原则的定义和解读2、单一职责原则案例解读2.1、违背单一职责原则反面案例2.2、违背单一职责原则反面案例 - 解决方案 3…系列文章目录
C高性能优化编程系列 深入理解设计原则系列 深入理解设计模式系列 高级C并发线程编程 SRP单一职责原则 系列文章目录1、单一职责原则的定义和解读2、单一职责原则案例解读2.1、违背单一职责原则反面案例2.2、违背单一职责原则反面案例 - 解决方案 3、类的职责是否越细化越好4、如何判断类的职责是否单一5、小结 1、单一职责原则的定义和解读
单一职责原则(Single Responsibility Principle, SRP)的描述一个类或模块只负责完成一个职责(或功能)。
注意单一职责原则描述的对象有两个类(Class)和模块(Module)。关于这两个概念我们有两种理解方式。
一种理解方式把模块看作比类更抽象的概念把类看作一种模块。另一种理解方式把模块看作更粗粒度的代码块多个类组成一个模块。
无论哪种理解方式单一职责原则在应用这两个描述对象时原理是相通的。粒度小功能单一。
2、单一职责原则案例解读
2.1、违背单一职责原则反面案例
反面案例1: 重复的假象 某个工资管理程序中的Employee类有三个函数caculatePay()、reportHourse()和save()。 图1 Employee类 这三个类的函数分别对应的是三类非常不同的行为者违反了SRP设计原则。
caculatePay()函数是由财务部门制定的他们负责向CFO汇报。 reportHourse()函数是由人力资源部制定并使用的他们负责向COO汇报。 save()函数是由DBA制定的他们负责向CTO汇报。
这三个函数被放在同一个源代码文件即同一个Employee类中程序员这样做实际就等于使三个类行为耦合在了一起。这有可能会导致CFO团队的命令影响到COO团队所依赖的功能。
例如caculatePay()函数和reportHourse()函数使用同样的逻辑来计算工作时数。程序员为了避免重复编码通常会将该算法单独实现一个名为的reportHourse()函数。
图2 算法共享 接下来假设CFO团队需要修改正常工作时数的计算方法而COO带领的HR团队不需要这个修改因为他们对数据的用法是不同的。 这时候负责这项修改的程序员会注意到函数调用了函数但可能不会注意到该函数会同时被调用。
于是该程序员就这样按照要求进行了修改同时CFO团队的成员验证了新算法工作正常。这项修改最终被成功部署上线。
但是COO团队显然完全不知道这些事的发生HR仍然在使用产生的报表随后就发现他们的数据出错了最终这个问题让COO十分愤怒因为这些错误的数据给给公司造成了几百万的损失。 与此类的事情我们多多少少都经历过。这类问题发生的根源就是因为我们将不同的行为所依赖的代码强凑到一起。对此SRP强调这类代码一定要分开。
反面案例2: 代码合并 一个拥有很多函数的源代码文件必然经历很多次代码合并该文件中的这些函数分别服务不同行为者的情况就更加常见了。
例如CTO团队的DBA决定要对Emploee数据表结构进行简单修改。与此同时COO团队的HR需要修改工作时数据报表的格式。
这样一来就很可能出现两个来自不同团队的程序员分别对Emploee进行修改的情况。不出意外的话他们各自的修改一定会互相冲突这就必要进行代码合并。
在这个例子中这次代码合并不仅可能让CTO和COO要求的功能出错甚至连CFO原本正常的功能也可能收到影响。
事实上这样的案例还有很多我们就不一一例举了。他们的一个共同点是多人为了一个不同的目的修改了一份源代码这很容造成问题的产生。
而避免这种问题产生的方法就是将服务不同行为者的代码进行切分。
2.2、违背单一职责原则反面案例 - 解决方案
我们有很多方法可以用来解决上面的问题每一种方法都需要将相关的函数划分到不同的类。
其中最简单直接办法是将数据与函数分离设计三个类共同使用一个不包括函数的、十分简单的EmployeeData类每个类只包含与之前相关函数的代码互相不可见这样就不存在相互依赖的情况了。
图3 三个类互相不可见 这种解决方案的坏处在于程序员现在需要在程序里处理三个类。另一种方法是使用Facade(外观)设计模式。
图4 Facade模式 这样一来EmployeeFacade类所需要的代码量就很少了他仅仅包含了初始化和调用三个类的函数。
当然也有程序员更倾向于把重要的业务逻辑与数据放在一起那么我们也可以选择将最重要的函数保留在Emploee类中同时用这个类调其他没那么重要的函数。
图5 将最重要的函数保留在Emploee类中同时用这个类调其他没那么重要的函数 读者也许会反对上面这些解决方案因为看上去这里的每个类中都只有一个函数事实上并非如此因为无论是计算工资、生成报表还是保存数据都是一个很复杂的过程每个类都可能包含了许多私有函数。
总而言之上面的每一类都分别容纳了一组作用于相同作用域函数而在作用域之外它们各自的私有函数是互相不可见的。
3、类的职责是否越细化越好
在面向对象编程中类的职责不应该过多、过于复杂而应该越细越好这是因为
类的单一职责原则Single Responsibility Principle每个类都应该只有一个职责这样可以保证类的代码简洁明了、易于维护和扩展。
高内聚低耦合原则High Cohesion Low Coupling将一个类拆分成多个单一职责的类可以使得各类之间的耦合度降低提高代码的灵活性和可复用性。
然而同时过度细化职责也有其负面影响
增加代码复杂度和维护成本当类被拆分成过多微小的类时会增加代码的数量和复杂度导致维护成本的增加。
过度抽象将导致代码的不透明性和可读性降低在面向对象编程中过度抽象会导致代码难以阅读和理解。
因此类的职责是否越细化越好需要根据具体情况进行权衡。在实际编程中需要保持类的职责尽量单一、明确但不要过度细化避免代码的冗余和不必要的复杂性。同时也要注意把握好封装的程度保证类的内部实现不会对外部造成影响。
4、如何判断类的职责是否单一
要判断一个类的职责是否单一可以使用以下方法
查看类的名称和文档类的名称和文档应该准确地描述它的职责。如果名称或文档涵盖了多个职责那么这个类可能不够单一。分析类中的方法观察类中的方法是否都涉及同一个领域或者问题域。如果这些方法处理不同的领域或问题域那么这个类可能不够单一。查看类的属性观察类中的属性是否都与类的职责相关。如果属性与类的职责无关或者有多个职责那么这个类可能不够单一。观察类的依赖关系观察类是否依赖其他类或模块如果这些依赖与类的职责无关或者有多个职责那么这个类可能不够单一。观察代码的复杂度观察类的代码是否过于复杂如果代码过于复杂可能说明这个类的职责不够单一。
综上所述以上方法可以帮助你判断一个类的职责是否单一。如果你发现一个类的职责过于复杂或者不够单一那么就需要考虑对这个类进行重构将其拆分成多个单一职责的类。
5、小结
单一职责原则主要讨论的是函数和类之间的关系 - 但是它在两个讨论层面上会以不同的形式出现。在组件层面上我们可以将其称为共同闭包原则在软件架构层面它则是用于奠定架构边界的变更轴心。
