设计模式 单一职责

最新推荐文章于 2024-02-23 15:38:32 发布
最新推荐文章于 2024-02-23 15:38:32 发布
阅读量213 收藏
点赞数
分类专栏： 基础
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Hesy_H/article/details/105934812
版权

在软件组件的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。

Decorator

场景

继PM前天提出了一个需求之后，PM昨天又提出了一个新的需求。
在这里插入图片描述

思路

  • 没有经验的coder自然倾向于这样的方案
    • 原本的代码–>Component类；前天PM提出了需求，加班加点使用ConcreteComponent类( derived from Component 类 ) 进行代码实现；[没毛病]
    • 针对昨天PM提出的需求，加班加点使用ConcreteConcreteComponent类( derived from ConcreteComponent 类) 进行实现。[问题来了，没有decorator的思想就很容易掉进的陷阱] ，如下

    Stream就是Component，FileStream\NetworkStream\MemoryStream是ConcreteComponent，CryptoFileStream\BufferedFileStream 之类就是ConcreteConcreteComponent

//业务操作
class Stream{
public：
    virtual char Read(int number)=0;
    virtual void Seek(int position)=0;
    virtual void Write(char data)=0;
    
    virtual ~Stream(){}
};

//主体类
class FileStream: public Stream{
public:
    virtual char Read(int number){
        //读文件流
    }
    virtual void Seek(int position){
        //定位文件流
    }
    virtual void Write(char data){
        //写文件流
    }

};

class NetworkStream :public Stream{
public:
    virtual char Read(int number){
        //读网络流
    }
    virtual void Seek(int position){
        //定位网络流
    }
    virtual void Write(char data){
        //写网络流
    }
    
};

class MemoryStream :public Stream{
public:
    virtual char Read(int number){
        //读内存流
    }
    virtual void Seek(int position){
        //定位内存流
    }
    virtual void Write(char data){
        //写内存流
    }
    
};

//扩展操作
class CryptoFileStream :public FileStream{
public:
    virtual char Read(int number){
       
        //额外的加密操作...
        FileStream::Read(number);//读文件流
        
    }
    virtual void Seek(int position){
        //额外的加密操作...
        FileStream::Seek(position);//定位文件流
        //额外的加密操作...
    }
    virtual void Write(byte data){
        //额外的加密操作...
        FileStream::Write(data);//写文件流
        //额外的加密操作...
    }
};

class CryptoNetworkStream:public NetworkStream{
public:
    virtual char Read(int number){
        
        //额外的加密操作...
        NetworkStream::Read(number);//读网络流
    }
    virtual void Seek(int position){
        //额外的加密操作...
        NetworkStream::Seek(position);//定位网络流
        //额外的加密操作...
    }
    virtual void Write(byte data){
        //额外的加密操作...
        NetworkStream::Write(data);//写网络流
        //额外的加密操作...
    }
};

class CryptoMemoryStream : public MemoryStream{
public:
    virtual char Read(int number){
        
        //额外的加密操作...
        MemoryStream::Read(number);//读内存流
    }
    virtual void Seek(int position){
        //额外的加密操作...
        MemoryStream::Seek(position);//定位内存流
        //额外的加密操作...
    }
    virtual void Write(byte data){
        //额外的加密操作...
        MemoryStream::Write(data);//写内存流
        //额外的加密操作...
    }
};

class BufferedFileStream : public FileStream{
    //...
};

class BufferedNetworkStream : public NetworkStream{
    //...
};

class BufferedMemoryStream : public MemoryStream{
    //...
}




class CryptoBufferedFileStream :public FileStream{
public:
    virtual char Read(int number){
        
        //额外的加密操作...
        //额外的缓冲操作...
        FileStream::Read(number);//读文件流
    }
    virtual void Seek(int position){
        //额外的加密操作...
        //额外的缓冲操作...
        FileStream::Seek(position);//定位文件流
        //额外的加密操作...
        //额外的缓冲操作...
    }
    virtual void Write(byte data){
        //额外的加密操作...
        //额外的缓冲操作...
        FileStream::Write(data);//写文件流
        //额外的加密操作...
        //额外的缓冲操作...
    }
};

void Process(){

        //编译时装配
    CryptoFileStream *fs1 = new CryptoFileStream();
    BufferedFileStream *fs2 = new BufferedFileStream();
    CryptoBufferedFileStream *fs3 =new CryptoBufferedFileStream();
}

  • 问题出在哪里？

    • “//额外的加密操作…”，对于所有的ConcreteConcreteComponent实例来说都是一样的 --> 重复性的代码出现了 --> bad smell
    • 另一方面，如果前天提出的需求可以具体分为m类，昨天的可以分为n类，那么ConcreteConcreteComponent类就会有O(m*n!) 的个数(为什么是阶乘–> 因为需求可以组合，比如我既要加密又要buffer)，实现的类会特别多

  • 改进如下

