Andy Niu �����ĵ�

项目应用场景：协议本身是一个载体，与不同的外部服务交互，格式不同，有些是xml格式，有些是json格式。
因此需要不同的打包解包子类，根据交互的格式需要，指定打包解包的子类。这就是策略模式。

参见

1、考虑用户（这个用户可能是自己也可能是其他的程序员）的需求：给出一个汽车类型，获取一个汽车对象。怎么办？
2、使用简单工厂。如下：
    创建抽象类ICar，具体类Sedan（轿车）和具体类SportCar继承ICar。
    创建简单工厂类，根据汽车类型（使用switch），创建汽车对象返回。
3、用户需求变化，要求给出SUV类型，获取SUV汽车对象。怎么办？
4、增加具体类SUV，继承ICar。在简单工厂类增加switch的分支。但是这存在问题：
    a、具体类SUV满足开闭原则，而简单工厂类不满足开闭原则，要修改简单工厂类的代码，增加分支。
    b、同时简单工厂类是个上帝类，需要返回一切需要的汽车对象。
    怎么办？
5、使用工厂方法。如下：
    创建抽象工厂IFactory，以及具体工厂类SedanFactory和SportCarFactory。
    当用户需要SUV的时候，增加一个工厂类SUVFactory，满足开闭原则。
6、用户需求变化，期望获取一个品牌的轿车和跑车，比如给出奔驰，期望获取奔驰轿车和奔驰跑车。
    如果用户还是使用工厂方法，用户可能会用SedanFactory获取奔驰轿车，但是用SportCarFactory获取宝马跑车。
    这就导致了使用windows的锤子去敲linux的钉子，不匹配。要把用户想象的就是这么傻。怎么解决这个问题？
7、这就涉及到产品族的概念，解决办法是使用抽象工厂。如下：
    创建抽象工厂IFactory，以及具体工厂类BenZFactory和BmwFactory。
    BenZFactory有两个方法，分别负责生产奔驰轿车和奔驰跑车，
    BmwFactory有两个方法，分别负责生产宝马轿车和宝马跑车。
    这样，再傻的用户也不会出错，生产出来的轿车和跑车是匹配的，也就是同一品牌。

参见

1、开闭原则
2、里氏代换
3、面向抽象编程（依赖倒转）
4、接口隔离（最小接口）
5、合成聚合原则（使用合成聚合替代继承）
6、迪米特法则（不和陌生人说话）

参见

项目应用场景：我们的服务会接入不同的设备，比如大华设备，海康设备，这些设备sdk的接口不同，需要抽象出一种设备。
需要根据不同的设备类型进行适配。下层有适配器管理器和一组适配器，服务告诉适配器管理是哪一种设备，
适配器管理器创建出一个适配器，设备适配器与具体的设备交互。这个odbc的道理一样。odcb可以认为是适配器管理器，
mysql的odbc驱动是适配器，负责与mysql服务交互，oracle的odbc驱动是适配器，负责与oracle交互。

参见