结构型模式(1)

 

结构型模式主要包括：

    适配器模式（Adapter）、桥接模式（Bridge）、组合模式（Composite）、装饰模式（Decorator）、外观模式（Facade）、享元模式（Flyweight）、代理模式（Ptoxy）。

1 适配器模式（Adapter）

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

    面向对象的精神就是更好的应对需求变化，而现实中往往会有下面这些情况：使用一个已经存在的类，而它的接口不符合需求，或者希望创建一个可以复用的类，该类可以与其他不相关的类

2 桥接模式（Bridge）

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

    那么桥接模式如何面对变化的呢？

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

3 组合模式（Composite） 

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

    组合模式如何做到“擅长于表示对象的部分与整体的层次结构”？

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

4 装饰模式（Decorator）

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

    装饰模式如果面对变化的？

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

5 外观模式（Facade）

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

    如何理解“信息的隐藏促进了软件的复用”？

    类之间的耦合越弱越有利于复用，一个外在弱耦合的类被修改，不会对有关系的类造成波及。如果两个类不必彼此直接通信，那么就不要让这两个类发生直接相互的作用。如果实在调用，可以通过第三者转发调用。

    外观模式是如果贯彻这一原则的？

    应该让一个软件中的子系统间的通信和相互信赖关系达到最小，而具体的办法就是引入一个外观对象，它为子系统间的提供了一个单一而简单的屏障。通常企业软件的三层或N层架构，层与层的分离其实就是外观模式的体现。    

6 享元模式（Flyweight）

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

    那么如何看待很多对象使用内存开销过大的问题？

    对象使用内存过多，而且都是大量的重复对象，那就是资源极大的浪费，会使得机器性能减慢，这显然是不行了。面向对象技术有时会因简单的设计而代价极大。

    如文档处理软件，当中的字符都可以是对象。而如果这些字符都是一个对象的话，就会产生大量难以接受的运算开销，显然这是不合理也是没必要的。由于文档字符就是那么些字母、数字或符号，完全可以让所有相同的字符都共享一个对象。比如有有到‘a’的字符地方，使用一个共享的‘a’对象，这样可以节约大量的内存。

7 代理模式(Ptoxy)

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

    代理模式与外观模式有哪些不同？对适配器模式区别以何在？

    代理模式与外观的区别在于，代理对象代表单一对象而外观对象代表一个子系统，代理的客户对象无法直接访问目标对象，由代理提供对单独的目标对象的访问控制；而外观的客户对象可以直接访问子系统中各个对象，但通常由外观对象提供对子系统各元件功能的简化的共同层次的调用接口。

    与适配器模式其实都属于一种衔接性质的功能。代理是一种原来对象的代表，其他需要与这个对象打交道的操作都是和这个代表交涉。而适配器则不需要虚构出一个代表者，只需要为应付特定的使用目的，将原业的类进行一些组合。

适配器模式、桥接模式与外观模式的优势：

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

    桥接模式与适配器模式有些共同的特征，就是给另一个对象提供一定程度的间接性，这样就可能有利于系统的灵活性。但正所谓未雨绸缪，我们不能等到问题发生了，再去考虑解决问题，而是更应该在设计之处就应该想好如何做来避免问题的发生，桥接模式在设计之初，就对抽象接口与它的实现部分进行桥接，让抽象与实现两者都可以独立的演化。

    桥接模式和适配器模式都是被用到软件生命周期的不同阶段，针对的是不同的问题。而对于外观模式，则和适配器模式有些相似，都是对现存的系统进行封装。但是外观模式定义的是一个新接口，而适配器模式则是复用一个原来的接口，适配器是使两个已有的接口协同工作。而外观模式则是为现在系统提供一个更为方便的访问接口。适配器是用来适配对象的，而外观模式则适配整个子系统，也就是说，外观模式所针对的粒度更大。