设计模式总结-结构型模式

描写叙述：

• 怎样组合类和对象以获得最大的结构；
• 不是对接口和实现进行组合，而是描写叙述了怎样对一些对象进行组合，从而实现新功能的一些方法；

分类：

适配器模式	http://blog.csdn.net/huo065000/article/details/22177651
装饰模式	http://blog.csdn.net/huo065000/article/details/22061403
代理模式	http://blog.csdn.net/huo065000/article/details/22177651
外观模式	http://blog.csdn.net/huo065000/article/details/23181031
享元 模式	详见下文
桥接模式	详见下文
组合模式	详见下文

适配器模式可分为：类的适配器模式，对象的适配器模式，接口的适配器模式，当中对象的适配器模式则是各结构模式的起源：

Bridge模式：

意图：

      将抽象部分与他的实现部分分离，使它们都能够独立的变化。其用意是：将抽象化与实现化解耦，使得二者能够独立变化。

      就如生活中一样：在公路上随处可见小汽车，公共汽车，他们不但能够在市区内公路上行驶，还能够在快速公路上行驶；也就是说，对于交通工具来说，他们有着不同的类型，同一时候它们所行驶的环境也在变化，在软件设计中要适应这样的两个或者多维度的变化，就要涉及到桥接模式。

画一个简单的结构图：

FlyWeight模式：

      运用共享技术有效地支持大量细粒度的对象。主要解决因为同样数量过大而造成系统内存开销过大的问题。

      享元模式，顾名思义最大的优势就是共享啦！在此也分为两种状态，举一个常见的样例，如今网上购物已经是一个潮流了！自己当然也是当中的一员了！网上购物真的是降低了自己出门的频率，这对于不喜欢逛街的自己来说是最好只是的了！作为一个淘宝店主的话，比方经营一款畅销的女士板鞋，在订单中须要注明客户须要的板鞋信息，这样我们能够将板鞋产品抽象出来：

class Shoe
        {
            string color;
            int size;
            string position;
            public string Getcolor()
            {
                return color;
            }
            public void Setcolor(string color)
            {
                this.color = color;
            }
            //还有反复的size和position代码，不做反复
        }

      正如上边的代码一样，鞋子分为颜色，尺码和库存位置三项状态数据，当中颜色和尺码为鞋子的自然状态，我们称之为内部状态，这些状态仅仅与对象本身有关，不会随外界的环境改变而发生变化；而库存位置，我们称之为外部状态，它与对象本身无必定关系，所以外部状态通常是由外界环境所决定的。

Composite模式：

意图：

      将对象组合成树形结构以表示“部分-总体”的层次结构。使得用户对单个对象和组合对象的使用具有一致性。看到树形结构突然想到了《数据结构》课本中“树”那一章节了，在书中给出了“树”的固有特性：一颗非空树是由若干颗子树构成的，而子树又可由若干颗更小的子树构成。而这里的子树能够是叶子，也能够是分支。

结构图：

适应性：

1．你想表示对象的部分-总体层次结构

2．你希望用户忽略组合对象与单个对象的不同，用户将统一地使用 组合结构中的全部对象。

方式分类：

透明方式：

      看图就可发现，Leaf中没有Add和Remove。可是为了方便，也就是为了让Leaf和Composite具备统一的接口，所以在Component中声明全部用来管理子对象的方法，使叶节点和枝节点对于外界没有差别，具备全然一致的行为接口。可是这样问题也会非常明显，由于Leaf本身没有，这样实现根本就没有了意义。

安全方式：

      在图中，不在Component接口中声明Add和Remove方法，即子类Leaf也不用去实现它，而是在子类Composite声明全部用来管理子类对象的方法，可是因为不够透明，全部树叶和树枝类不具有同样的接口，这样client调用时须要做对应的推断，带来了非常大的不变。

      由此看来，使用的时候真的得视情况而定了啊！事实上组合模式最大的动机也就是让用户在使用时无需对Leaf和Composite进行区分，能够一致的对待容器对象和叶子对象，这样不就倾向于透明方式了吗？

总结：

模式比較：

1）从代码的角度来看，发现事实上适配器模式和代理模式有些相似，仅仅是前者解决现有对象在新的环境中所遇到的问题，后者解决直接訪问对象时出现的问题，所以这两种模式从使用角度来看的话都是解决直接訪问对象时出现的问题，仅仅是含义不十分同样而已。

2）从外观上来看的话，适配器模式和外观模式都是对系统的封装，仅仅是适配器是用来适配对象的，而外观是用来配合整个子系统的。

3）就外观模式与代理模式来说，我认为他们两个仅仅是解决的側重点不同而已，解决的思路还是一样的，都是通过引用一层间接层。外观能够同代理模式同一时候使用，由于外观对象全然能够是一个远程地址空间对象的远程代理，简称为外观代理模式或者代理外观模式。

对于模式的学习还须要进一步的加深与理解，继续！