结构型模式描述了如何把类和对象组合起来以形成更大的结构。我是这么理解的：程序大体框架已基本形成了，只是对其代码和结构进行了优化。提高了代码的复用性，降低了系统内部的耦合性。
该类型模式主要包括：适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式、代理模式。
1.适配器模式：更换接口，使其成为适应用户需求的接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。（系统的数据和行为都是正确的，但接口不符时，我们应该考虑用适配器，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况。）当使用一个已经存在的类，但如果它的接口也就是它的方法和你的要求不同时，就应该考虑使用适配器模式。客户代码可以统一调用同一接口。
现实生活中这样的例子很多，前段时间买了个键盘，由于自己的疏忽把键盘买错了，应该是USB接口的，我却买成了台式机的圆头的，跟卖家交谈的时候，人家推荐我用USB转换器就可以解决问题啦。一样的道理，适配器模式就是要解决这个问题，就算是转弯抹角也要达到目的。
2.桥接模式：将抽象部分和它的实现部分分离，使它们都可以独立的变化。（抽象类和它的派生类用来实现自己的对象）我的理解是：实现系统可能有多角度分类，每一种分类都有可能变化，那么就把这多角度分离出来让他们变化，减少他们之间的耦合。这里用到了合成/聚合复用原则（尽量使用合成/聚合，尽量不要使用类的继承：优先使用对象的合成/聚合将有助于你保持每个类被封装，并被集中在单个任务上。这样类和继承层次会保持较小规模，并且不可能增长为不可控制的庞然大物。）
说实话，刚开始不太理解什么是抽象和实现分离，从网上找了一个例子说服了自己：就拿汽车在路上行驶的来说。即有小汽车又有公共汽车，它们都不但能在市区中的公路上行驶，也能在高速公路上行驶。这你会发现，对于交通工具（汽车）有不同的类型，然而它们所行驶的环境（路）也在变化，在软件系统中就要适应两个方面的变化？怎样实现才能应对这种变化呢？在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。
3.组合模式：定义：组合模式是将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。当需求中是体现部分与整体层次的结构时，希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑用组合模式了。它定义了包含基本对象、组合对象的类的层次结构。基本对象可以被组合成更复杂的组合对象，而这个组合对象又被组合，这样不断地递归下去，客户代码中，任何用到基本对象的地方都可以使用组合对象了、用户是不用关心到底是处理一个叶节点海华丝处理一个组合组件，也就用不着为定义组合而写一些判断语句了。组合模式是让客户可以一致地使用组合结构和单个对象。（详见http://blog.csdn.net/fengkungui/article/details/41445489） 4.装饰模式：动态的给一个对象添加额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。5.外观模式：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一个子系统更加容易使用。 代理模式：为其他对象提供一种代理以控制对这个对象的访问 二者区别： 代理的客户对象无法直接访问目标对象，代理对象提供对单独目标对象的访问控制，而外观模式的客户对象可以直接访问子系统中的各个对象，但通常由外观对象提供对子系统个元件功能的简化的共同层次的调用接口。
6.享元模式：运用共享技术有效的支持大量细粒度的对象
总结：概念性的东西，越想越乱，在回忆这几个模式的时候，都是首先想到的是大话设计上大鸟和小菜对话的场景，之后才是对知识的回顾，还是理论和实际脱节的缘故啊。所以嘛，重复才是力量，将设计模式与实践相结合，慢慢感悟。