【C++】Chapter25：模式总结（中）

结构型模式

 

适配器模式：

将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原来由于接口不兼容而不能一起工作的那些类可以一起工作。

现实中往往会有下面这些情况，想使用一个已经存在的类，而它的接口不符合要求，或者希望创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类协同工作。适配器模式可以让这些接口不同的类通过适配后，协同工作。

 

适配器（Adapter）

 

 

 

桥接模式：

将抽象部分与它的实现部分分离，使它们都可以独立地变化。

继承是好东西，但往往会过度地使用，继承会导致类的结构过于复杂，关系太多，难以维护，而更糟的是扩展性非常差。而仔细研究如果能发现继承体系中，有两个甚至多个方向的变化，那么就解耦这些不同方向的变化，通过对象组合的方式，把两个角色之间的继承关系改为了组合的关系，从而使这两者可以应对各自独立的变化，事实上也就是合成聚合复用所提倡的原则。总之，面对变化，应该找出变化并封装之。

适配器模式主要是为了解决两个已有接口之间不匹配的问题，不需要考虑这些接口是怎样实现的，也不考虑它们各自可能会如何演化。不需要对两个独立设计的类中任一个进行重新设计，就能够使它们协同工作。

桥接与适配器具有一些共同的特征，就是给另一对象提供一定成都的间接性，这样可以有利于系统的灵活性。通常在设计之初，就对抽象接口与它的实现部分进行桥接，让抽象与实现两者可以独立演化。

 

桥接（Bridge）

 

 

组合模式：

将对象组合成树形结构以表示“部分—整体”的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。

组合模式希望用户忽略组合对象和单个对象的不同，用户将可以统一地使用组合结构中的所有对象。用户使用组合类接口与组合结构中的对象进行交互，如果接收者是一个叶节点，则直接处理请求，如果接收者是组合对象，通常将请求发送给它的子部件，并在转发请求之前或之后可能执行一些辅助操作。组合模式的效果是客户可以一致地使用组合结构和单个对象。任何用到基本对象的地方都可以使用组合对象。

 

组合（Composite）

 

 

 

装饰模式：

动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更加灵活。

面对变化，如果采用生成子类的方法进行扩充，为支持每一种扩展的组合，会产生大量的子类，使得子类数目呈爆炸性增长。这就带来了灾难，而事实上，这些子类多半只是为某个对象增加一些职责，此时通过装饰的方式，可以更加灵活、以动态、透明的方式给单个对象添加职责，并在不需要时，撤销相应的职责。

 

装饰（Decorator）

 

 

 

外观模式：

为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

信息的隐藏促进了软件的复用。类之间的耦合越弱，约有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。如果两个类不必彼此直接通信，那么就不要让这两个类发生直接的相互作用。如果实在需要调用，可以通过第三者来转发调用。外观模式就是引入一个外观对象，它为子系统间提供了一个单一而简单的屏障，让一个软件中的子系统间的通信和相互依赖关系达到最小。通常企业软件的三层或N层架构，层与层之间地分离其实就是外观模式的体现。

在现实中，早已设计好的两个类，过后需要它们统一接口，整合为一的实例很多，外观模式多被用于软件生命周期的此阶段。外观模式与适配器模式有些近似，都是对现存系统的封装。有人说外观模式是另外一组对象的适配器，这种说法不是很准确，因为外观定义的是一个新的接口，而适配器则是复用一个原有得接口，适配器是使两个已有的接口协同工作，而外观则是为现存系统提供一个更为方便的访问接口。如果硬说外观模式是适配，那么适配模式是用来适配对象的，而外观则是适配整个子系统的，针对的对象粒度更大。

 

外观（Facade）

 

 

享元模式：

为运用共享技术有效地支持大量细粒度的对象。

对象使得内存占用过多，而且如果都是大量重复的对象，那就是资源的极大浪费。享元模式可以很好的解决很多对象内存开销过大的问题。

 

享元（Flyweight）

 

 

 

代理模式：

为其他对象提供一种代理以控制对这个对象的访问。

代理模式与外观模式的主要区别在于，代理对象代表一个单一对象而外观对象代表一个子系统；代理的客户端对象无法直接访问目标对象，由代理提供对单独的目标对象的访问控制，而外观的客户对象可以直接访问子系统中的各个对象，但通常由外观对象提供对子系统各元件功能的简化的共同层次的调用接口。代理模式是一种原来对象的代表，只需要为应付特定使用目的，将原来的类进行一些组合。

 

代理（Proxy）