软件原则-单一职能原则

写在前头

在日常的软件开发过程当中,咱们常常听到软件要符合单一原则, 开闭原则, 里氏替换原则, 接口隔离原则, 依赖倒置原则. 这些原则都是经过经验教训获得的. 对于软件开发中的大多数场景咱们都应该遵循这些原则, 固然在某些状况下也要打破这些原则. 今天主要讲讲单一原则

定义

单一职能原则(single responsibility principle): 每个模块或者类所对应的职责,应该对应系统若干功能中的某个单一功能, 同时对于该职责的封装都应该经过这个类来完成 从定义中咱们能够看到, 单一职能原则告诉咱们在日常的开发过程当中,咱们要尽量将模块或类的做用保持单一.其实这个原则在不少方面都有所体现.好比如今流程的微服务, 某些系统就是经过业务功能来进行服务的划分, 让各自的服务作好各自的事情. 函数要保持近可能的功能单一. 虽然这个原则很简单,可是在日常的开发过程当中,可能咱们仍然会触犯. 因此在写代码前,设计方案时, 要提早考虑下单一职能原则.

实践

记得以前在工做中, 须要查询数据返回到界面, 由于后台要处理的数据之间有依赖, 因此查询的数据都在一个接口中进行了返回. 这样致使后来这个接口特别难以维护,而且难以阅读; 后台尝试优化界面逻辑, 将此接口按照界面不一样的数据内容拆开, 拆开后每一个接口都只查询界面对应的数据. 通过此重构以后, 接口变得较好的理解同时也下降了维护成本. 还有好比在咱们进行web开发时, 后端常常会涉及到不一样的领域对象, 而领域对象的封装建议根据功能单独拆出一个类出来进行编写. 经过封装领域对象的方法尽量保持简单. 这些都是我在平常开发中的一些体会. 除了这些, 咱们在平常开发工做中如何来避免违反单一职能原则呢? 有如下这些方法 有一个简单的原则, 只须要牢记, 使代码保持足够的简单

孤立变化

须要经常思考为何代码要这样子写, 代码到底完成了什么功能, 对于一些特别长的类和方法要格外注意. 注意将代码中容易变化的点进行隔离

注意类之间的依赖

对于类之间,应该尽量的减小依赖, 若是一个类的构造函数较多, 可能就须要考虑进行对应的重构了. 能够考虑采用工厂模式来解耦类的使用者和实现者之间的依赖. 也能够采用依赖注入机制来减小类之间的依赖 PS: Spring就是采用依赖注入来达到类之间依赖的解耦

注意方法参数

方法参数要尽量少, 在代码整洁之道中建议, 方法的参数不要超过三个. 若是方法参数过多,多是由于此方法作的工做太多, 能够考虑重构方法, 或者考虑将方法参数封装为对应的领域对象 经过也要主要方法的命名, 若是方法的名称过长, 每每表名方法内作了工做太多

尽早重构

在代码的开发过程当中,若是发现有了更好的更简明的方式要进行,要重构它. 这样可以及早的发现问题. 若是须要作出改变,要果断一些.固然这些内容都须要有对应的测试保证, 因此在代码的编写过程当中,最好有相应的单元测试以及集成测试