//业务操作
class Stream{
public：
    virtual char Read(int number)=0;
    virtual void Seek(int position)=0;
    virtual void Write(char data)=0;
    
    virtual ~Stream(){}
};

//主体类
class FileStream: public Stream{
public:
    virtual char Read(int number){
        //读文件流
    }
    virtual void Seek(int position){
        //定位文件流
    }
    virtual void Write(char data){
        //写文件流
    }
};

class NetworkStream :public Stream{
public:
    virtual char Read(int number){
        //读网络流
    }
    virtual void Seek(int position){
        //定位网络流
    }
    virtual void Write(char data){
        //写网络流
    }  
};

class MemoryStream :public Stream{
public:
    virtual char Read(int number){
        //读内存流
    }
    virtual void Seek(int position){
        //定位内存流
    }
    virtual void Write(char data){
        //写内存流
    }
    
};

//扩展操作
class CryptoStream: public Stream {
    
    Stream* stream;//...

public:
    CryptoStream(Stream* stm):stream(stm){
    
    }
    
    
    virtual char Read(int number){
       
        //额外的加密操作...
        stream->Read(number);//读文件流
    }
    virtual void Seek(int position){
        //额外的加密操作...
        stream::Seek(position);//定位文件流
        //额外的加密操作...
    }
    virtual void Write(byte data){
        //额外的加密操作...
        stream::Write(data);//写文件流
        //额外的加密操作...
    }
};

class BufferedStream : public Stream{
    Stream* stream;//...    
public:
    BufferedStream(Stream* stm):stream(stm){
        
    }
    //...
};

void Process(){
    //运行时装配
    FileStream* s1=new FileStream();
    CryptoStream* s2=new CryptoStream(s1);
    BufferedStream* s3=new BufferedStream(s1);
    BufferedStream* s4=new BufferedStream(s2);
}

  • 把原本继承ConcreteComponent类的ConcreteConcreteComponent类改成直接继承Component，至于前天的需求如何和金今天的需求一起整合呢？–》 使用指针对象

    • 利用多态， 所以指针对象是前天的需求的基类，也就是ConcreteComponent的基类–》Component类。
    • 所以奇妙的事情发生了，改写后的、实现昨天需求的类，既继承了Component类，又包含了Component类的指针对象

  • 一般出现继承就不组合，出现组合就不继承

    • 如果看到了对同一个类既有继承又有组合，基本上就是装饰模式
    • 这里继承是为了实现接口，组合是为了包含另一个需求/扩展出的功能

  • 所以装饰模式就是为了划清责任

    • 每个类都负责单一职责 （SRP原则）

  • 其实写到现在已经差不多了，但是我们可以进一步优化–> 可以看到改写后的、实现昨天需求的几个类里面都有个特性就是，包含了Steam* stream , 根据原则“看到相同的就可以往上提”(马丁福勒在《重构》中说的)，可以在创建一个中间类Decorator继承Stream，然后昨天的需求继承Decorator，这样就隐藏了既继承又组合的现象了。（但实际上工程中上一种写法很常见了。）

uml

在这里插入图片描述

  • 每次看uml的时候要想清楚哪部分是动的，哪部分是静的，Component和Decorator是静的(稳定点)，剩下的Concrete开头的都是动的(不稳定的)。

小总结

  • 通过采用组合而非继承的手法， Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的“灵活性差”和“多子类衍生问题”。
  • Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类。
  • Decorator模式的目的并非解决“多子类衍生的多继承”问题，Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。

Bridge

两者辨析

