服务访问和配置模式
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对象