首页 > 代码库 > 设计模式总结-结构型模式

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

2024-07-02 17:49:23   225人阅读

描述：

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

分类：

适配器模式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声明所有用来管理子类对象的方法，但是由于不够透明，所有树叶和树枝类不具有相同的接口，这样客户端调用时需要做相应的判断，带来了很大的不变。
      由此看来，使用的时候真的得视情况而定了啊！其实组合模式最大的动机也就是让用户在使用时无需对Leaf和Composite进行区分，可以一致的对待容器对象和叶子对象，这样不就倾向于透明方式了吗？

总结：


模式比较：

1）从代码的角度来看，发现其实适配器模式和代理模式有些相似，只是前者解决现有对象在新的环境中所遇到的问题，后者解决直接访问对象时出现的问题，所以这两种模式从使用角度来看的话都是解决直接访问对象时出现的问题，只是含义不十分相同而已。
2）从外观上来看的话，适配器模式和外观模式都是对系统的封装，只是适配器是用来适配对象的，而外观是用来配合整个子系统的。
3）就外观模式与代理模式来说，我觉得他们两个只是解决的侧重点不同而已，解决的思路还是一样的，都是通过引用一层间接层。外观可以同代理模式同时使用，因为外观对象完全可以是一个远程地址空间对象的远程代理，简称为外观代理模式或者代理外观模式。
对于模式的学习还需要进一步的加深与理解，继续！
 


联系
我们