6.装饰模式（Decorator）

最新推荐文章于 2023-10-04 15:19:24 发布
最新推荐文章于 2023-10-04 15:19:24 发布
阅读量137 收藏
点赞数
分类专栏： 可复用面向对象软件基础（23种设计模式）
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_35484146/article/details/113002885
版权

本文讲述了单一职责模式中的装饰模式，介绍了装饰模式的动机、定义、结构、代码实例，最后进行了总结。
再次感谢GeekBand的李建忠老师、GOF等前辈

1. “单一职责”模式:

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

2. 动机（Motivation）

  • 在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入了静态特质[什么是静态特质？什么是动态特质？稍后结合代码理解]，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。
  • 如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响降为最低？

3. 代码实例

decorator1.cpp代码实现的是“流操作类及其功能扩充”，根据以往知识，继承可以为父类增加新功能，FileStream、NetworkStream、MemoryStream分别为文件流、网络流、内存流，这三个类都继承了抽象父类Stream，并重写了虚函数。为了为流增加加密功能，CryptoFileStream、CryptoNetworkStream、CryptoMemoryStream分别继承了上边三个基本流，并在对应方法中增加了加密代码；为了为流增加缓冲功能，BufferedFileStream、BufferedNetworkStream、BufferedMemoryStream分别继承了上边三个基本流，并在对应方法中增加了数据缓冲代码；为了为流增加加密与缓冲功能，CryptoBufferedFileStream、CryptoBufferedNetworkStream、CryptoBufferedMemoryStream分别继承了上边三个基本流，并在对应方法中增加了加密与数据缓冲代码。

// decorator1.cpp
// 流基类
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);//写文件流
        //额外的加密操作...
        //额外的缓冲操作...
    }
};
class CryptoBufferedNetworkStream : public NetworkStream{
	//...
};
class CryptoBufferedMemoryStream : public MemoeryStream{
	//...
};

void Process(){

    //编译时装配
    CryptoFileStream *fs1 = new CryptoFileStream();

    BufferedFileStream *fs2 = new BufferedFileStream();

    CryptoBufferedFileStream *fs3 =new CryptoBufferedFileStream();

}

