Head First 设计模式 —— 04. 工厂 (Factory) 模式

思考题

如何将实例化具体类的代码从应用中抽离，或者封装起来，使它们不会干扰应用的其他部分？ P111

• 将实例化具体类的代码放入一个对象中管理，通过不同入参决定实例化具体的类

简单工厂

不是23种GOF设计模式之一，而更像一种编程习惯。 P117

特点

• 通常利用静态方法创建实例，但这样无法通过继承来改变创建方法的行为。 P115

  缺点

• 违反开闭原则，增加产品时需要修改工厂类。

工厂方法模式

定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。 P134

特点

• 工厂方法让类把实例化推迟到子类。 P134
• “决定”指选用哪个子类，就决定了实际创建哪个子类。 P134
• 增加产品或改变产品的实现，不会影响工厂接口。 P135

缺点

• 新增产品时，需要增加新的工厂，增加代码复杂性。

抽象工厂模式

提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。 P156

特点

• 抽象工厂的方法经常以工厂方法的方式实现。 P158
• 把一群相关的产品集合起来。 P159

  缺点

• 新增新的相关产品时，需要修改接口和实现类。 P159

设计原则

• 依赖倒置原则：要依赖抽象，不依赖具体类。 P139
  • 不能让高层组件依赖低层组件，并且不管高层组件或低层组件，都应该依赖于抽象。 P139
  • 低层组件依赖于高层抽象。 P141
  • 避免违反依赖倒置原则的指导方针（可根据实际情况尽量遵循） P143
    • 变量不可以持有具体类的引用
      • 即没有 import 具体类，可以使用工厂避免具体类的引用
    • 不要让类派生自具体类
      • 【书上解释】使用时可能会依赖具体类，可是让类派生自接口或抽象类
      • 【自己想法】只要具体类派生自接口或抽象类，就可以让类派生自该具体类
    • 不要覆盖基类中已实现的方法
      • 【书上解释】基类中已实现的方法，应该由所有的子类共享
      • 【自己想法】书上前面也提到基类可以提供默认的方法，子类可以覆盖为自己的实现 P135

所思所想

• 其实平时写代码时很多时候都倒置了自己的思考方式，比如：依赖某个接口的不同实现完成不同的小功能时，不会先去写具体的实现，而是根据接口先完成上层的代码框架，再具体完成每一个实现类。
• 虽然书中说了工厂方法和抽象工厂的区别，但还是感觉两个区别不大，只是在应用场景有点区别。工厂方法指创建一类产品，而抽象工厂关键相关的多类产品。当相关的产品只有一类时，抽象工厂就是工厂方法。

  本文首发于公众号：满赋诸机（点击查看原文） 开源在 GitHub ：reading-notes/head-first-design-patterns