设计模式之富基类模式

我通常是反面向对象派生的，不是今天的题目，不展开说。

纯粹一点其实与好与不好无关，但是却不合算，文雅一些叫做不实际，但是不如合算来得精确。

反面向对象设计的一个有力工具是接口，为某个 Unit of Work，设计一个高内聚的接口。面对各种场景实现这一接口。实现接口避免了派生带来的各种系统牵扯，达到更灵活的复用的目的。纯洁也有代价，实现类中存在通用的逻辑，这时可以借助富基类。

把通用的操作封装在函数中，保存在通用的基类上，但是需要遵守一个基本原则：

共享的函数需是无状态的，所有的状态都保存在参数中。如果语言支持：

1. 定义为静态方法，或者类方法
2. 访问控制设置为 protected

如果不使用富基类，有两种思路：

1. 使用单独的工具函数类，比如接口 ImportDriverInterface，定义工具类 ImportDriverUtil, ImportDriverHelper，但是这两个名字一般是用来辅助调用者，也许应该改成 ImportDriverImplUtil, ImportDriverImplHelper 。
   这个方法的缺点是需要引入一个顶级的名字，定义，使用，查找比较麻烦，也暴露了内部实现。
   Util, Helper 其实是个很糟的名字，无法通过名字知道他提供什么功能。
2. 部分语言支持在接口中定义静态方法，也可以使用。优点是方便，缺点是暴露了实现，也给类库使用者带来困扰和疑惑。

面向接口，面向函数编程，日益觉得一项重要的工作是控制顶层名字。组件颗粒度变小，顶层名字变多了，不知道如何起名，如何设计 namespace/package layout，使用富基类，至少名字看上去要清晰一些。比如约定命名为 BaseImportDriver 或者 AbstractImportDriver，一眼就知道他的目的。