面向对象设计原则:单一职责原则(The Single Responsibility Principle)

热爱生活、享受娱乐、专注技术,欢迎关注微信公众号QGer,我们一起见证成长!

什么是单一职责原则?

- 官方解释:一个类应该只有一种改变的原因

- 通俗解释:一个类被修改、拓展的时候,应该只能因为一种职责(功能)的扩展,而不应该有第二种职责导致类的修改,一个也不能有另一种职责存在。

为什么遵循单一职责原则?

  • 降低类的复杂度,一个类负责一种职责,逻辑上也变得直观简单。
  • 使代码变得灵活,提高系统的维护性。
  • 变更的风险降低,有需求就会有变更,单一职责原则可降低变更的影响面。
  • 保持松耦合,提供内聚。

如何使用单一职责原则?

单一职责原则是设计原则中最简单的,最直观的,但是,往往一些很有经验的开发者在比较负责的项目开发的时候,也经常会犯下错误,一个负责两个或多个职责。因为代码是经常发生变更的,有时候为了快速完成开发,或者代码逻辑并不复杂,改动不大,可能在代码逻辑上不遵循这一原则,或者在方法层次不遵循这一原则,视情况而定,在某些情况下是可行的。但更有甚者,在类层次、包层次不遵循这一原则,导致代码可读性差,影响面增大,脆弱难以维护,这是没有经验的程序员才会干出的事情。

简单举例:现在我在一个开发一个即时聊天工具,现在我想实现发送消息功能,我需要一个SendMessager类。

     public class SendMessager{
          public boolean sendMessage(String content, String sender, String receiver){
               println(sender + " send message to " + receiver);
               return true;
          }
     }

这里没什么问题,但是你发现发送内容并没有经过加密,你想要有包含数字的内容被加密后再发送。于是呼

     public class SendMessager{
          public boolean sendMessage(String content, String sender, String receiver){
               /**
                    如果包含数字
               */
               if(content contains numeric){
                    content = md5(content);
                    println(sender + " send message to " + receiver);
                    return true;
               }
               println(sender + " send message to " + receiver);
               return true;
          }
     }  
 或者方法层次上遵循单一职责原则:
     public class SendMessager{
          public boolean sendMessage(String content, String sender, String receiver){
               println(sender + " send message to " + receiver);
               return true;
          }
               /**
                    发送经过加密后的消息
               */
          public boolean sendEncryptedMessage(String content, String sender, String receiver){
                    content = md5(content);
                    println(sender + " send message to " + receiver);
                    return true;
          }
     } 
 或者完全遵循单一原则:
     public class SendMessager{
          public boolean sendMessage(String content, String sender, String receiver){
               println(sender + " send message to " + receiver);
               return true;
          }
     }
     public class SendMd5Messager{
               /**
                    发送经过加密后的消息
               */
          public boolean sendMessage(String content, String sender, String receiver){
                    content = md5(content);
                    println(sender + " send message to " + receiver);
                    return true;
          }
     }    

在这样简单的逻辑上看,似乎这三种情况都是可行并且也不怎么影响代码的负责度。但是,当职责分化的时候,或者需求增加的时候,三种设计的影响差别就很明显了。

  • 比如,现在我想增加一种加密方式,用RSA算法来加密,那么第一种实现,将会影响到代码层次上的变更,第二种实现,会影响到方法层次上的变更,第三种,并没有产生什么影响,仅仅是新增一个SendRSAMessager类而已。
  • 因此,我个人认为,三种设计层次,视职责分化的可能性而定,方法层次上的设计是可以被允许的,最好是用第三种方法,遵循单一职责原则。
时间: 2024-10-11 18:20:42

面向对象设计原则:单一职责原则(The Single Responsibility Principle)的相关文章

设计模式--6大原则--单一职责原则

单一职责原则(Single Responsibility Principle),简称SRP. 定义: There should never be more than one reason for a class to change. 应该有且仅有一个原因引起类的变更. 有时候,开发人员设计接口的时候会有些问题,比如用户的属性和用户的行为被放在一个接口中声明.这就造成了业务对象和业务逻辑被放在了一起,这样就造成了这个接口有两种职责,接口职责不明确,按照SRP的定义就违背了接口的单一职责原则了. 下

六大设计原则——单一职责原则【Single Responsibility Principle】

