结构型模式 讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象，从而实现新的功能（对象结构型模式）。
适配器模式
场景。希望使用以前的类库等，但原类库的结构，与新功能不匹配，需要转换接口
解决办法。重在转换接口，它能够使原本不能在一起工作的两个类一起工作，所以经常用在类库复用，代码迁移等方面，有一种亡羊补牢的味道。
桥接模式
场景。一个类从各角度考虑，会有很多种层派生类，用继承会把分类设计得很复杂。
解决办法。用组合/聚合，把抽象和实现分类，应用于不是一定用继承的情况。
装饰模式
场景。多次加功能时，带来多次的加子类扩展，各级派生类的组合加剧了这种子类膨胀。如穿衣服，是按照不定的次序（类似组合，不能用次序一定的建造者模式，如内裤外穿的超人），穿各种衣服（衣服的子类，很多种）。
解决办法。动态的给一个对象加额外的职责，即不是给类加功能，而是直接加给对象。
组合模式
场景。一些对象，有的是元对象，有的是用多个元对象组合成的，客户调用时，需要区分是元对象还是组合对象，用不同的方式调用，这增加了耦合度。
解决办法。使用调用组合对象的方式调用，不用管是组合还是元对象。
外观模式
场景。客户系统直接调用一个复杂系统的子系统，当子系统发生变化时，一般会引起调用方式的变化，原因是客户系统与复杂系统的耦合度较高，耦合到了复杂系统的子系统。
解决办法。复杂系统提供一个统一接口，所有复杂系统的子系统与客户系统的通信，都用这个接口，避免复杂系统的内部变化，带来调用方式的变化。
享元模式 平时不常用，一般用于在底层提升性能
场景。 一个系统中有大量对象，耗费大量内存。
解决办法。如果满足其他条件，用享元模式解决。
代理模式
场景。一个对象不能或不希望直接访问其他对象，如远程时不能直接访问，有时直接访问会带来复杂度。如远程代理；打开网页时没打开的图片框存储了图片路径和尺寸，是为了优化性能，叫虚拟代理；安全代理，控制真实对象访问时的权限；智能指引，调用对象时，处理一些其他事如记录对象引用次数，查看对象是否锁定成功。总之，引入间接性，可以附加的一些内部处理。
解决办法。加个中间层，类似适配器模式，但不是亡羊补牢，是在避免复杂性，同时保证透明性的情况下加的。