<<面向模式的软件架构2-并发和联网对象模式>>读书笔记

服务访问和配置模式

Wrapper Facade可以将有非对象API提供的函数和数据封装到面向对象的类接口中

就是把底层API再封装一次，让外部不用关心是调用哪个平台的API，不如锁，在不同的平台上可能是不同的函数，所以直接封装成一个统一的命名

1. 如何根据平台来进行判断封装的函数要调用哪个函数
1. 使用#ifdef
2. 使用编译器的设置，把不同的平台实现放在不同的目录，编译的时候自动根据一些平台设置的宏定义去查找对应的目录

优点:
1. 简洁，内聚，健壮的高级面向对象编程接口
2. 可移植性和可维护性

缺点:
1. 功能丧失，每增加一层抽象，都可能丧失访问下一层抽象的功能
2. 性能降低
3. 编程语言和编译器的局限性

Component Configure 让应用程序能够在运行阶段加载和卸载组件的实现

就是程序提供一个虚接口，然后各个子组件去根据这个接口进行开发，就是利用DLL在做插件

优点:
1. 统一性
2. 集中管理
3. 模块化，可测试性和可重用性
4. 动态的控制和配置
5. 调整和优化

缺点:
1. 不确定性及未考虑依赖，一个dll可能花太多时间导致其他dll无法处理事件
2. 降低安全性和可靠性
3. 增加了运行时的开销和基础设施的复杂度

Interceptor可以透明地给框架添加服务，并且在特定的事件发生时自动触发他们

其实就是hook，指定一个接口，然后其他人实现这个接口，像handle注册这个接口，然后事件发生的时候再去回调这个接口，有点类似于qt的 event filter

优点:
1. 可扩展性和灵活性
2. 分离关注点
3. 支持对框架进行监视和控制
4. 分层对称
5. 可重用性

缺点:
1. 复杂的设计问题，预测使用的具体框架的需求不简单，很难判断哪些需要提供分派程序
2. 恶意或者错误的拦截器
3. 潜在的连锁拦截

Extension Interface可以避免因开发人员扩展和修改既有组件的服务功能，导致接口膨胀及客户端代码失效

其实就是COM的这种模式，很丑陋的接口，通过dynamic_cast， 获取IID等来获取对应的V1, V2的类

优点:
1. 可扩展性
2. 分工明确
3. 支持多态
4. 组件及其客户端的分离
5. 支持接口聚合和委托

缺点:
1. 增加了组件和设计实现的工作量
2. 增加了客户端编程的复杂度
3. 额外的间接性和运行时开销

事件处理模式

Reactor， 等待指示事件的发生，分离出事件并且将他们交给复杂处理这些事件的相关事件处理程序

Proactor，在异步处理程序中主动地发起一个或者多个异步请求，然后发送到事件处理程序

proactor和reactor区别可能就在这里，proactor是其他的线程去处理IO，然后IO发生以后再通知处理线程，而reactor是当前线程去处理IO

Asynchronous Completion Token

有点类似于信号，发生IO 了后发送信号，只是这个信号是一个接口，接口里面保存了你要处理的一些数据，感觉跟reactor和proactor差不多，可能是我现成的async io框架用多了，感觉没什么实际的东西

Acceptor-Connector

将SOCKET的句柄传送给其他类进行处理，分派程序只是负责接收句柄

同步模式

scope_lock

其实就是boost的scope_lock

strategized locking

在boost里面scopet_lock都需要制定是mutex还是其他mutex,比如boost::scope_lock<boost::mutex>

thread safe interface

就是 std::unique_lock，不会重复获得锁

double-checked locking

单件里面一个很经典的问题

并发模式

Active object

将方法执行和方法调用分离，就是发送一个function到另外一个县城处理

Monitor Object

单线程调用对象

Half-sync和Half-Async模式

将系统里面的异步和同步服务处理分离，简化编程，又不降低性能

Leader-followers模式

多个线程轮流询问事件源，然后对发出的服务进行处理

thread-specific storage

就是访问thread local对象