精华内容
下载资源
问答
  • 主要为大家详细介绍了单一职责原则的相关资料,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
  • 单一职责模式例子。

    2017-12-25 11:43:56
    设计模式6大原则之单一职责械,SIP,一个类只负责处理一个业务,
  • 单一职责原则可以使类的复杂度降低,实现什么职责都有清晰明确的定义;类的可读性提高,复杂度降低;可读性提高了,代码就更容易维护;变更(需求是肯定会变)引起的风险(包括测试的难度,以及需要测试的范围)降低...
  • NULL 博文链接:https://lijie-insist.iteye.com/blog/2190970
  • 单一职责原则简介

    2020-08-03 17:51:55
    参考文章:面向对象编程的六大原则(1)--单一职责原则 1. 什么是单一职责  单一职责原则(Single responsibility principle,简称SRP),顾名思义,是指一个类或者一个模块应该有且只有一个职责,它是面向对象...

    参考文章:面向对象编程的六大原则(1)--单一职责原则

    1. 什么是单一职责

      单一职责原则(Single responsibility principle,简称SRP),顾名思义,是指一个类或者一个模块应该有且只有一个职责,它是面向对象编程六大原则之一。

    2. 单一职责的粒度

      单一职责的粒度,可以是某个方法、某个类、某个程序包甚至某个功能、某个模块(甚至某个系统),每一个层次上都可以进行单一职责设计。下面来举个例子说明一下:

      模块级别:某购物平台,包含如下几个模块:用户模块、商品模块、订单模块、库存模块、运输模块、支付模块,每一个模块都已本身的职责:用户模块负责用户相关的功能,商品模块负责商品的管理等等;

      功能级别:在模块内部,比如用户模块,根据用户相关职责划分,又划分为用户管理、注册、登录等不同的功能,他们的职责也都是各不相同的;

      程序包级别:在用户管理中,又可以根据层次不同划分为持久化层、业务逻辑层、UI层,其中每一层基本上就是一个程序包,持久化层负责数据持久化相关(和数据库打交道,数据的CRUD(增删改查)),业务逻辑层负责用户管理相关的业务逻辑(比如修改密码),UI层负责用户界面交互;

      类级别:在持久化层内部,又可以根据职责不同划分为:数据库连接类(负责数据库连接的构造)、持久化类(负责数据的CRUD操作)、数据缓存类(负责数据缓存的处理)等;

      方法级别:在持久化类中,又可以划分为查询数据方法(负责查询数据)、检索数据方法(负责检索数据)、新增数据方法(负责插入数据)、 删除数据方法(负责删除数据)、修改数据方法(负责修改数据)。有些复杂场景,甚至建议增删改查每一个逻辑都放到不同的类中;

      方法级别二:在查询数据方法中,又可以根据查询的逻辑步骤划分为不同的二级方法:解析查询条件方法、构造Sql方法、执行Sql方法、构造返回实体方法;每个方法可以借着这个思路再往下细化;

    3. 单一职责的优点

    1. 增强功能的稳定性
      单一职责能够增强功能稳定性、健壮性,适应程序的变化,避免修改一段逻辑时,对其他逻辑造成影响。例如:一个类或者一个方法,承担了多个职责:职责A、职责B、职责C...职责N。如果在维护过程中,修改之职责A对应的逻辑,就很有可能对职责B、C等其他职责逻辑造成影响,最终不利于功能的稳定性。
    2. 提升复用能力
      使用单一职责,有一某一个类或者方法都是对应的它本身的唯一职责,已经是实现某个职责的最小粒度,所以它可以提供给任何需要该职责地方调用,从而提升了复用能力。
    3. 降低程序复杂度
      由于单一职责原则是根据职责来设计,每一个类或者方法只实现某一特定的逻辑,粒度划分的合适的话,每一个类基本上只有几行、至多几十行代码,程序复杂度会被大大降低;
    4. 提升可读性
      每一个程序包、类、方法职责明确后,我们在阅读代码时,我们可以通过方法名就能知道某个方法是干什么的(可以不用知道具体的细节),它内部用到的方法是干什么的,有助于我们在某一层次上思考代码逻辑是否正确、完整,而不用受某一具体细节逻辑的影响。

     4. 具体实践

      在用户管理持久化层,如果要适配不同类型的数据库(比如要支持SqlServer、Oracle、MySql等),不同类型的数据库,其语法结构都有一些差异,比如插入数据方法,插入sql的语法是不同的。我们可能按照如下代码实现:

      以下是用户信息的结构:

    public class UserInfo {
      public string ID { get; set; }
      public string Code { get; set; }
      public string Name { get; set; }
    }

      以下是用户持久化的新增数据方法:

    public class UserDac {
      Database GetDatabase() {
        /*获取Database连接的逻辑*/
      }
    
      //新增用户
      public void AddUser(UserInfo userInfo) {
        Database db = GetDatabase();
        string insertSql = string.Empty;
        
        switch (db.DbType) {
          case DBType.SqlServer:
            insertSql = "Sql A";
            break;
          case DBType.Oracle:
            insertSql = "Sql B";
            break;
          default:
            throw new NotSupportedException("DBType");
        }
        
        db.ExecuteSql(insertSql); 
      }
    }

      在上面的例子中,我们看似应该是一个比较简单并且合理的结构。但是假如有以下需求场景:

    1. 业务中添加了新的字段,需要修改 InsertSql(在Sql中添加新字段部分);
    2. 我需要添加一种新的数据库类型支持(假如需要支持开源的MySql),新的数据库类型中,Sql语法也是不相同的;

      两个场景都需要修改以上的代码,这说明上面这段代码承担了两个职责,违背了单一职责原则。

      从上面的方法中,我们可以看到 ,上面方法承担了两个职责:拼接插入Sql;适配不同的数据库类型。我们可以按照如下方式进行修改(修改中用到了设计模式中的策略模式)。

      用户信息的结构不变:

    public class UserInfo {
      public string ID { get; set; }
      public string Code { get; set; }
      public string Name { get; set; }
    }

       第一步:我们添加一个获取Sql的策略,如下结构:

    public interface IUserSqlStrategy {
      string GetInsertSql(UserInfo userInfo);
    }

      第二步:我们添加SqlServer的策略实现:

    public class SqlServerUserSqlStrategy implements IUserSqlStrategy {
      public string GetInsertSql(UserInfo userInfo) {
        return "Sql A";
      }
    }

      第三步:相应的,我们添加Oracle、MySql的的实现类:

    public class OracleUserSqlStrategy implements IUserSqlStrategy {
      public string GetInsertSql(UserInfo userInfo) {
        return "Sql B";
      }
    }
    
    public class MySqlUserSqlStrategy implements IUserSqlStrategy {
      public string GetInsertSql(UserInfo userInfo) {
        return "Sql C";
      }
    }

      第四步,我们添加策略工厂,来根据不同的数据库类型获取不同的策略实现:

    public class UserSqlStrategyFactory {
      public static IUserSqlStrategy GetUserSqlStragety(DBType dbType) {
        switch (dbType)  {
          case DBType.SqlServer:
            return new SqlServerUserSqlStrategy();
          case  DBType.Oracle:
            return new OracleUserSqlStrategy();
          case DBType.MySql:
            return new MySqlUserSqlStrategy();
          default:
            throw new NotSupportedException("DBType");
        }
      }
    }

      最后,执行插入逻辑中,调用策略工厂获取策略,然后根据相应的策略获取不同的Sql实现:

    public class UserDac {
      Database GetDatabase() {
        /*获取Database连接的逻辑*/
      }
    
      //新增用户
      public void AddUser(UserInfo userInfo) {
        Database db = GetDatabase();
        var strategy = UserSqlStrategyFactory.GetUserSqlStragety(db.DbType);
        string insertSql = strategy.GetInsertSql(userInfo);
        db.ExecuteSql(insertSql); 
      }
    }

      以上是所有的代码实现,通过策略模式,将不同数据库类型的实现拆分到不同的策略实现类中,这样拼接插入Sql逻辑与适配不同数据库逻辑两个职责拆分开来。

     总结

      通过单一职责原则,将程序实现拆分到不同的类(或者方法)中,这样,以后的变化都只影响要修改的主责,而不会影响到其他职责,最终达到提升稳定性的目的。

     

    展开全文
  • 单一职责原则

    千次阅读 2021-03-12 15:31:36
    1. 单一职责原则的定义 单一职责原则(Single Responsibility Principle,SRP) 又称单一功能原则,由罗伯特·C.马丁(Robert C. Martin)于《敏捷软件开发:原则、模式和实践》一书中提出的。这里的职责是指类变化...

    1. 单一职责原则的定义

    单一职责原则(Single Responsibility Principle,SRP)

    又称单一功能原则,由罗伯特·C.马丁(Robert C. Martin)于《敏捷软件开发:原则、模式和实践》一书中提出的。这里的职责是指类变化的原因,单一职责原则规定一个类应该有且仅有一个引起它变化的原因,否则类应该被拆分(There should never be more than one reason for a class to change)。

    该原则提出对象不应该承担太多职责,如果一个对象承担了太多的职责,至少存在以下两个缺点:

    1. 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力;
    2. 当客户端需要该对象的某一个职责时,不得不将其他不需要的职责全都包含进来,从而造成冗余代码或代码的浪费。

    2. 单一职责原则的优点

    单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。

    • 降低类的复杂度。一个类只负责一项职责,其逻辑肯定要比负责多项职责简单得多。
    • 提高类的可读性。复杂性降低,自然其可读性会提高。
    • 提高系统的可维护性。可读性提高,那自然更容易维护了。
    • 变更引起的风险降低。变更是必然的,如果单一职责原则遵守得好,当修改一个功能时,可以显著降低对其他功能的影响。

    3. 单一职责原则的实现方法

    单一职责原则是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。下面以交通工具运行方式为例介绍单一职责原则的应用。

    【例】众所周知,交通工具有汽车这种陆地上的,也有飞机这种天上的,也有轮船,如果控制交通工具的类把所有交通工具的运行都放到一个方法去执行那么会出现这种情况:

    /**
     * @Author lizeyu
     * @Date 2020/4/7 9:38
     */
    public class single_test {
        public static void main(String[] args) {
            Vehicle car = new Vehicle("汽车");
            car.run(car.getname());
            Vehicle airPlane = new Vehicle("飞机");
            airPlane.run(airPlane.getname());
            Vehicle ship = new Vehicle("轮船");
            ship.run(ship.getname());
        }
    }
    
    class Vehicle{
        private String name;
    
        public Vehicle(String name) {
            this.name = name;
        }
    
        public String getname() {
            return name;
        }
    
        public void setname(String name) {
            this.name = name;
        }
    
        public void run(String name) {
            System.out.println(name+"交通工具是在陆地上运行");
        }
    }
    

    运行结果

    汽车交通工具是在陆地上运行
    飞机交通工具是在陆地上运行
    轮船交通工具是在陆地上运行

    由上面我们可以知道一个交通工具的总类去负责每种类型的交通工具的运行方式,它负责的太宽了,导致运行出现逻辑问题。我们大家都明白目前交通方式分为三类海陆空,我们讲交通工具类分为陆地交通水上交通天空交通,每一个类负责各自的运行方式。

    第一次优化

    /**
     * @Author lizeyu
     * @Date 2020/4/7 9:38
     */
    public class single_test {
        public static void main(String[] args) {
            LandVehicle car = new LandVehicle("汽车");
            car.run(car.getName());
    
            AirVehicle airPlane = new AirVehicle("飞机");
            airPlane.run(airPlane.getName());
    
            WaterVehicle ship = new WaterVehicle("轮船");
            ship.run(ship.getName());
        }
    }
    
    class LandVehicle{
        private String name;
    
        public LandVehicle(String name) {
            this.name = name;
        }
    
        public String getName() {
            return name;
        }
    
        public void setName(String name) {
            this.name = name;
        }
    
        public void run(String name) {
            System.out.println(name+"交通工具是在陆地上运行");
        }
    }
    
    class AirVehicle{
        private String name;
    
        public AirVehicle(String name) {
            this.name = name;
        }
    
        public String getName() {
            return name;
        }
    
        public void setName(String name) {
            this.name = name;
        }
    
        public void run(String name) {
            System.out.println(name+"交通工具是在天上运行");
        }
    }
    
    class WaterVehicle{
        private String name;
    
        public WaterVehicle(String name) {
            this.name = name;
        }
    
        public String getName() {
            return name;
        }
    
        public void setName(String name) {
            this.name = name;
        }
    
        public void run(String name) {
            System.out.println(name+"交通工具是在水上运行");
        }
    }
    

    运行结果

    汽车交通工具是在陆地上运行
    飞机交通工具是在天上运行
    轮船交通工具是在水上运行

    这样看起来就正常了,但是又有一个问题值得我们思考,一个很简单的问题居然需要创建三个类,内存消耗太大。我们有没有方法不需要这么浪费内存又做到单一职责呢?

    第二次优化

    /**
     * @Author lizeyu
     * @Date 2020/4/7 9:38
     */
    public class single_test {
        public static void main(String[] args) {
            Vehicle transition = new Vehicle();
    
            transition.landRun("汽车");
            transition.airRun("飞机");
            transition.waterRun("轮船");
        }
    }
    
    class Vehicle{
    
        public void airRun(String name) {
            System.out.println(name+"交通工具是在天上运行");
        }
    
        public void waterRun(String name) {
            System.out.println(name+"交通工具是在水上运行");
        }
    
        public void landRun(String name) {
            System.out.println(name+"交通工具是在陆地上运行");
        }
    }
    

    运行结果

    汽车交通工具是在陆地上运行
    飞机交通工具是在天上运行
    轮船交通工具是在水上运行

    整体看我们并没有严格按照单一职责原则,这是什么意思呢?我们看到我们在客户端里,我们构造了海陆空三个类,为什么要这么做呢?因为我们交通工具类负责了三个职责。显然在类级别上违反了单一职责原则,但是我们这样做代码简单了很多,满足了程序设计的易读性。扩展简单,如果这时候又将汽车分为更细的类,那马我们只需要更改客户端的代码,而封装好的方法不需要改动,显然符合可扩展性。其它各种性质都可以满足。

    这么看来我们可以得出结论,第二次优化以后虽然在类级别违反了单一职责原则,但是在方法上遵循了该原则,而且这样使得程序变得更加简单、更加适合使用。

    4. 总结

    单一职责原则注意事项和细节

    • 降低类的复杂度,一个类只负责一项职责
    • 提高类的可读性,可维护性
    • 降低变更引起的风险
    • 通常情况下,我们应当遵守单一职责原则,只有逻辑足够简单,才可以在代码(类)级别违反单一职责原则;只有类中方法数量足够少,才可以在方法级别违反单一职责原则。
    展开全文
  • Java设计模式-单一职责原则

    千次阅读 2019-03-01 16:27:11
    单一职责原则 定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。 问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行...

    单一职责原则 【Single Responsibility Principle】

      定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。
    问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。

      解决方案:遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T2时,也不会使职责P1发生故障风险。

      说到单一职责原则,很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则,因为这是常识。在软件编程中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,但是即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。所谓职责扩散,就是因为某种原因,职责P被分化为粒度更细的职责P1和P2。

      举例说明:只要做过项目,肯定要接触到用户、机构、角色管理这个模块,我们今天要讲的是用户管理,管理用户的信息,增加机构(一个人属于多个机构),增加角色等,用户有这么的信息和行为要维护,我们就把这些写到一个接口中,都是用户管理类嘛,我们先来看类图:
    在这里插入图片描述
      太easy的类图了,我相信即使一个初级的程序员也可以看出这个接口设计的有问题,用户的属性(Properties)和用户的行为(Behavior)没有分开,这是一个严重的错误!非常正确,确实是这个接口设计的一团糟,应该把用户的信息抽取成一个业务对象(BussinessObject,简称B0),把行为抽取成另外一个接口中,我们把这个类图重新画一下:

    在这里插入图片描述
      这个类图看起来完全满足了类和接口的单一职责要求,非常符合标准,但是我相信你在设计的时候肯定不会采用这种方式,一个用户类要把把两个IUserB0和IUserBiz组合在一块才能使用,组合是一种强耦合关系,你和我都是有共同的生命期,这样的强耦合关系还不如使用接口实现的方式呢,而且还增加了类的复杂性,多了两个类呀,我们修改一下类图:
    在这里插入图片描述  重新拆封成两个接口,IUserB0负责用户的属性,简单的说就是IUserB0的职责是收集和反馈用户的属性信息;IUserBiz负责用户的行为,完成用户的信息的维护和变更。各位可能要问了,这个和我实际的工作中用到的User类还是有差别的呀,别着急,我们先来想一想分拆成两个接口怎么使用,想清楚了,我们看是面向的接口编程,所有呀你产生了这个UserInfo对象之后,你当然可以把它当IUserB0接口使用,当然也可以当IUserBiz接口使用,这要看你在怎么地方使用了,你要获得用户想信息,你就当时IUserB0的实现类;你要是想维护用户的信息,就当是IUserBiz的实现类就成了,类似于如下代码:

    IUserBiz userInfo=new UserInfo();
    //我要赋值了,我就认为它是一个纯粹的
    BO IUserBO userB0=(IUserBO)userInfo;
    userBO.setPassword("abc");
    //我要执行动作了,我就认为是一个业务逻辑类
    IUserBiz userBiz=(IUserBiz)userInfo;
    userBiz.deleteUser();
    

      这样的设计,一个用户实现了两个接口,把两个职责融合一个类中,你会觉得这个UserInfo有两个原因引起变化了呀,是的是的,但是别忘记了我们是面向接口编程,我们对外公布的是接口而不是实现类;而且如果真要实现类的单一职责的话,这个就必须使用了上面组合的方式了,那这个会引起类间耦合过重的问题(我们等会再说明这个问题,继续往下看)。那使用了单一职责原则有什么好处呢?

      单一职责使用于接口、类,同时也使用方法,什么意思呢?一个方法尽可能做一件事情,比如一个方法修改用户密码,别把这个方法放到“修改用户信息”方法中,这个方法的颗粒度很粗,比如这个一个方法:
    在这里插入图片描述

      在IUserManager中定义了一个方法叫changeuser,根据传递的type不同,把可变长度参数changeOptions修改到userBo这个对象上,并调用持久层的方法保存到数据库中。
    这种方式要简单的多。但是却存在着隐患:每次新增、移除某个type都需要对原有代码进行修改啊;进而可能影响到其他type的操作,这种修改方式直接在代码级别上违背了单一职责原则,虽然修改起来最简单,但方法职责不清晰,不单一,隐患却是最大的。一般方法设计成这样的:

    在这里插入图片描述

      你要修改用户名称,就调用changeUserNane方法,你要修改家庭地址就调用changellomeAddress,你要修改单位单户就调用changeofficeTel方法,每个方法的职责就非常清晰,这也是一个良好的设计习惯。

      对于接口,我们在设计的时候一定要做到单一,但是对于实现类就需要多方面考虑了,考虑项目环境,考虑工作量,考虑人员的技术水平,考虑硬件的资源情况等等,最终融合的结果是经常违背这一单一原则。生搬硬套单一职责原则会引起类的剧增,给维护带来非常多的麻烦;而且过分的细分类的职责也为人为的制造系统的负责性,本来一个类可以实现的行为非要拆成两个,然后使用聚合或组合的方式再耦合在一起,这个是人为制造了系统的复杂性,所以原则是死的,人是活的,这句话是非常好的。但是我相信随着技术的深入,单一职责原则必然会深入到项目的设计中去,而且这个原则是那么的简单,简单的我都不知道该怎么更加详细的去描述,单从字面上大家都应该知道是什么意思,单一职责嘛!

      遵循单一职责原的优点有:
      可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;
      提高类的可读性,提高系统的可维护性;
      变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。
      需要说明的一点是单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都适用单一职责原则。

    展开全文
  • 单一职责

    2018-06-20 22:13:23
    其中的一点收获是单一职责。我封装了一层Toolbar的原生样式改善层,一层自定义View添加层,其功能拆分得可谓完美,在无数次划分职责的思考中最终选择了这样的划分,真的很棒。第一层,职责是Toolbar的原生样式,他的...

    仅作个人记录


    最近封装了一个项目的Toolbar,在开发中有着各种各样的收获,比如对建造者的意义的深入理解,对Toolbar源码的阅读与Toolbar布局规则的改善。。。其中的一点收获是单一职责。

    我封装了一层Toolbar的原生样式改善层,一层自定义View添加层,其功能拆分得可谓完美,在无数次划分职责的思考中最终选择了这样的划分,真的很棒。

    第一层,职责是Toolbar的原生样式,他的NavigationIcon、Title字体都是我需要的,可是受到的限制很大,我就通过某些手段,突破了这些限制,可以说这一层封装后,Toolbar依然是Toolbar,但是他的样式更灵活了,比如Title可以居中了,右边也有了一模一样的ImageButton。可以说相当于官方的修改了,等同于官方修复了他样式不够灵活的bug。

    第二层,在更多的位置上可以插入View,算是自定义View层。

    这样划分的好处在于,第一层等同于bug修复,好像官方修复了不足之处一样。我现在做的才是真正的Toolbar封装。这是运气好,第一层功能被吞并了,使得这次开发太舒服了。

    不过就算我是封装的2层,也是很舒服了。这样维护起来,别人阅读起来,使用者使用起来,都很舒服,因为每一层都对应一个功能,我如果写在一起,或者分层不明确,日后修改,头都要大了。现在好了,改动非常有目标性,非常清晰。


    单一职责

    难道我会谈事件分发、OkHttp和网络分层的责任链模式来述说单一职责?当然不是。这些已经算是很抽象了,离真正开发似乎很远。近一点,MVP难道不是单一职责吗?数据层,组织层,UI层,这样一分,简直美到心醉。以后维护起来是一种享受!!(当然了,MVP还用了接口隔离的思想)

    展开全文
  • SOLID:SOLID原则并非单纯的1个原则,而是由5个设计原则组成,它们分别是:单一职责原则、开闭原则、里式替换原则、接口隔离原则和依赖反转原则,SOLID由5个设计原则的头一个字母组成。 如何理解单一职责原则(SRP)...
  • 主要介绍了Java设计模式编程中的单一职责原则,这在团队开发编写接口时经常使用这样的约定,需要的朋友可以参考下
  • 1 简介 1.1 定义 不要存在多于一个导致类变更的原因。该原则备受争议,争议之处在于对职责的定义,...以上的设计依旧很差,总不能一味堆砌 ifelse 添加鸟类,结合该业务逻辑,考虑分别实现类职责,即根据单一原则创建两
  • 软件架构-单一职责原则

    千次阅读 2020-11-20 13:48:57
    单一职责原则(Single Pesponsibility Principle, SRP)是SOLID五大设计原则最容易被误解的一个。也许是名字的原因,很多程序员根据SRP这个名字想当然地认为这个原则是指:每个模块应该只做一件事。但这只是一个面向...
  • 本文我们将讨论面向对象编程中著名的 SOLID 原则之一的单一职责原则。我们将深入讲解什么是单一职责原则和在设计代码时如何实现它,最后将如何避免滥用此设计规则。单一职责的英文表达为 Single Responsibility ...
  • Bob大叔提出并发扬了S.O.L.I.D五大原则,用来更好地进行面向对象编程
  • 单一职责原则小案例

    2020-11-26 09:34:32
    交通工具类为例: 方式1: 运行结如下: 问题: 方式2: 运行结果: ...这种修改方法没有对原来的类做很大修,只是增加方法 虽然在类级别没有遵守单一职责原则,但是在方法级别仍然遵守单一职责原则 ...
  • 单一职责原则定义(Single Responsibility Principle,SRP) 单一职责原则海报 它说:"并不是因为你能,你就应该做"。为什么?因为长远来看它会带来很多管理问题。 从面向对象角度解释为:"引起类变化的因素...
  • 设计模式六大原则(一)单一职责原则单一职责的定义单一职责原则针对的问题单一职责原则的解决方案单一职责原则的认识单一职责的案例如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表...
  • 单一职责原则的理解

    2020-07-15 18:20:23
    单一职责原则(SRP: Single responsibility principle)又称单一功能原则,面向对象五个基本原则(SOLD:SRP单一责任原则、OCP开放封闭原则、LSP里氏替换原则、DIP依赖倒置原则、IsP接口分离原则)之一。它规定一个类应该...
  • 单一职责原则例子

    千次阅读 2016-11-28 21:59:50
    这篇文章写的真好定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。问题由来:类T负责两个不同的...解决方案:遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P
  • 接口隔离原则和单一职责原则区别 单一职责原则是备受争议的原则,根据不同的业务逻辑,它会将系统功能模块划分成不同种类,产生多样的接口,同时每个接口尽量只包含一个功能(方法)。 而产生争议的原因就是这个业务...
  • 单一职责原则(SRP:Single responsibility principle)又称单一功能原则 定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。 问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于...
  • 单一职责原则是面向对象设计原则中的一条 我们经常听说的一句话,叫做做好一颗“螺丝钉”,这里的螺丝钉体现了管理中的分工,
  • 单一职责原则(Single-Responsibility) 一个类,最好只做一件事,只有一个引起它的变化。 问题由来: 类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行...
  • #单一职责原则 概念 定义:不要存在多于一个导致类变更的原因 一个类、接口、方法只负责一项职责 优点:、、 案例 单一职责原则很简单,一个方法 一个类只负责一个职责,各个职责的程序改动,不影响其它程序。 这...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 87,517
精华内容 35,006
关键字:

单一职责