结构型模式讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象，从而实现新的功能（对象结构型模式）。GoF23中设计模式中结构型模式有7中。具体分类如下：

• 适配器模式

将一个接口转换成客户希望的另一个接口，适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作（即让接口不同的类通过适配器后，协同工作）。

• 桥接模式：

将抽象部分与它的实现部分分离，使他们都可以独立地变化。

在解耦方式中，用聚合来代替继承。继承虽然是好东西，但是过渡运用，就会导致类的结构过于复杂，关系太多，难以维护，而更糟糕的是扩展性非常差。如果发现继承体系中，有两个甚至多个方面的变化，那么久解耦这些不同方向的变化，通过对象组合的方式，把两个角色之间的继承关系改为了组合的关系，从而使这两者可以各自独立的变化。找出变化并封装之。

• 组合模式：

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

• 装饰模式：

动态的给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更加灵活。

面对变化，如果采用继承方式会产生大量的子类，使子类数目呈爆炸性增长。而事实上，这些子类多半只是为某个对象增加一些职责，此时通过装饰的方式，可以更加灵活、以动态、透明的方式给单个对象添加职责，不需要时，撤销相应的职责。

• 外观模式：

为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

信息的隐藏促进了软件的复用，在外观模式中，采用引入一个外观对象，让一个软件中的子系统见的通信和相互依赖关系达到最小，也就为子系统间提供了一个单一而简单的屏障。

• 享元模式：

运用共享技术有效地支持大量细粒度的对象。

• 代理模式：

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

• 代理模式与外观模式的区别：

代理对象代表一个单一对象而外观对象代表一个子系统；代理的客户端对象无法之间访问目标对象，有代理提供对单独的目标对象的访问控制，而外观的客户对象可以直接访问子系统中的各个对象，但通常由外观对象提供对子系统个元件功能的简化的共同层次的调用。

• 代理模式与适配器模式的区别：

两者都是属于一种衔接性质的功能，代理是一种对象的代表，其他需要与这个对象打交道的操作都是和这个代表交涉。而适配器则不需要虚构出一个代表者，只需要为应付特定使用目的，将原来的类进行一些组合。

总之，外观模式注重简化接口，适配器模式注重转换接口，桥接模式注重分离接口，装饰模式注重在稳定接口的前提下为对象扩展功能。

Java的动态Web编程，经历了所谓的Model1和Model 2时代。

   （动态Web编程技术的发展历史）

JSP页面是中心

JSP页面接收处理客户端请求，对请求处理后直接做出响应，这样就在JSP页面中同时实现了业务逻辑和流程控制。

上图中的“业务逻辑”对应下图的JavaBean，完成业务处理和访问数据库。

优点和不足

实现比较简单，适用于快速开发小规模项目。

难和简单都是相对的，如果采用Model2的话至少得多一个Servlet类。

但JSP页面身兼View和Controller两种角色，将控制逻辑和表现逻辑混杂在一起，从而导致代码的重用性非常低，增加了应用的扩展性和维护的难度。

也就是说职责过多，耦合度高，很难适应变化。比如老式显卡都是集成在主板上的，显卡要是坏了，那就换主机吧，悲剧。

职责划分，简化JSP工作量

model2在model1基础上，对jsp功能进行了职责划分。

Servlet的加入，从而构成了MVC的实现。

• Servlet做控制器（Controler）：
• 取得参数
• 调用业务逻辑
• 转向页面

• 业务逻辑做模型（Model）：
• 处理业务逻辑
• 保存数据状态

• JSP做视图（View），渲染页面。

上图中的“业务逻辑”对应下图的JavaBean，完成业务处理和访问数据库。

继续职责划分，加入三层思想

将业务逻辑模型（Model）进一步划分成业务逻辑和持久化数据

Servlet/JSP对应三层中的UI（显示层）

业务逻辑对应BLL（业务逻辑层）

持久化逻辑对应DAL（数据访问层）

优点和不足

我们PC用到的文件系统，其实就是我们数据结构里的树形结构，我们处理树中的每个节点时，其实不用考虑他是叶子节点还是根节点，因为他们的成员函数都是一样的，这个就是组合模式的精髓。他模糊了简单元素和复杂元素的概念，客户程序可以向处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。

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

注明：树形结构里的叶子节点也有左右孩子，只不过他的孩子都是空。

组合模式的实现根据所实现接口的区别分为两种形式，分别称为安全模式和透明模式。组合模式可以不提供父对象的管理方法，但组合模式必须在合适的地方提供子对象的管理方法（诸如：add、remove、getChild等）。

作为第一种选择，在Component里面声明所有的用来管理子类对象的方法，包括add（）、remove（），以及getChild（）方法。这样做的好处是所有的构件类都有相同的接口。在客户端看来，树叶类对象与合成类对象的区别起码在接口层次上消失了，客户端可以同等同的对待所有的对象。这就是透明形式的组合模式。