荷西·H
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
设计模式原则—单一职责原则
lspengjiang的专栏
11-15 666
设计模式六大原则 1.单一职责原则 2.里氏替换原则 3.依赖倒置原则 4.接口隔离原则 5.迪米特法则 6.开闭原则
设计模式之单一职责原则
胡胜同学
09-04 451
设计模式之单一职责原则 遵循单一职责原的优点有： 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多。 提高类的可读性，提高系统的可维护性。 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。 class Animal{ public void breathe(String animal){ S
面向对象设计原则之单一职责原则
limuzi13的专栏
06-25 446
单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小。单一职责原则定义如下： 单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。 单一职责原则告诉我们：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用
设计模式原则 - 单一职责原则（一）
weixin_43811057的博客
12-19 515
单一职责原则（Single Responsibility Principle, SRP），有且仅有一个原因引起类的变更顾名思义：一个类只负责一项职责即对类来说，一个类应该只负责一项职责。如类 A 负责两个不同职责：职责 1，职责 2，当职责 1 需求变更而改变 A 时，可能造成职责 2 执行错误，所以需要将类 A 的粒度分解为 A1，A2单一职责原则：各司其职通过上面两种方案分析：方案一：类级别遵守了单一职责原则，但是改动的代价很高方案二：方法级别遵守了单一职责原则，改动幅度较小。
设计模式六大原则之【单一职则原则】
m0_50414588的博客
06-18 410
一、什么是单一职责原则 首先, 我们来看单一职责的定义. 单一职责原则,全称Single Responsibility Principle, 简称SRP. A class should have only one reason to change 类发生更改的原因应该只有一个 就一个类而言，应该仅有一个引起它变化的原因。应该只有一个职责。如果一个类有一个以上的职责，这些职责就耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责
设计模式—单一职责原则
weixin_38747097的博客
11-22 470
每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。遵循单一职责原则，分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。有一个类T负责两个不同的职责：职责P1和职责P2。当因为职责P1的需求发生改变而需要修改类T的时候，有可能会导致原本运行正常的职责P2功能发生故障。举例：针对上面案例中的代码，我们进行优化，我们把图片下载、保存到缓存、图片显示这几个职责定义成单独类，而不是一个类全搞定。变更是必然的，如果单一职责原则遵守得好，就可以达到职责/功能的解耦。
设计模式-单一责任原则
qq_45205390的博客
02-24 493
设计模式-单一责任原则深入相关论述
Java设计模式中单一职责原则详解.rar
07-10
其中，"单一职责原则"（Single Responsibility Principle，SRP）是面向对象设计的基本原则之一，也是Java设计模式中的重要组成部分。本篇文章将深入探讨单一职责原则的概念、意义、应用及其在Java编程中的实际运用。...
简单讲解Java设计模式编程中的单一职责原则
09-02
Java设计模式中的单一职责原则（Single Responsibility Principle，SRP）是面向对象设计的基本原则之一，它的核心思想是：一个类或者一个模块应该只有一个引起它变化的原因。这意味着一个类应该只负责一项职责，使得...
设计模式（三）之单一职责原则.zip
02-17
单一职责原则可以使类的复杂度降低，实现什么职责都有清晰明确的定义；类的可读性提高，复杂度降低；可读性提高了，代码就更容易维护；变更（需求是肯定会变）引起的风险（包括测试的难度，以及需要测试的范围）降低...
设计模式6大原则：单一职责原则
05-09
设计模式6大原则：单一职责原则
单一职责模式例子。
12-25
在软件设计领域，单一职责原则（Single Responsibility Principle，简称SRP）是面向对象设计的六大原则之一，由罗伯特·C·马丁（Robert C. Martin）在其著作《Clean Code》中提出。这个原则强调一个类或者模块应当...
浅谈c#设计模式之单一原则
10-25
**浅谈C#设计模式之单一原则** 设计模式是软件工程中的一种最佳实践，用于解决常见问题并提供可重用的解决方案。其中，单一原则（Single Responsibility Principle, SRP）是面向对象设计的基本原则之一，它强调一个...
Java设计模式 | 七大原则之单一职责原则
最新发布
但行好事，莫问前程
02-23 513
Java设计模式七大原则之单一职责原则要点+应用demo
设计模式原则——单一职责原则
Whoo_的博客
09-30 480
单一职责原则了解
图解java设计模式_06_单一职责原则
to_real的博客
07-26 187
package com.atguigu.principle.singleresponsibility; public class SingleResponsibility1 { public static void main(String[] args) { // TODO Auto-generated method stub Vehicle vehicle = new Vehicle(); vehicle.run("摩托车"); vehicle.run("汽车"); vehi...
设计模式系列--23种常见设计模式之单一职责原则（2）
每天进步一点点
10-28 167
概念 单一职责原则（SRP：Single responsibility principle）又称单一功能原则，它规定一个类应该只有一个发生变化的原因。通俗来讲就是 一个类或模块应该有且只负责一件事。 为什么，因为假如负责了2件事，任何一件事需要改变就引起了该模块的改变，违反了 “一个类应该只有一个发生变化的原因”。所以就可以简单的理解为就是 一个类或模块细分到只负责一个功能，这就要求了这个类不能太臃肿，要简单精细。 问题由来 有一个类T负责两个不同的职责：职责P1和职责P2。当因为职责P1的需求发
设计模式（单一职责原则）
qq_39234639的博客
06-22 732
设计模式（单一职责原则）
正则表达式，正则和通配的区别
Hesy_H的博客
10-29 3714
这个博客写的很好 通配 尤其注意，通配的*和正则里面的*是不一样的含义 正则 通配是shell能够解析的 正则是给支持正则的命令自身解析的(like grep)，所以要用引号防止shell将特殊符号进行了转义 ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值