单一指责原则(Single Responsibility Principle) SRP
using System;
using System.Collections.Generic;
using System.Text; namespace SingleResponsibilityPrinciple
{
//单一指责原则(Single Responsibility Principle) SRP
//There should never be more than one reason for a class to change.
//有且只有一个原因引起类的变更。
class Program
{
//使用场景
static void Main(string[] args)
{
//职责单一适用于接口,类,方法。
//让我们来先看接口是如何体现职责单一的。
//我们都知道自从IPHONE使用USB_Type_C接口后,许多厂家也真先恐后的加入了使用该接口的行列。
//新MacBook的USB_Type_C接口能够传输数据、进行充电也可以作为视频输出端口链接外部显示设备。
//很明显,违反了职责单一的原则!接口包含的三个功能根本毫不相关,如果用户同时要充电,要传输数据,要接显示器,怎么办?而苹果为了减轻MacBook的厚度和重量,为此做了权衡。
//这是产品设计上的取舍,你也不能说不对,各有利弊,对于软件开发来说,也是一样的。
//例如模拟用户使用USB_Type_C接口给手机充电。
Iphone6 iphone = new Iphone6();
XiaoMiM5 xiaomi = new XiaoMiM5();
Charger_C(iphone);
Charger_C(xiaomi);
//而如今闪充技术现在已经不是什么新闻了,我们假设Iphone等不住了要升级充电功能到闪充,不然用户不买账啊。
//想想会发生什么事情?USB_Type_C有3个原因(充电,数据传输,显示)会引起类的变更,由于iphone实现了USB_Type_C接口,想要升级,就肯定先要USB_Type_C接口声明闪充功能。
//这个时候小米和其他使用了USB_Type_C的涉及到充电的厂商不干了啊,USB_Type_C升级闪充,我们也要跟着变了啊(子类必须实现接口声明方法,由于只是内部充电方法改变,接口没变,所以传输和显示相关设备厂商不用改变,充电设备厂商需要适配新的方法),增加了成本和风险,价格不发烧了呀,用户不买账啊。
//什么?你说新建一个Flash_USB_Type_C接口?让苹果自己玩去?传输和显示功能没变。就因为闪充而新增一个新的接口Flash_USB_Type_C,那以前苹果涉及到USB_Type_C接口的相关代码不是全部要适配新的Flash_USB_Type_C接口?
//而且你还要叫其他iphone辅助设备厂家来适配新接口(包括传输和显示相关设备厂商,因为接口已经变了,但其实内部的传输与显示方法并没改变,造成不同接口,声明了实际相同的功能,变复杂了),苹果也不干了(虽然以前苹果产品的接口都是特立独行的……)。
//撕逼大战从此开始,谁叫你们当初选择跟风使用USB_Type_C接口的,说好的职责单一呢?魅族和华为表示毫无压力,因为它分别实现了不同功能的接口。
MeiZu mz = new MeiZu();
Charger_N(mz);
HuaWei hw = new HuaWei();
Charger_N(hw);
//魅族想升级就升级,IFlashCharge闪充是单独的充电功能模块,并且业界已经成熟,魅族替换掉该充电接口即可,华为当然不受影响,依然用着以前的充电技术ICharger~
FlashMeiZu fmz = new FlashMeiZu();
FlashCharger(fmz);
//传输,显示技术的更新换代,原理也一样的,如果不符合职责单一,大家一起折腾去吧。所以接口的职责单一,主要体现在变化上。 //对于方法的职责单一,也很好理解,例如一个用户拨打电话的场景
Iphone6 ip6 = new Iphone6();
//请按F12进入函数看详情
ip6.CallPeople("1307779****");
//符合职责单一方法,你也许会想,SRPCallPeople方法本身好像职责就不单一啊,用了那么多方法?这个需要在不同层面考虑的。
//SRPCallPeople已经是业务逻辑处理函数方法,并只不是功能了,肯定会调用其他方法实现某种业务。而方法的职责单一,主要体现在功能上。
ip6.SRPCallPeople("1307779****"); //最后对于类的职责单一,很大程度上与方法类似。
//例如各种类库,每个类库都实现自己的相关功能(见项目-引用),如果不按照职责单一,不用命名空间区分,它们完全可以在一个类文件中存在啊,简直就是代码混沌世界!
//所以一个类(大到模块,小到方法)承担的职责越多,它被复用的可能性就越小,而且一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作
//因此要将这些职责进行分离,将不同的职责封装在不同的类中,即将不同的变化原因封装在不同的类中,如果多个职责总是同时发生改变则可将它们封装在同一类中。
//职责单一,也就是让我们多多考虑高内聚、低耦合
} //PS.面向接口编程,只关注行为规范,管他对象类是谁。低耦合
//我是一个普通的充电器
static void Charger_N(ICharge device)
{
device.Charge();
} //我是一个支持USB_Type_C的充电器~(Flash_USB_Type_C这种接口的充电器还不存在)
static void Charger_C(IUSB_Type_C device)
{
device.Charge();
} //充电5分钟,通话2小时(闪充充电器已经成熟,很多厂家都开始生产)
static void FlashCharger(IFlashCharge device)
{
device.FlashCharge();
}
} public class Iphone6 : IUSB_Type_C
{
//打电话给某人
public void CallPeople(string number)
{
//发现问题木有?拨打电话的方法全部在这个函数实现了,说好的职责单一呢?
//想想看,代码长度很长的时候,看起来是不是很晕,你很可能不知道这些不同的代码到底是干什么用的,很容易引入BUG。
//并且,检查电话,拨打电话,显示运营商,这些功能并不是只在这里实现。
//所以最好提取出来,做到“方法“的单一,不仅好理解,其他地方也可以调用,减少冗余,复用代码,提高效率~
Console.WriteLine("检查电话号码是否合法");
if (number.Length == )
{
Console.WriteLine("拨打电话");
}
if (number.Substring(, ).Contains(""))
{
Console.WriteLine("显示电话号码运营商,中国联通");
}
} //符合职责单一的拨打电话方法哟
public void SRPCallPeople(string number)
{
CheckNumber(number);
Call(number);
ShowOperator(number);
} private bool CheckNumber(string number)
{
Console.WriteLine("单一检查电话号码是否合法");
if (number.Length > )
{
return true;
}
else
{
return false;
}
}
private void Call(string number)
{
Console.WriteLine("单一拨打电话");
} private void ShowOperator(string number)
{
if (number.Substring(, ).Contains(""))
{
Console.WriteLine("单一显示电话号码运营商,中国联通");
}
} public void Hangup()
{
Console.WriteLine("通话结束");
} public void TranData()
{
throw new NotImplementedException();
} public void Charge()
{
Console.WriteLine("Iphone6充电ing");
} public void Display()
{
throw new NotImplementedException();
}
} public class XiaoMiM5 : IUSB_Type_C
{
public void TranData()
{
throw new NotImplementedException();
} public void Charge()
{
Console.WriteLine("小米M5充电ing");
} public void Display()
{
throw new NotImplementedException();
}
} public class MeiZu : ITranData, ICharge, IDisplay
{ public void TranData()
{
throw new NotImplementedException();
} public void Charge()
{
Console.WriteLine("魅族充电ing");
}
public void Display()
{
throw new NotImplementedException();
}
} public class HuaWei : ITranData, ICharge, IDisplay
{ public void TranData()
{
throw new NotImplementedException();
} public void Charge()
{
Console.WriteLine("华为充电ing");
}
public void Display()
{
throw new NotImplementedException();
}
} public class FlashMeiZu : IFlashCharge, ITranData, IDisplay
{ public void TranData()
{
throw new NotImplementedException();
}
public void Display()
{
throw new NotImplementedException();
}
public void FlashCharge()
{
Console.WriteLine("小米闪充,充电5分钟,通话2小时!~");
}
} public interface IUSB_Type_C
{
void TranData();
void Charge();
void Display();
} public interface ITranData
{
void TranData();
} public interface ICharge
{
void Charge();
}
public interface IFlashCharge
{
void FlashCharge();
} public interface IDisplay
{
void Display();
}
}
单一指责原则(Single Responsibility Principle) SRP的更多相关文章
- 面象对象设计原则之一:单一职责原则(Single Responsibility Principle, SRP)
单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小.单一职责原则定义如下:单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域 ...
- 单一职责原则(Single Responsibility Principle,SRP)
定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的 ...
- 设计模式六大原则(一):单一职责原则(Single Responsibility Principle)
单一职责(SRP)定义: 不要存在多于一个导致类变更的原因,通俗的说,即一个类只负责一项职责. 问题由来: 类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可 ...
- 【设计原则和编程技巧】单一职责原则 (Single Responsibility Principle, SRP)
单一职责原则 (Single Responsibility Principle, SRP) 单一职责原则在设计模式中常被定义为“一个类应该只有一个发生变化的原因”,若我们有两个动机去改写一个方法,那这 ...
- 设计模式原则(1)--Single Responsibility Principle(SRP)--单一职责原则
1.定义: 不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 2.使用场景: 如果类A有两个职责:d1,d2.当职责d1需要修改时,可能会导致原本运行正常的职责d2功能产生问题. ...
- 01-01.单一职责原则(Single Responsibility)
1.基本介绍 对于类来说的,就是一个类,应该只负责一项职责(一个类只管一件事). 如类A负责两个不同职责:职责1,职责2. 当职责1需求变更而改变A时,可能造成职责2执行错误,所以需要将类A的粒度分解 ...
- 单一职责原则(Simple responsibility pinciple, SRP)
一个类只负责一个功能领域中的相应职责 未完待续
- 单一职责原则(Single Responsibility Principle)
单一职责原则(SRP:The Single Responsibility Principle) 一个类应该有且只有一个变化的原因. There should never be more than on ...
- 面向对象设计原则 单一职责原则(Single responsibility principle)
单一职责原则(SRP:Single responsibility principle) 又称单一功能原则,面向对象的基本原则之一.它规定 一个类应该只有一个发生变化的原因. 该原则由罗伯特·C·马丁( ...
随机推荐
- (转)基于MVC4+EasyUI的Web开发框架形成之旅--界面控件的使用
原文地址:http://www.cnblogs.com/wuhuacong/p/3317223.html 在前面介绍了两篇关于我的基于MVC4+EasyUI技术的Web开发框架的随笔,本篇继续介绍其中 ...
- duilib入门简明教程 -- 第一个程序 Hello World(3)
小伙伴们有点迫不及待了么,来看一看Hello World吧: 新建一个空的win32项目,新建一个main.cpp文件,将以下代码复制进去: #include <windows.h> #i ...
- 阿里 vs. 腾讯,谁的收购更有眼光?
近年来我们国内企业高速发展,各大集团纷纷收购其他公司发展自己,在这么多的集团收购里面尤其以阿里巴巴和腾讯的收购引人注目.在2014年里阿里巴巴先后投资了中信,美国奢侈品电子商务lstdibs,高德,优 ...
- 手机打车APP的机遇与挑战
所谓打车APP,就是个能安装在手机上的打车软件.原理是通过GPS进行定位,能够搜索附近的空车信息然后反馈给用户.同样的,空车信息也会反馈给用户.一般这种啊APP都是跟地图类软件一起的.比如百度地图,谷 ...
- C语言编程学习开发的俄罗斯方块小游戏
C语言是面向过程的,而C++是面向对象的 C和C++的区别: C是一个结构化语言,它的重点在于算法和数据结构.C程序的设计首要考虑的是如何通过一个过程,对输入(或环境条件)进行运算处理得到输出(或实现 ...
- sqlServer组合主键
sqlServer 组合主键 创建表时: create table Person ( Name1 ) not null ,Name2 ) not null primary key(Name1,Na ...
- 「BZOJ 2142」礼物
题目链接 戳这 Title Solution 这一道题显然可以看出公式为: \[ans=C_{n}^{w_1}*C_{n-w}^{w_2}*...*C_{w_m}^{w_m}\] 然后就可以用扩展Lu ...
- 内联函数背景、例子、与普通函数的区别及要注意的地方 ------新标准c++程序设计
背景: 使用函数能够避免将相同代码重些多次的烦恼,还能减少可执行程序的体积,但也会带来程序运行时间上的开销.函数调用在执行时,首先在栈中为形参和局部变量分配存储空间,然后还要将实参的值复制给形参,接下 ...
- 「CF622F」The Sum of the k-th Powers「拉格朗日插值」
题意 求\(\sum_{i=1}^n i^k\),\(n \leq 10^9,k \leq 10^6\) 题解 观察可得答案是一个\(k+1\)次多项式,我们找\(k+2\)个值带进去然后拉格朗日插值 ...
- 洛谷P3236 [HNOI2014]画框(最小乘积KM)
题面 传送门 题解 我似乎连\(KM\)都不会打啊→_→ 和bzoj2395是一样的,只不过把最小生成树换成\(KM\)了.因为\(KM\)跑的是最大权值所以取个反就行了 //minamoto #in ...