这个选择的缺点是不够安全，因为树叶类对象和合成类对象在本质上是有区别的。树叶类对象不可能有下一个层次的对象，因此add（）、remove（）以及getChild（）方法没有意义，是在编译时期不会出错，而只会在运行时期才会出错或者说识别出来。

第二种选择是在Composite类里面声明所有的用来管理子类对象的方法。这样的做法是安全的做法，因为树叶类型的对象根本就没有管理子类对象的方法，因此，如果客户端对树叶类对象使用这些方法时，程序会在编译时期出错。

这个选择的缺点是不够透明，因为树叶类和合成类将具有不同的接口。

这两个形式各有优缺点，需要根据软件的具体情况做出取舍决定。

这种形式涉及到三个角色：

抽象构件(Component)角色：这是一个抽象角色，它给参加组合的对象定义出公共的接口及其默认行为，可以用来管理所有的子对象。在安全式的合成模式里，构件角色并不是定义出管理子对象的方法，这一定义由树枝构件对象给出。

树叶构件（Leaf）角色：树叶对象是没有下级子对象的对象，定义出参加组合的原始对象的行为。

树枝构件（Composite）角色：代表参加组合的有下级子对象的对象。树枝对象给出所有的管理子对象的方法，如add（）、remove（）、getChild（）等。

//Menu.h
#include <string>

class Menu  
{
public:
    virtual ~Menu();

    virtual void Add(Menu*);
    virtual void Remove(Menu*);
    virtual Menu* GetChild(int);
    virtual void Display() = 0;
protected:
    Menu();
    Menu(std::string);
    std::string m_strName;
};

//Menu.cpp
#include "stdafx.h"
#include "Menu.h"

Menu::Menu()
{

}

Menu::Menu(std::string strName) : m_strName(strName)
{

}

Menu::~Menu()
{

}

void Menu::Add(Menu* pMenu)
{}

void Menu::Remove(Menu* pMenu)
{}

Menu* Menu::GetChild(int index)
{
    return NULL;
}

//SubMenu.h
#include "Menu.h"

class SubMenu : public Menu  
{
public:
    SubMenu();
    SubMenu(std::string);
    virtual ~SubMenu();

    void Display();
};

//SubMenu.cpp
#include "stdafx.h"
#include "SubMenu.h"
#include <iostream>

using namespace std;

SubMenu::SubMenu()
{

}

SubMenu::SubMenu(string strName) : Menu(strName)
{

}

SubMenu::~SubMenu()
{

}

void SubMenu::Display()
{
    cout << m_strName << endl;
}

//CompositMenu.h
#include "Menu.h"
#include <vector>

class CompositMenu : public Menu
{
public:
    CompositMenu();
    CompositMenu(std::string);
    virtual ~CompositMenu();

    void Add(Menu*);
    void Remove(Menu*);
    Menu* GetChild(int);
    void Display();
private:
    std::vector<Menu*> m_vMenu;
};

//CompositMenu.cpp
#include "stdafx.h"
#include "CompositMenu.h"
#include <iostream>

using namespace std;

CompositMenu::CompositMenu()
{
    
}

CompositMenu::CompositMenu(string strName) : Menu(strName)
{

}

CompositMenu::~CompositMenu()
{

}

void CompositMenu::Add(Menu* pMenu)
{
    m_vMenu.push_back(pMenu);
}

void CompositMenu::Remove(Menu* pMenu)
{
    m_vMenu.erase(&pMenu);
}

Menu* CompositMenu::GetChild(int index)
{
    return m_vMenu[index];
}

void CompositMenu::Display()
{
    cout << "+" << m_strName << endl;
    vector<Menu*>::iterator it = m_vMenu.begin();
    for (; it != m_vMenu.end(); ++it)
    {
        cout << "|-";
        (*it)->Display();
    }
}

#include "stdafx.h"
#include "Menu.h"
#include "SubMenu.h"
#include "CompositMenu.h"

int main(int argc, char* argv[])
{
    Menu* pMenu = new CompositMenu("国内新闻");
    pMenu->Add(new SubMenu("时事新闻"));
    pMenu->Add(new SubMenu("社会新闻"));
    pMenu->Display();
    pMenu = new CompositMenu("国际新闻");
    pMenu->Add(new SubMenu("国际要闻"));
    pMenu->Add(new SubMenu("环球视野"));
    pMenu->Display();

    return 0;
}

1．组合模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化“一对一”的关系，使得客户代码可以一致地处理对象和对象容器，无需关心处理的是单个的对象，还是组合的对象容器。

2．将“客户代码与复杂的对象容器结构”解耦是组合模式的核心思想，解耦之后，客户代码将与纯粹的抽象接口——