再看设计模式——工厂方法与抽象工厂模式

传统GOF的24种设计模式中有两个工厂模式:工厂方法(factory method) vs 抽象工厂(absctract factory),而通常又能听到所谓的简单工厂模式(simple factory)。实际上简单工厂的实现就是一个static的工厂创建方法,也就是工厂方法,两个是同一个东西。 工厂方法模式在工程实现上可以使用map替代switch case,用来关联产品标识符和具体产品类型(这 …

阅读全文

再看设计模式——状态模式与策略模式

根据不同的状态,执行不同的行为。相比switch case思路,使用状态模式能让数据与行为封闭性更好,添加新的状态也比较简单,状态间的切换逻辑不用刻意去维护,但是不如switch切换状态顺序流那么清晰。 实际实现中状态模式对”开闭原则”的支持并不太好。有两种实现存放的思路: 静态状态。初始化时把所有可能的状态对象都new好,状态切换时通过赋值改变当前的状态。 实例化状态。每 …

阅读全文

再看设计模式——单例模式

这个模式其实就是要保证只有一个实例存在。通常的实现思路就是持有一个私有静态实例,保证仅一次初始化,以getInstance方法返回。但是实际实现这个模式要考虑更多细节:  线程安全与DLC 单例对象的析构与销毁 组件中单例对象的管理 单例模式的单元测试 使用C++实现还必须额外注意一些实现细节 静态成员变量初始化顺序不依赖构造函数, 多个单例可能初始化顺序不对 延迟初始化(第一次使用才初始化)需要 …

阅读全文

volatile与内存屏障总结

一. 内存屏障 Memory Barrior 1.1 重排序 同步的目的是保证不同执行流对共享数据并发操作的一致性。在单核时代,使用原子变量就很容易达成这一目的。甚至因为CPU的一些访存特性,对某些内存对齐数据的读或写也具有原子的特性。但在多核架构下即使操作是原子的,仍然会因为其他原因导致同步失效。 首先是现代编译器的代码优化和编译器指令重排可能会影响到代码的执行顺序。 其次还有指令执行级别的乱序 …

阅读全文

Zookeeper系统设计的缺陷

之前总结过Zookeeper的各种设计优点,但是这个系统的缺陷与优点同样突出,本文就是结合自己的使用经验,业界给出的评价对ZK的缺点进行的归纳,一方面归纳使用表现上的不足,另一方面根据个人经验总结出系统本身功能设计时的就存在的缺陷。同时也思考了相应对策与改进的办法,算是本人对ZK设计的完整的思考总结吧。最后还关注了下etcd这个后起之秀的设计,看看它是否已经弥补了ZK的不足,能否担当后继者。 1. …

阅读全文