当前代码的继承关系如下，有图可以发现我们在主体类[stream类]的不同方向[FileStream、NetworkStream、MemoryStream类进行了相同的功能扩充。
在这里插入图片描述
假设现在的基本层（第二层）有n个，每个基本流可能会加m个功能，那么最后一共可以得到1+n+n*m!个类。当然我们能够很快的就定位问题出现的位置，即大量的重复加密与缓冲代码，比如不同的流对于加密算法并没有影响。
 
现在开始进行优化第一步：我们观察CryptoFileStream、CryptoNetworkStream、CryptoMemoryStream三个类十分相似，比如接口个数、接口重写方法等，唯一的不同就是会调用不同基本流对应的Read()、Seek()与Write()，为了消除这种差异，我们不再继承各个基本类，而是在每个扩展类中维护一个Stream对象指针，并修改三个方法的调用方式，这里我们使用的是“优先使用对象组合，而不是类继承原则”[继承在某种程度上破坏了封装性，子类父类耦合度高。而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低]。修改之后发现三个方法的实现版本均为virtual，这要求我们必须继承Stream。
 
这里我们使用了重要的重构方法“编译时绑定转换为了运行时绑定”，即在未修改代码前我们如果维护了CryptoFileStream、CryptoNetworkStream、CryptoMemoryStream三个类的对象指针，那么在编译时已经确定，如果我们维护Stream类的对象指针，那么只有在运行时才能确定类型，这是解耦合的重要方法。

// 改进一
// 扩展操作：加密
class CryptoFileStream /*: public FileStream */ : public Stream{
	Stream *m_stream;	// = new FileStream()
public:
	CryptoFileStream(Stream *stream) : m_stream(stream) {
	
	}
    virtual char Read(int number){
        //额外的加密操作...
       	m_stream->Read(number);	// 读文件流
        //额外的加密操作...
    }
    virtual void Seek(int position){
        //额外的加密操作...
        m_stream->Seek(position);	// 定位文件流
        //额外的加密操作...
    }
    virtual void Write(byte data){
        //额外的加密操作...
        m_stream->Write(data);	// 写文件流
        //额外的加密操作...
    }
};

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

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

通过上一步优化，我们惊奇的发现上面三个类除了类名之外，其它部分完全一致，因此我们可以直接使用一个类来代替，这样就消除了代码的重复性。

// 改进二
// 扩展操作：加密
class CryptoStream : public Stream{
	Stream *m_stream;	// = new FileStream() or = new NetworkStream() or = new MemoryStream()
public:
	CryptoStream(Stream *stream) : m_stream(stream) {
	
	}
    virtual char Read(int number){
        //额外的加密操作...
       	m_stream->Read(number);	// 读文件流
        //额外的加密操作...
    }
    virtual void Seek(int position){
        //额外的加密操作...
        m_stream->Seek(position);	// 定位文件流
        //额外的加密操作...
    }
    virtual void Write(byte data){
        //额外的加密操作...
        m_stream->Write(data);	// 写文件流
        //额外的加密操作...
    }
};

同样对于其它扩展功能也可以按照如上方法进行重构。

// decorator2.cpp
//业务操作
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* m_stream;	//...

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

// 扩展操作：数据缓冲
class BufferedStream : public Stream{
    
    Stream* m_stream;	//...
    
public:
    BufferedStream(Stream* stm):m_stream(stm){
        
    }
    //...
};

void Process(){

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

上述的重构使得我们可以通过嵌套的方式为基本流对象添加新功能。比如s4的定义，既有数据缓冲功能，又实现了加密功能。
 
另外根据“如果某个类的子类中同时出现了相同的字段，那么就应该向上提取”这一重构思想，发现Stream* m_stream;可以将它提取到父类Stream当中，但是FileStream等类中并不包含该字段，因此不能直接提取到Stream当中，所以我们定义了一个中间类：DecoratorStream，并且设置接口为protected访问权限，因为我们只需要通过子类调用或赋值[由于继承了Stream，又不需要重写接口方法，所以该类还是抽象类，当然我们也可以重写接口方法，直接通过m_stream调用运行时类方法来实现，那么再它的子类中即使使用静态绑定也能达到相同效果]。

// decorator3.cpp
//业务操作
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 DecoratorStream : public Stream{
protected:
    Stream* m_stream;//...
    
    DecoratorStream(Stream * stm) : m_stream(stm){
    
    }
};

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


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

void Process(){

    //运行时装配
    FileStream* s1 = new FileStream();
    
    DecoratorStream* fc = new CryptoStream(s1);
    
    DecoratorStream* fb = new BufferedStream(s1);
    
    DecoratorStream* fbc = new BufferedStream(s2);
}

通过重构之后，类个数为1+n+1+m个。优化到这里我们对当前程序的变化点“对不同的流进行功能扩展”有了更清晰的认识，因此我们可以在功能类中维护基类流对象指针来运行时绑定具体流类型来隔离变化。
在这里插入图片描述
现在我们来理解“什么是静态特质？什么是动态特质？”，在decorator1.cpp当中的FileStream::Read(number);就是静态特质，在decorator3.cpp中的m_stream->Read(number);就是动态特质。前者不会发生变化，因为是静态联编，而后者根据运行时的不同类型调用不同的方法，属于动态联编。

4. 模式定义

动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（消除重复代码 & 减少子类个数）。
 
其实Decorator模式和Strategy模式有异曲同工之妙，Strategy模式通过建立“抽象策略”并通过组合来隔离不同策略的变化，Decorator模式也是通过组合“抽象流”来对流进行功能扩充。注意前者的变化点是同一类算法的不同版本，后者是不同类型的流对象。

5. 结构

在这里插入图片描述
使用绿色表示稳定，使用红色表示变化。UML中Component即为Stream，ConcreteComponent即为FileStream、NetworkStream、MemoryStream，Decorator即为DecoratorStream，维护了一个Stream抽象类对象指针，用来保存运行时待增加功能的流对象，ConcreteDecoratorA、ConcreteDecoratorB即为CryptoStream、BufferedStream。

6. 要点总结

  • 通过采用组合而非继承的手法， Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的“灵活性差[静态特质]”和“多子类衍生问题[前面提到的子类爆炸问题]”。
  • Decorator类在接口上表现为is-a Component的继承关系，即 Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类。像这种即继承了父类，有包含父类指针大概率使用了Decorator模式。
  • Decorator模式的目的并非解决“多子类衍生的多继承”问题， Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能[对文件/网络/内存流扩展缓冲、加密等功能，多方向指的就是不同的流]”——是为“装饰”的含义。
  • 通过继承来实现的扩充会出现这种问题的原因就是功能划分不清，Stream中只需要实现流相关操作即可，而加密、数据缓冲应该划分到外部。
Tobias Shieh
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
6、7 单一职责模式（装饰模式、桥模式)
sdsc1314的博客
12-25 122
1.装饰模式（Decorator) ①通过采用组合而非继承的方法，Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的灵活性差和多子类衍生问题 ②Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表示为has-a Component的组合关系，即Decorator类又使用另外一个Component类 2.桥模式（Bridge） ...
c++ 设计原则 - 单一职责原则
最新发布
weixin_45053845的博客
11-12 278
然后，在需要的地方调用 FileCompressor 的方法进行压缩和解压操作，这样就实现了功能的扩展，并且不会影响到原有的文件读取和写入类。通过以上的两个场景，我们可以看到，根据单一职责原则的设计，当需求发生变化时，我们可以独立地扩展或修改相应的类，而不会对其他部分的代码造成影响。设计遵循单一职责原则：每个类只负责一项工作，当需求发生变化时，只需要修改对应的类，而无需影响其他类。当需求发生变化时，根据单一职责原则的设计，我们可以针对不同的需求独立地扩展或修改相应的类，而不会影响其他部分的代码。
【8】c++设计模式——＞单一职责原则
weixin_42097108的博客
10-04 454
如果一个类承担的职责过多，就等于把这些职责耦合到了一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。指的就是将单一事物抽象出来组合成一个类，所以我们在设计类的时候每个类中处理的是单一事物而不是某些事物的集合。让类的功能单一，不让类与具体的事物耦合。软件设计真正要做的事情就是，发现根据需求发现职责，并把这些职责进行分离，添加新的类，给当前类减负，越是这样项目才越容易维护。设计模式中所谓的单一职责原则，就是对一个类而言，应该仅有一个引起它变化的原因，其实就是将这个类所承担的职责单一化。
单一职责原则（C++)
先锋小牛
08-31 1289
概念     就一个类而言，应该仅有一个引起它变化的原因。每个类实现一个功能。 简述     单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责，通常意味着单一的功能，因此不要为类实现过多的功能点，以保证实
单一职责原则
Andrew's Blog
08-17 175
设计模式学习之单一职责原则
设计模式C++学习之装饰模式（Decorator）
09-07
装饰模式（Decorator）是软件设计领域中一种非常实用的结构型设计模式，它允许我们向一个对象添加新的行为或责任，而无需修改该对象的源代码。在C++编程语言中，装饰模式常用于动态地扩展类的功能，使得类的行为在...
7. 装饰器模式1
08-03
Python允许使用`@decorator`的形式直接将装饰器应用到函数或方法上，这在语法层面上大大简化了装饰器的使用。例如，一个简单的日志装饰器可以记录函数的执行时间，或者统计函数的调用次数。 装饰器模式的本质是通过...
Java装饰模式（Decorator模式）
12-22
Java装饰模式，也被称为Decorator模式，是一种设计模式，它允许在运行时向对象添加新的行为或职责，而不必通过继承的方式来扩展类。这种模式提供了一种比使用子类更加灵活的方式来扩展对象的功能。 装饰模式的核心...
java设计模式之装饰器模式（Decorator）
08-31
- 灵活性：装饰模式可以在运行时动态地给对象添加新的职责，而不必通过修改代码来实现。 - 可组合性：通过组合多个装饰类，可以创造出多种多样的行为组合，比单一的继承关系更加灵活。 - 易于维护：减少了子类的创建...
Java设计模式之装饰模式（Decorator模式）介绍
09-03
Java设计模式中的装饰模式（Decorator模式）是一种结构型设计模式，它允许在运行时向对象添加新的行为或责任，而不必通过子类化的方式。这种模式对于系统扩展性和灵活性至关重要，因为它避免了创建大量子类来实现...
c++ 面向对象设计五大原则
12-17
面向对象设计（OOD）是面向对象编程（OOP）必不可少的一个环节，只有好的设计，才能保障程序的质量。面向对象设计的主要任务就是类的设计，不少面向对象（OO）的先驱和前辈已经提出了很多关于类的设计原则，用于指导OOP，其中就包括类设计的五项基本原则。 1.单一职责原则（Single Resposibility Principle，SRP） 专注是一个人的优良品质，同样，单一职责也是一个类的优良设计。单一职责的核心思想：一个类只做好一件事情。 单一职责原则可以看作是高内聚、低耦合在面向对象原则上的引申。类的职责过多，容易导致类间职责依赖，提高耦合度，降低内聚性。通常意义下的单一职责，指的是类只有一
设计模式（一）：单一职责原则
工作学习记录
06-19 767
Single Responsibility Principle(SRP): There should never be more than one reason for a class to change. 单一职责原则的定义：应该有且只有一个原因导致类的变更。 按照字面意思理解，一个类应该只有一个功能才符合单一职责原则。 单一职责原则的好处： 1.因为只有一个职责，类的复
【学习笔记】C++下的单一职责原则（程杰-大话设计模式）
野生C++程序员
06-13 261
《大话设计模式》单一职责原则学习笔记
桥接模式和装饰者模式的区别及理解
夏虫的博客
12-01 3641
一、桥接模式 桥接模式必须由一方使用抽象类，持有使用接口的一方。 二、装饰者模式 从外观上看装饰者模式和桥接模式的类图只有一个地方不一样，就是最上边的接口和抽象类间的关系，装饰者模式是实现接口，桥接是以组合的方式持有接口。 三、两种模式的区别 桥接模式之所以能够解决类爆炸问题，就是因为相互直接接触的是接口和抽象类，其实每一个接口或者抽象类后背都可以看成是无数数目的不同类别的对象。于是各自拿出/删除对象就可以解决问题，如下图，就是想要哪两个货物结合，比如要A1、B1，那就直接通过商人交换就OK了，重点在于
常用设计者模式---装饰模式和桥接模式
静下心来吧，让自己变强大点！
02-15 2390
装饰模式 定义：动态给一个对象添加一些额外的职责,就象在墙上刷油漆.使用Decorator模式相比用生成子类方式达到功能的扩充显得更为灵活。 要点：装饰者与被装饰者拥有共同的超类，继承的目的是继承类型，而不是行为 下面这个例子也有助于理解 装饰的流程和作用 现在需要一个汉堡，主体是鸡腿堡，可以选择添加生菜、酱、辣椒等等许多其他的配料，这种情况下就可以使用装饰者模式。 http:/
以C/C++语法浅谈六大设计原则（三）——单一职责原则（Single Responsibility Principle）
尘海折柳的博客
01-15 1133
单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。 简述：单一职责原则(Single Responsibility Principle, SRP)可以看作是低耦合、高内聚在面向对象原则上的引申与扩展，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因...
《大话设计模式》读书笔记之C++实现--chapter3单一职责原则
WingC的博客
03-30 468
单一职责的原则准确解释为：“就一个类来说，应该仅有一个引起它变化的原因”。如果一个类承担的职责过多，就相当于把这些职责耦合在一起，一个职责的变化可能会抑制或削弱这个类完成其他职责的能力。当变化发生时，设计会受到意想不到的破坏。 举一个例子来说，俄罗斯方块的游戏逻辑和界面应该分开，当移植到不同平台上时，游戏逻辑代码本身不会发生改动，仅需要对界面部分作出修改。如果你能想到多余一个的动机去改变类，那么
设计模式六大原则（1）：单一职责原则
qq_46418241的博客
05-30 84
说到单一职责原则，很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P.
3.4 设计模式 ————————单一职责原则——面向对象设计原则
ice
08-17 158
单一职责原则也是面向对象设计原则中的一条，下面我们就来详细地对其进行介绍。 单一职责原则的定义 单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a cl
装饰模式（Decorator）
05-26
装饰模式是一种结构型设计模式，它允许你在运行时动态地扩展对象的行为，而无需修改源代码。这种模式创建了一个包装对象，这个包装对象可以在被包装的对象的行为前后添加或者替换新的行为，从而实现对原有对象的动态...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值