设计模式学习笔记(二) 设计基本原则之【单一职责原则】

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

名词解释:

1) 职责:是指类变化的原因。

2) 职责扩散:就是因为某种原因,职责P被分化为粒度更细的职责P1和P2。

3) 可变类:是指创建该类的实例后,可以对其属性进行修改。

4)不可变类:是指创建该类的实例后,不可对其属性进行修改。不可变类是线程安全的。

1、应用场景

一个类T负责两个不同的职责:职责P1、职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原来运行的职责P2功能发生故障。

2、解决方案

分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T2时,也不会使职责P1发生故障风险。

3、优点

  • 可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多。
  • 提高类的可读性,提高系统的可维护性。
  • 变更引起的风险降低,实际应用中,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。
  • 提供重用基础:代码块独立,功能单一,可以容易地重用。
  • 提供可扩展性 :依赖别的单元提供的接口,便于扩展。

4、缺点

如果严格的遵循单一职责原则,即所有的类均只负责一项职责,开发者面对的将是巨量的类(类的爆炸),如果没有一个清晰的类管理方法,势必降低系统的可读性和可维护性。

我们不可能针对每个类都设计原子级的职责。那么就会牵涉到职责的组合和划分,我们很难建立一个标准来界定如何对职责进行合理的划分。职责的大小怎么定义是个难题,什么样的职责放在一起是好的内聚也不好定义。

实际项目应用中很少能够实现单一职责原则,必须考虑可变因素与不可变因素的影响和开发效率的问题。

5、实践及示例

一般来说,接口的设计需严格遵守单一职责原则。如下图说所示,我们定义一个文件操作的接口,实现文件的基本操作

代码如下:

 1 using System;
 2 using System.Collections.Generic;
 3 using System.Text;
 4
 5 namespace LoadBalan
 6 {
 7      public  interface IFileOperator
 8     {
 9         void Open(string fileName);
10         void Write(string fileName,byte[] fileData);
11         byte[] Read();
12         void Save(string fileName);
13         void Close(string fileName);
14     }
15
16     class DisplayFile : IFileOperator
17     {
18         public void Open(string fileName)
19         {
20
21         }
22
23         public void Write(string fileName, byte[] fileData)
24         {
25         }
26         public byte[] Read() {
27
28             return null ;
29         }
30         public void Save(string fileName)
31         {
32
33         }
34        public void Close(string fileName)
35         {
36
37         }
38     }
39     class SaveFile : IFileOperator
40     {
41         public void Open(string fileName)
42         {
43
44         }
45
46         public void Write(string fileName, byte[] fileData)
47         {
48         }
49         public byte[] Read()
50         {
51
52             return null;
53         }
54         public void Save(string fileName)
55         {
56
57         }
58         public void Close(string fileName)
59         {
60
61         }
62     }
63 }

我们可以看到,IFileOperator接口包含了一系列的操作,而我们的DisplayFile类和SaveFile类都只是用到其中一部分操作,但都要实现该接口中所有的操作,造成大量的代码冗余,也影响程序的可读性。根据单一职责原则,我们做如下改进:

代码如下(设计不一定合理,只是为了说明单一职责原则):

using System;
using System.Collections.Generic;
using System.Text;

namespace LoadBalan
{
    class Lesson_SRP02
    {
        public interface IFileOperator
        {
            void Open(string fileName);
            void Close(string fileName);
        }
        public interface IFileRead
        {
            byte[] Read();
        }
        public interface IFileSave
        {

            void Write(string fileName, byte[] fileData);
            void Save(string fileName);

        }

        class DisplayFile : IFileOperator,IFileRead
        {
            public void Open(string fileName)
            {

            }

            public byte[] Read()
            {

                return null;
            }

            public void Close(string fileName)
            {

            }
        }
        class SaveFile : IFileOperator
        {
            public void Open(string fileName)
            {

            }

            public void Write(string fileName, byte[] fileData)
            {
            }

            public void Save(string fileName)
            {

            }
            public void Close(string fileName)
            {

            }
        }
    }
}

这样,DisplayFile类与SaveFile类里就没有冗余代码,各自只实现自己所需的功能。

时间: 2024-08-10 06:24:36

设计模式学习笔记(二) 设计基本原则之【单一职责原则】的相关文章

[敏捷设计]2.SRC单一职责原则

一.定义 一个类应该只有一个发生变化的原因. 二.为什么要使用SRC 因为每一个职责都是变化的一个轴线.当需求变化时,这种变化就会反映为类的职责的变化.如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个. 如果一个类承担的职责过多,就等于把这些职责耦合在了一起.一个职责的变化可能会消弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭到意想不到的破坏. 三.案例演示 考虑图中的设计. Rectangle类具有两个方法,一个方法把矩形绘制到屏幕上,另一个方

学习设计模式 - 六大基本原则之单一职责原则

设计模式总共有六大基本原则,统称为SOLID (稳定)原则,分别是S-单一职责原则(Single Responsibility Principle), O-开闭原则(Open closed Principle),L-里氏替换原则(Liskov Substitution Principle),L-迪米特法则(Law of Demeter),I-接口隔离原则(Interface Segregation Principle),D-依赖倒置原则(Dependence Invension Principl

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

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

设计模式学习笔记之设计原则

利用继承来提供对象的行为,会导致: 1.代码在多个子类中重复                            2.很难知道所有鸭子的全部行为 3.运行时的行为不易改变                            4.改变会牵一发而动全身,造成其他鸭子不想要的改变   设计原则 1 :找出应用之中可能需要变化之处,把他们独立出来,不要和那些不需要变化的代码混在一起. 注释:把会变化的部分取出并“封装”起来,以便以后可以轻易的改动或者扩充此部分,好让其他部分不受影响.代码变化引起的不

request对象的增强 装饰设计模式学习笔记二

Servlet API 中提供了一个request对象的Decorator设计模式的默认实现类HttpServletRequestWrapper , (HttpServletRequestWrapper 类实现了request 接口中的所有方法,但这些方法的内部实现都是仅仅调用了一下所包装的的 request 对象的对应方法)以避免用户在对request对象进行增强时需要实现request接口中的所有方法 使用Decorator模式包装request对象,完全解决get.post请求方式下的乱码

设计模式学习笔记(一) 概论

1.设计模式的发展史 设计模式来源于建筑行业,20世纪的70年代,Christopher Alexander在研究为解决同一个问题而设计出的不同建筑结构时,发现那些高质量的设计中有很强的相似性.提出用"模式语言"来指代这种相似性.在Christopher Alexander的经典著作<建筑的永恒之道>中,给出了关于模式的定义: 模式描述一个在我们所处环境中不断出现的问题,已经该问题的解决方案的核心.通过模式,我们可以重复利用已有的成功解决方案. (A pattern is

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

单一职责原则 定义: 不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案: 遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 单一职责原则是最简单的面向对象设计原则,它用于控制类的粒

设计模式六大原则(1):单一职责原则(转载)

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

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

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

【转】设计模式六大原则(1):单一职责原则

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