结构型模式

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

面向对象的精神就是更好的应对需求的变化,而现实中往往会有下面这些情况:想使用一个已经存在的类,而它的接口不符合要求,或者希望创建一个可以复用的类,该类可以与其他不相关的类或不可预见的类协同工作。遵循“对修改关闭,对扩展开放”的原则,让这些接口不同的类通过适配器后,协同工作。

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

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

桥接和适配器有一些共同之处,就是给另一对象提供一定程度的间接性,这样可以有利于系统的灵活性。但是桥接通常是在设计之初就对抽象接口与它的实现部分进行桥接,让抽象与实现两者可以独立演化。
桥接和装饰被应用于软件生命周期的不同阶段,针对的是不同的问题。

外观(迪米特法则)
为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

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

应该让一个软件中的子系统间的通信和相互依赖关系达到最小,而具体办法就是引入一个外观对象,它为子系统间提供了一个单一而简单的屏障。

外观与适配器也有一些近似,都是对现存系统的封装。外观定义的是一个新的接口,而适配器则是复用一个原有的接口,适配器是使用两个原有的接口协同工作,而外观则是为现存系统提供一个更为方便的访问接口。适配器是用来适配对象的,而外观则是用来适配整个子系统的,外观所针对的对象的粒度更大。

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

用户使用组合类接口与组合结构中的对象进行交互,如果接收者是一个叶节点,则直接处理请求,如果接收者是组合对象,通常将请求发送给它的子部件,并在转发请求之前或之后可能执行一些辅助操作。组合模式的效果是客户可以一致地使用组合结构和单个对象。任何用到基本对象的地方都可以使用组合对象。
【结构型模式】
装饰(合成/聚合复用)
动态地给一个对象添加一些额外的职责。就增加功能来说,装饰模式相比生成子类更加灵活。

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

享元(单一职责)
运用共享技术有效地支持大量细粒度的对象。

对象使得内存开销过大,而且如果都是大量重复的对象,那就是资源的极大浪费,会使得机器性能减慢,这个显然是不行的。

面向对象技术有时会因简单化的设计而代价极大。享元模式可以避免大量非常相似类的开销。在程序设计中,有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本上都是相同的,有时就能够大幅度地减少需要实例化的类的数量。如果能把那些参数移动到类实例的外面,在方法调用时将它们传递进来,就可以通过共享大幅度地减少单个实例的数目。

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

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

代理与适配器的区别:
代理是一种原来对象的代表,其他需要与这个对象打交道的操作都是和这个代表交涉。而适配器则不需要虚构出一个代表者,只需要为应付特定使用目的,将原来的类进行一些组合。

    推荐阅读