开发几大原则理解(单一原则)
来源:互联网 发布:linux 批量删除文件名 编辑:程序博客网 时间:2024/06/05 08:20
网上看这张图片归纳挺好的:
单一原则(Single Responsibility Principle)
单一职责原则的英文名称是 Single Responsibility Principle,简称是 SPR,简单地说就是一个类只做一件事,这个设计原则备受争议却又极其重要。只要你想和别人争执、怄气或者是吵架,这个原则是屡试不爽的。因为单一职责的划分界限并不是如马路上的行车道那么清晰,很多时候都是需要个人经验来界定。当然,最大的问题就是对职责的定义,什么是类的职责,以及怎么划分类的职责。这跟我们社会分工一样, 一些人干这个, 另一些人干那个,只有大家都这样做了, 我们的社会才更和谐。
试想一下,如果你遵守了这个原则,那么你的类就会划分的很细,每个类都有比较单一的职责,这不就是高内聚、低耦合么!当然,如何界定类的职责就需要你的个人经验了。
当然,软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离,就是抽象的能力。其实要去判断是否应该分离出类来,也不难,那就是如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责。
/** * @ClassName: OrderSend * @Description: 指令发送接口 * @author: jyj * @date: 2017年6月7日 下午10:47:49 */public interface OrderSend{ String readDeviceName(); String readDeviceMacAddress();}
我们可以看到,OrderSend接口中定义了两个方法,分别是读取设备名称和读取设备mac地址。它的职责很单一,这样在需要修改执行指令发送的相关代码时,只需要修改实现 OrderSend接口的类,而不会影响其他类的代码。如果某个类的职责包含有执行指令发送、指令解析等,那么在你修改某处代码时就必须谨慎,以免修改的代码影响了其它的功能。当你修改的代码能够基本上不影响其他功能。这就一定程度上保证了代码的可维护性。注意,单一职责原则并不是一个类只能有一个函数,而是说这个类中的函数所做的工作是高度相关的,也就是高内聚。
基本判断原则, 就是一个特定的类,当确认以后, 它的责任就确定了,不能增加它行为以外的功能。 例如一般我们定义 API 接口的时候,如果这个接口干了很多事情, 就是一些隐含的事情,我们就认为它设计没有遵循单一原则。
优点
类的复杂性降低,实现什么职责都有清晰明确的定义。
可读性提高,复杂性降低,那当然可读性提高了。
可维护性提高,可读性提高了,那当然更容易维护了。
变更引起的风险降低,变更是必不可少的,如果接口的单一职责做得好,一个接口修改只对应的实现类有影响,对其他的接口无影响,这对系统的扩展性、维护性都有非常大的帮助。
下次继续
- 开发几大原则理解(单一原则)
- 敏捷软件开发 读书笔记——OO五大原则(1.SRP 单一职责原则)
- OO五大原则(1.SRP 单一职责原则)
- 设计模式6大原则(1):单一职责原则
- 6大设计原则(1):单一职责原则
- oo大原则之单一职责原则
- 6大设计原则-单一职责原则
- 如何理解单一职责原则?
- 深入理解JavaScript系列 ----(6):SOLID五大原则之单一职责
- 单一原则
- 单一原则
- 软件设计原则----单一职责原则(SRP)
- 软件设计原则----单一职责原则(SRP)
- 软件设计原则----单一职责原则(SRP)
- 设计原则(1)-单一职责原则
- OOP几大原则
- OOP几大原则
- OOP几大原则
- Intellij IDEA使用指南(持续更新
- SourceTree安装教程和GitLab配置详解
- 199.m1-ListView的优化
- linux ip配置
- MyEclipse添加自己安装的Maven
- 开发几大原则理解(单一原则)
- 淘淘商城系列——商品搜索功能Dao实现
- 200.m1-优化抽取Adapter一之抽取BaseAdapter
- 汇编语言中常用的指令
- 学习7:ROS话题,ROS服务,ROS参数
- jquery.parser源码解析
- 汇编语言 寄存器、英文缩写全称
- 2-struts2入门-action
- 开源单元测试工具汇总