设计模式之禅之六大设计原则-单一职责原则

单一职责原则
--->类从属性维度的划分:名词属性,动作属性。例如。用户类(User),用户行为类。(UserService)
--->类和接口的设计原则要追求的目标是:有且仅有一个原因能引起它的变化。也就是一个接口或类只有一个职责,它就负责同一类的事情,如果所负责的业务超过两类或两类以上,则考虑拆分成不同的接口。

 

单一职责原则的好处
--->类的复杂性降低,实现什么指责都清晰明确的定义
--->可读性提高,因为复杂性降低,因此刻度性提高。
--->可维护性提高,因为可读性提高,因此可维护性降低
--->变更引起的风险降低,变更是必不可少的。如果接口的单一职责做的好,一个接口修改,只对相应的实现类有影响,对其他接口无影响。这对系统的扩展性,维护性都有非常大的帮助

 

示例:

 1 package com.yeepay.sxf.only;
 2 /**
 3  * 电话的接口类
 4  * @author sxf
 5  *
 6  * 一个电话的业务类,看似行为只有这些。
 7  * 可是(1)拨打电话,是需要传输协议的。因此,该业务类隐含负责了通信协议的传输。
 8  *           (2)通话时,是数据的传输。因此,该业务类隐含负责了数据的传输。
 9  * 因此该电话业务类,违背了单一职责的原则,该业务类负责协议和数据两个职责。
10  *
11  * 我们面向接口的编程。因此可以拆分成两个接口类。一个通信协议的传输接口。一个数据格式的接口。
12  * ==>可由一个实现类,同时实现这两个接口,内部组合,完成电话功能。
13  * ==>也可以由两个实现类,各自实现一个接口。然后两个实现类,数据传输类引用通信协议传输接口,(增加类的数量,增加了类之间的耦合度)
14  *         在需要打电话,先调用通信协议的方法,建立链接。再传输数据。完成通话
15  *
16  *
17  */
18 public interface IphoneService {
19
20     /**
21      * 拨通电话
22      * @param phoneNumber
23      */
24     public void dial(String phoneNumber);
25     /**
26      * 进行通话
27      * @param o
28      */
29     public void chat(Object o);
30     /**
31      * 通话完毕,挂断电话
32      */
33     public void hangup();
34 }

View Code

 

时间: 2024-07-29 10:22:18

设计模式之禅之六大设计原则-单一职责原则的相关文章

设计模式之禅之六大设计原则-接口隔离原则

接口隔离原则一:什么是接口?● 实例接口(Object Interface)        ---->Person zhangSan=new Person()产生了一个实例,这个实例要遵从的标准就是Person这个类,Person类就是zhangSan的接口● 类接口(Class Interface)        ---->Java中经常使用的interface关键字定义的接口. 二:那什么是隔离呢?它有两种定义:      ---->事物的定义一般都比较难理解,晦涩难懂是正常的.我们

设计模式六大原则 单一职责原则

设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责,一个人只负责做一件事. ( 一个类,只有一个引起它变化的原因.应该只有一个职责.每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起.这会导致脆弱的设计.当一个职责发生变化时,可能会影响其它的职责.另外,多个职责耦合在一起,会影响复用性.例如:要实现逻辑和界面的分离 ) 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修

设计模式六大原则——单一职责原则(SRP)

      定义       就一个类而言,应该仅有一个引起它变化的原因.通俗的说,一个类只负责一项职责.       问题的由来       手机的功能多,但是每一项的功能都不强:       拍摄功能-->专业的摄像机和照相机       手机游戏-->PSP       网络摄像头-->专业摄像头       GPS功能-->专业GPS导航系统       每一个职责都是一个变化的轴线,当需求变化时会反映为类的职责的变化,如果一个类的承担的职责多于一个,那么引起她变化的原因就

设计模式之禅之六大设计原则-开闭原则

开闭原则 一:开闭原则的定义        --->一个软件实体如类.模块和函数应该对扩展开放,对修改关闭.        --->我们做一件事情,或者选择一个方向,一般需要经历三个步骤:What--是什么,Why--为什么,How--怎么做(简称3W原则,How取最后一个w)        --->对于开闭原则,我们也采用这三步来分析,即什么是开闭原则,为什么要使用开闭原则,怎么使用开闭原则? 二:如何使用开闭原则        --->抽象约束.               

设计模式之禅之六大设计原则-依赖倒置原则

依赖倒置原则依赖倒置原则的原始定义是:● 高层模块不应该依赖低层模块,两者都应该依赖其抽象;● 抽象不应该依赖细节;● 细节应该依赖抽象. 那什么是抽象?什么又是细节呢?---->在Java语言中,抽象就是指接口或抽象类,两者都是不能直接被实例化的;细节就是实现类,实现接口或继承抽象类而产生的类就是细节,其特点就是可以直接被实例化,也就是可以加上一个关键字new产生一个对象.依赖倒置原则在Java语言中的表现就是: ● 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接

设计模式之禅之六大设计原则-迪米特原则

迪米特法则 一:迪米特法则定义:        ---->迪米特法则(Law of Demeter,LoD)也称为最少知识原则(Least KnowledgePrinciple,LKP),        ---->一个对象应该对其他对象有最少的了解.通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的这么多public方法,我就调用这么多,其他的我一概不关心. 二:迪米特法则对类的低耦合提出明确的要求.   

设计模式之禅之六大设计原则-里氏替换原则

里氏替换原则说的就是面向对象语言的继承--->代码共享,减少创建类的工作量,每个子类都拥有父类的方法和属性.--->提高代码的重用性.--->子类可以形似父类,但又特殊于父类.--->提高代码的可扩展性.实现父类的方法,可以为所欲为.许多开源框架的接口都是继承父类完成的.--->提高产品或项目的开放性.--->继承是侵入性的.子类必须拥有父类的属性和方法.让子类自由的世界中多了些约束.--->增强了耦合性.当父类的常量,变量和方法被修改时,需要考虑子类的修改.造成

《Android 源码设计模式解析与实战》——第1章,第1.1节优化代码的第一步——单一职责原则

第1章 走向灵活软件之路--面向对象的六大原则Android 源码设计模式解析与实战 1.1 优化代码的第一步--单一职责原则单一职责原则的英文名称是Single Responsibility Principle,缩写是SRP.SRP的定义是:就一个类而言,应该仅有一个引起它变化的原因.简单来说,一个类中应该是一组相关性很高的函数.数据的封装.就像老师在<设计模式之禅>中说的:"这是一个备受争议却又及其重要的原则.只要你想和别人争执.怄气或者是吵架,这个原则是屡试不爽的".

单一职责原则

单一职责原则 单一职责原则(Simple responsibility pinciple SRP) 就一个类而言,应该仅有一个引起它变化的原因,如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.应该把多于的指责分离出去,分别再创建一些类来完成每一个职责. 单一职责原则是软件设计7大原则之一,其核心思想就是最大限度的提升代码的可复用性.   以下以具体的例子阐述,为何单一职责原则能最大限度的提升代码的可复用性. 之前写过一篇教程,教大家通过runtime扩展了NSObject