声明:本文内容是从网络书籍整理而来,并非原创. 用户管理的例子 先看一张用户管理的类图: 再看一眼上面的图,思考:这样合理吗? 这个接口是一个很糟糕的设计! 用户的属性和行为竟然混合在一起!!! 正确的做法是把用户的信息抽取成一个业务对象(Bussiness Object,简称 BO),把行为抽取成另外一个接口中,我们把这个类图重新画一下: 这样划分成了两个接口,IUserBO 负责用户的属性,IUserBiz 负责用户的行为,因为是面向的接口编程,所有当产生了这个 UserInfo 对象之后,

设计模式.设计原则-单一职责原则

1:什么情况下 会使用到单一职责原则设计模式? 当同一个类中同时出现业务和属性等代码的时候或者当同一个类中要做多样事情的时候,就需要将其抽象出来,做成多种不同的接口,以便后续方便扩展单一职责:原则要求一个接口或者类只有一个原因引起变化,也就是一个接口或者类只有一个职责,它就负责一件事情 单一原则的好处:类的复杂性降低,实现责任清晰明确可读性高,复杂性降低可维护性提高,可读性提高变更引起风险性降低,变更是必不可少的,如果接口修改,只影响对应的实现类,对其他接口没有影响 如上图所示:Perion类这

Java设计原则—单一职责原则(转)

定义: 应该有且仅有一个原因引起类的变更. There should never be more than one reason for a class to change. 优点: 1.类的复杂性降低,实现什么职责都有清晰明确的定义: 2.可读性提高,复杂性减低,可读性当然提高: 3.可维护性提高,可读性提高,可维护性当然提高: 4.变更引起的风险减低,变更是必不可少的,如果接口的单一职责做得好,一个接口修改只对相应的类有影响,对其他接口无影响,这对系统的扩展性.维护性都有非常大的帮助. 注意

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

定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责.  问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾.因为它太简单了.稍有经验的程序员即

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

定义 就一个类而言,应该仅有一个引起它变化的原因.通俗的说,一个类只负责一项职责. 问题的由来 手机的功能多,但是每一项的功能都不强: 拍摄功能-->专业的摄像机和照相机 手机游戏-->PSP 网络摄像头-->专业摄像头 GPS功能-->专业GPS导航系统 每一个职责都是一个变化的轴线,当需求变化时会反映为类的职责的变化,如果一个类的承担的职责多于一个,那么引起她变化的原因就有多个,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力,从而导致脆弱的设计. 解决方案 遵循单一职

编码最佳实践——单一职责原则

SOLID是一组最佳编码实践的首字母缩写 S 单一职责原则 O 开放与封闭原则 L Liskov(里式)替换原则 I 接口分离原则 D 依赖注入原则 同时应用这些最佳实践,可以提升代码适应变更的能力.但是凡事要有度,过度使用虽然可以让代码有很高的自适应能力,但是会导致层次粒度过小而难以理解或使用,还会影响代码的可读性. 单一职责原则 单一职责原则(Single Responsibility principle)要求开发人员编写的代码有且只有一个变更理由.如果一个类有多个变更理由,那么它就具有多个

【设计模式之禅】第1章 单一职责原则

1.1 我是"牛"类,我可以担任多职吗 SRP 单一职责原则的英文名称是Single Responsibility Principle,简称是SRP. RBAC模型(Role-Based Access Control)基于角色的访问控制        通过分配和取消角色来完成用户权限的授予和取消,使动作主体(用户)与资源的行为(权限)分离 单一职责原则的定义是:应该有且仅有一个原因引起类的变更. 1.2 绝杀技,打破你的传统思维 SRP的原话解释是:        There shou

单一职责原则

什么是单一职责原则 什么是单一职责原则? 单一职责原则的英文名称是Single Responsibility Principle,简称SRP.SRP的原话解释是:There should never be more than one reason for a class to change. 也就是说一个类,只有一个引起它变化的原因.应该只有一个职责.每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起. 这会导致脆弱的设计.当一个职责发生变化时,可能会影响其它的职责

Android与设计模式:用单一职责原则为Activity解耦

一.什么是单一职责原则 单一职责原则(SRP:Single responsibility principle)又称单一功能原则,其定义为:一个类,应该只有一个可以导致变化的原因.光看概念会让人很头疼,我先讲点小例子吧: 二.单一职责原则能解决什么问题 回顾我们的 Android 开发经历,很多人都会发现 Activity 类中的代码总会不知不觉地变得很多,这会让读我们代码的人非常痛苦.而造成这种情况的其中一个原因是:Activity 中需要与用户进行大量的交互,用户的操作会改变 Activity