架构师训练营第三周学习总结

第三周的课程以设计模式为主，介绍了六种设计模式，并以一个排序问题为引子，一步一步介绍涉及的各种模式，之后又引入测试模块，介绍JUnit中使用的设计模式。



1. Simple Factory Pattern

简单工厂模式没什么好说的，课上提到了可以利用反射和配置文件进行优化。如果是C++的话可以使用COM的Guid模拟反射。



1. Singleton Pattern



单例模式简单明了，只能拥有一个实例的类，核心思想是将构造函数设为私有，且类内使用静态成员存储单例对象。在课上看了Java的单例模式实现，相比C++还是简单了不少的。而且C++还存在一些坑，如拷贝构造函数和赋值运算符重载最好显示删除。使用静态对象（static Singleton instance）可以实现线程安全。



1. Adapter Pattern

适配器模式更推荐使用右面的方式，不会违反LSP。



1. Strategy Pattern

策略模式适合在有多种执行逻辑（策略）可供选择时使用。



1. Composite Pattern

组合模式适合构造树形结构。



1. Decorator Pattern (Wrapper)

装饰模式十分灵活，各种装饰器之间可以任意组合。这令我想起之前自己做的一个项目，其中有一部分就使用了类似的思想。但是当时并不清楚这就是装饰模式。



除去设计模式，老师在课程上还提到了他之前做个的一个将SQL转译为HQL的项目，在介绍这个项目的时候说，困难的问题可以解决，复杂的问题不好解决。在解决问题时，和学校不同，工作中遇到的问题几乎很少有不能解决的，如果遇到困难也会寻求替代方案。但是接踵而至的是，虽然几乎所有问题都可以解决，但是由于问题本身可能设计到多人协作或是其他条件，虽然也许很快就可以找到多种解决方案，但也许仍然有更好的方案。这句话中提到的“困难”便是如此，设计精妙的架构很困难，但是一旦完成了受益极大。看似简单的方案可能会使系统陷入“复杂”的深渊，各个模块犬牙交错，最后只能推倒重来。就像我在之前的公司写了一些数据预处理的代码，本来这部分只是清洗数据然后存入数据库，但是随着不同客户的数据格式不同，即使格式相同但含义不同，这部分的逻辑变得越来越复杂。后来我在离职前交接了很久，不过后来再有机会回去时发现由于当时的逻辑过于复杂且没有清晰的架构，已经大部分被重写了。