单一职责原则

[5分钟]菜鸟修研之设计模式：六大设计原则 目录 [5分钟]菜鸟修研之设计模式：六大设计原则 单一职责原则 接口隔离原则 开闭原则 里氏替换原则 依赖倒置原则 迪米特法则 笔者作为一个菜鸟，会尝试以简单的代码和容易理解的语句去解释这几种原则的特性和应用场景。 这六种原则分别为单一职责原则、接口隔离原则、里氏替换原则、迪米特法则、依赖倒置原则、开闭原则。 单一职责原则 单一职责原则(SRP：Single responsibility principle)，规定一个类中应该只有一个原因引起类的变化。 单一职责原则的核心就是 解耦和增强内聚性 。 问题： // 假设此类是数据库上下文 public class DatabaseContext { } public class Test { private readonly DatabaseContext _context; public Test(DatabaseContext context) { _context = context; } // 用户登录 public void UserLogin() { } // 用户注销 public void UserLogout() { } // 新增一个用户 public void AddUser() { } // 修改一个用户的信息 public void UpdateUser() { }

http://www.cnblogs.com/seacryfly/archive/2011/12/29/2305965.html 只有类对应的（唯一）职责（需求）的变更才会引起代码的重构。 The single responsibility principle states that every module or class should have responsibility over a single part of the functionality provided by the software , and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. Robert C. Martin expresses the principle as follows: [1] “ A class should have only one reason to change. ” 2.2 单一职责原则 2.2.1 引言 一个优良的系统设计，强调模块间保持低耦合、高内聚的关系，在面向对象设计中这条规则同样适用，所以面向对象的第一个设计原则就是：单一职责原则（SRP

目录 设计模式之遵循原则 1. 单一职责原则(SRP) 1.1 设计目的 1.2 定义 1.3 应用 2. 开放-封闭原则(OCP) 2.1 设计目的 2.2 定义 2.3 应用 3. 依赖倒转原则 3.1 设计目的 3.2 定义 3.3 应用 4. 迪米特法则(LoD,最少知识原则) 4.1 设计目的 4.2 定义 4.3 应用 设计模式之遵循原则 1. 单一职责原则(SRP) 1.1 设计目的 我们在做编程的时候，会很自然的给一个类添加各种各样的功能，比如我们写一个窗体应用程序，一般都会生成一个Form这样的类，于是我们就把各种各样的代码，像商业运算的算法，像数据库访问的SQL语句都写入到该类中，这样意味无论任何需求要来，你都需要改变这个窗体类，这样维护麻烦，无法复用，缺乏灵活性。 所以我们在设计一个类时，要遵循单一职责，让类具备原子化属性。 1.2 定义 就一个类而言，应该仅有一个引起它变化的原因。 1.3 应用 设计俄罗斯方块： 分别设计3个窗体的Form类, WallForm(背景容器), NewShapeForm(新产生的形状)， ResultShapeForm(最终组合的形状)，输入参数，横纵坐标，和形状代码。 设计Operation类，用于产生随机的NewShape的输入参数，产生改变形状的code，挪移的输入横纵坐标，获取Form的当前位置，已经最后合并操作等属性

一、简介 设计模式是对软件设计中普遍存在（反复出现）的各种问题，所提出的 解决方案 。 二、六大原则 a、单一职责原则 【基本介绍】 对类来说的，即 一个类应该只负责一项职责 。如类A负责两个不同职责：职责1，职责2。 当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为 A1，A2 【注意事项和细节】 降低类的复杂度，一个类只负责一项职责 提高类的可读性，可维护性 降低变更引起的风险 通常情况下， 我们应当遵守单一职责原则 ，只有逻辑足够简单，才可以在代码级违 反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原 b、接口隔离原则 【基本介绍 】 客户端不应该依赖它不需要的接 口，即一个类对另一个类的依赖 应该建立在最小的接口上 c、依赖倒转（DIP）原则 【基本介绍】 d、里氏替换原则 e、开闭原则ocp f、迪米特法则 来源： https://www.cnblogs.com/liugp/p/12082823.html

