从混乱到有序
1 Layers模式
采用分层的设计思想，如tcp/ip协议栈的实现：
代码结构类似如下，当然还有变种
classL1Provider{
public:
virtual voidl1Service() =0;
};classL2Provider{
public:
virtual voidl2Service() =0;
voidsetL1Provider(L1Provider*provider){this->provider= provider;};
protected:
L1Provider*provider;
};
classL3Provider{
public:
virtual voidl3Service() =0;
voidsetL2Provider(L2Provider*provider){this->provider= provider;}
protected:
L2Provider*provider;
};
classDataLink:publicL1Provider{
public:
virtual voidl1Service(){
cout<<"L1 service doing it jobs"<
}
};
classTranspot:publicL2Provider{
virtual voidl2Service(){
cout<<"L2 service before doing it jobs"<
provider->l1Service();
cout<<"L2 service after doing it jobs"<
}
};
classSession:publicL3Provider{
virtual voidl3Service(){
cout<<"L3 service before doing it jobs"<
provider->l2Service();
cout<<"L3 service after doing it jobs"<
}
};
优点：各层可重用 支持标准化 限制了依赖关系范围 可更换性
缺点：行为变化可能引起雪崩效应 效率低下 不必要的工作 难以确定正确的层次粒度
2 Pipes and filter （流水线，管道与过滤器模型）
提供类似unix的管道（|）对数据处理的架构，将数据写入管道，下一个filter进行处理 ，并写入另一个管道。
有如下几种情景
1
2 情景2 拉取模型
情景3 推拉模型 中间filter主动请求数据并推送数据
4 情景4 并行模式 所有filter都主动拉取，轮询属于自己的管道
优点：不需要中间文件，但也可以使用 可更换过滤器 可重组过滤器 可重用过滤器 可快速创建流水线原型 效率因并行处理所提高
缺点：状态信息的开销高昂或缺乏灵活性 通过并行提高效率的初衷常为泡影 数据转换开销大 错误处理
3BlackBoard （黑板模式）
未找到解决办法的不成熟领域，如语音识别 图下识别 监视等，该问题具有如下特点： 可分解成多个子问题，但每个子问题都属于多个不同专业领域。要解决子问题，需要使用不同的表示方法和范式。再很多情况下都没有指导子问题解决者如何系统作战的既定策略，者与职责分解形成了鲜明的对比，在执飞分解中，按指定顺序启动多个解决步骤。
该框架结构分为三部分： 控制组建 黑板组建 知识源
control用于确定下一个使用的知识源，确定下一个知识源需要使用知识源判断自己是否能处理黑板组建上的结果，黑板组建责用于几率知识源产生的结果。
优点：可以验证 有助于提高可修改性和可维护性 知识源课重用 可提高容错能力和健壮性
缺点：难以测试 不保证能提供满意的解 难以制定上号的策略 效率低 开发工作量大 不支持并行
分布式系统
分布式系统的优点： 经济实惠 性能和可扩展性 固有分配行 可靠性
1 Broker(中间人模式)
组件图
该模式主要有三部分 client broker server 。 client用于发起请求 broker用于分发服务，server用于处理请求， 另外client proxy是属于client部分，用处对数据进行额外处理，同样server provy属于server部分。 bridge的意图时用于 将三部分接偶，可通过不同的bridge导向不同的server和client （其实android中binder就是一个这样的结构 binder驱动就是中间人）
存在以下几个情景
1情景1 服务向中间人注册
情景2 客户端向本地服务发送请求
情景3 不同中间人通过网络交互
优点：位置透明，组件可修改可扩展 可移植 不同broker系统之间的互操作性 可重用性
缺点：效率不高，容错性差 测试和调试困难
交互式系统
人机交互西东，多为含有界面的程序
交互式系统开发起来比较容易，因为人工操作分散了逻辑
Mode-View-Controller（mvc）模式
常见的gui程序几乎都属于mvc模式或mvc模式变种
该模式分为三部分，数据模型，控制器，界面， 界面用于显示数据，并且通过界面传递事件给控制器处理逻辑，更新数据，数据变化又出发控制器更新界面。
组件
动态：
情景1 用户输入导致模型变化，进而出发变更传播机制
情景2 组件初始化
优点：一个模型可以有多个视图，视图同步，可插入的视图和控制器，可更换外观，可开发框架
缺点：更复杂 更新可能过度频繁 视图和控制器关系紧密 视图和控制器与模型耦合 视图和控制器访问效率底下，移植必须修改视图和控制器 使用较新的用户界面工具时难以遵循mvc
presentation-Abstraction-Contril(PAC)模式
定义了一种适用于交互式系统的结构－由相互协作的只能体组成的层次结构。每个只能体都负责应用程序功能的特定方面，并包含三个组件：表示组件，抽象组件和控制组件，这将只能的人机交互方向功能核心同通信分离
注意整个系统由多个pac模块组成，每个模块由pac模块组成。各pac模块采用树状结构，最上层为最基础模块，逐层组合下上层逻辑。
以下均以政治选举信息系统为例子介绍（用户输入表格，系统可将数据绘制成饼图，柱状图，席位分布图）。
静态结构
PAC智能体内部结构：
动态图
情景1 打开新的选举数据柱状图时，不同pac智能体之间的协作，还描述了柱状图pac内部行为
情景2 描述输入新数据后系统的行为，详细说明顶层pac智能体的内部行为
为了控制器起作用 ，这个getDate 流程有点长哈，必然使复杂度上升
优点： 分离关注点 支持修改和扩展 支持多任务（控制线程完成同步控制）
缺点：系统更复杂 复杂的控制组件，效率底下