单一职责原则(Single Responsibility Principle, SRP)是Bob大叔提倡的S.O.L.I.D五大设计原则中的第一个。其中，职责(Responsibility)被表述为“变化的原因”(reason to change)；SRP被表述为“一个类应该有且只有一个变化的原因”。但如果光从字面去理解，SRP很容易让人望文生义产生误解。本文希望能阐明SRP的本质，达到避免误解和指导设计的目的。 动机 对于设计原则的理解应该首先从它的动机入手，即遵循这个原则带来的好处是什么？对于SRP来讲，如果遵循“一个类应该有且只有一个变化的原因”是因，那么“任何一个变化只会影响一个类”就是果。可见SRP的动机主要是系统的可维护性，即降低适应变化的成本。 多功能与单变化 对于单功能的类来讲，比较容易遵循SRP，比如：把string转换为DateTime类型的工具类。理解SRP的难点在于在多功能类的情形，即不容易理解多功能与单变化的矛盾。让我们先来看一个Modem类的例子，Modem具有4个功能：拨号，挂断，发送数据，接收数据： class Modem { public void Dial(string aPno) {…} public void Hangup() {…} public void Send(char aData) {…} public char Receive()

基本概念 单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。 There should never be more than one reason for a class to change. 实例说明 简单栗子感受一哈 看如下类图 分析一下这个类图哈，UserInfo实现IUserInfo接口，IUserInfo接口下有一系列方法，不过认真看一下这些方法，结合让你直接定义一个UserInfo类，很容易会发现username、password、userID会被我们作为类的属性，其他的会被作为类的行为。这样设计接口就不满足原则了。 可拆分为以下类图 分析一哈这个类图，仅将原来的一个接口泛化，即IUserInfo接口继承了两个接口，…………这些仅起到说明的作用，其他和上述类图类似，不详细说明了。 在看以下这个类图，多了一个依赖关系，这种设计就符合单一职责原则 以上我们把一个接口拆分成两个接口的动作，就是依赖了单一职责原则，那什么是单一 职责原则呢？单一职责原则的定义是： 应该有且仅有一个原因引起类的变更。 复杂栗子感受一哈 分析一下这个类图哈，定义了一个电话的接口，有打电话、通话、挂断这三个方法，正常我们开发可能就写成这样子了，但是我阅读的这书中，却提出了这里面包含了协议管理和处理数据两个职责，分别对应打电话、挂断电话和通话，细想一下

有可能重复别的文章,只是自己的一个整理 单一法则 类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障或者难以维护,这就违背了单一职责 一个类只负责一件事儿,一个方法只负责一件事儿,写了太多的分支判断,去执行各自的业务逻辑时候,就容易出现职责不单一,所以只能拆分解决职责不单一的问题 类拆分:父类+子类,每个类就很简单,类内部很简单,简单就意味着稳定,未定就是开发永恒的追求,拆分以后:代码量就变多了,类增多了,(解读量增大了,理解成本增大了) 如果方法足够简单,类够少,其实违背一下单一职责也无所谓,如果方法多了,业务逻辑复杂,建议遵循单一职责。 方法的单一职责:一个方法只负责一件事儿(根据职责分拆小方法,避免分支逻辑判断) 类的单一职责:一个类只负责一件事儿 类库的单一职责:一个类库应该职责清晰 系统层面的单一职责:为通用的功能分拆系统 优点: 降低类的复杂度 提高类的可读性,因为类的职能单一,看起来比较有目的性,显得简单 提高系统的可维护性,降低变更程序引起的风险 里氏替换原则 任何使用基类的地方,都可以透明的使用其子类 继承:子类拥有基类的一切属性和行为,任何基类出现的地方都可以用子类代替 继承+透明(安全,不会出现行为不一致的情况) 在创建对象的时候尽量使用父类做变量的声明;为了能够更加灵活

单一职责原则的定义 　　单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。 　　该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点： 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力； 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。 单一职责原则的优点 　　单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。 提高类的可读性。复杂性降低，自然其可读性会提高。 提高系统的可维护性。可读性提高，那自然更容易维护了。 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。 单一职责原则的实现方法 　

单一职责原则 定义 单一职责原则(Single Responsibility Principle, SRP)是Bob大叔提倡的S.O.L.I.D五大设计原则中的第一个。其中，职责(Responsibility)被表述为“变化的原因”(reason to change)；SRP被表述为“一个类应该有且只有一个变化的原因”。但如果光从字面去理解，SRP很容易让人望文生义产生误解。本文希望能阐明SRP的本质，达到避免误解和指导设计的目的。 动机 对于设计原则的理解应该首先从它的动机入手，即遵循这个原则带来的好处是什么？对于SRP来讲，如果遵循“一个类应该有且只有一个变化的原因”是因，那么“任何一个变化只会影响一个类”就是果。可见SRP的动机主要是系统的可维护性，即降低适应变化的成本。 多功能与单变化 对于单功能的类来讲，比较容易遵循SRP，比如：把string转换为DateTime类型的工具类。理解SRP的难点在于在多功能类的情形，即不容易理解多功能与单变化的矛盾。让我们先来看一个Modem类的例子，Modem具有4个功能：拨号，挂断，发送数据，接收数据： class Modem { public void Dial(string aPno) {…} public void Hangup() {…} public void Send(char aData) {…} public char

内聚性： 一个模块的组成元素之间的功能相关性。 就一个类而言，应该仅有一个引起它变化的原因。 当需求变化时，该变化会反映为类的职责的变化，如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个。 如果一个类承担的职责过多，就等于把这些职责耦合在一起。一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。 这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。 什么是职责？ 在SRP中，吧职责定义为“变化的原因”。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个职责。有时，很难注意到这一点，我们习惯于以组的形式去考虑职责。 Modem接口，大多数人认为这个接口非常合理： public interface Modem { public void dial ( String pno ); public void hangup (); public void send ( char c ); public void recv (); } 然而，该接口却显示两个职责（1）连接管理（2）数据通信。 dial和hangup连接处理，send和recv数据通信 这两个职责应该被分开吗？这依赖于应用程序变化的方式。如果应用程序的变化会影响连接函数的签名，那么这个设计就具有僵化性的臭味，因为send和recv的类必须要重新编译。 在这种情况下