抽象永远是软件工程领域较难的命题，因为它没有规则，没有标准，甚至没有对错，只分好坏，只分是否适合。同样一份淘宝商品模型的领域抽象，可以算是业界标杆了，但它并非适合你的系统。那我们该如何驾驭“抽象”呢?UML的创始人Grady booch在 Object Oriented Analysis and Design with Applications 一书中，提到了评判一种抽象的品质可以通过如下5个指标进行测量：耦合性、内聚性、充分性、完整性与基础性。

1 耦合性

一个模块与另一个模块之间建立起来的关联强度的测量称之为耦合性。一个模块与其他模块高度相关，那它就难以独立得被理解、变化或修改。TCL语言发明者John Ousterhout教授也有同样的观点。我们应该尽可能减少模块间的耦合依赖，从而降低复杂度。

Complexity is caused by two things: dependencies and obscurity.

--- John Ousterhout 《A Philosophy of Software Design》

译：复杂性是由两件事引起的：依赖性和模糊性。

但这并不意味着我们就不需要耦合。软件设计是朝着扩展性与复用性发展的，继承天然就是强耦合，但它为我们提供了软件系统的复用能力。如同摩擦力一般，起初以为它阻碍了我们前进的步伐，实则没有摩擦力，我们寸步难行。

2 内聚性

内聚性与耦合性都是结构化设计中的概念，内聚性测量的是单个模块里，各个元素的的联系程度。高内聚低耦合，是写在教科书里的观点，但我们也并非何时何地都应该盲目追求高内聚。

内聚性分为偶然性内聚与功能性内聚。金鱼与消防栓，我们一样可以因为它们都不会吹口哨，将他们抽象在一起，但很明显我们不该这么干，这就是偶然性内聚。较希望出现的内聚是功能性内聚，即一个类或模式的各元素一同工作，提供某种清晰界定的行为。比如我将消防栓、灭火器、探测仪等内聚在一起，他们是都属于消防设施，这是功能性内聚。

3 充分性

充分性指一个类或模块需要应该记录某个抽象足够多的特征，否则组件将变得不用。比如Set集合类，如果我们只有remove、get却没有add，那这个类一定没法用了，因为它没有形成一个闭环 。不过这种情况相对出现较少，只要当我们真正去使用，完成它的一系列流程操作后，缺失的一些内容是比较容易发现并解决的。

4 完整性

完整性指类或模块需要记录某个抽象全部有意义的特征。完整性与充分性相对，充分性是模块的较小内涵，完整性则是模块的较大外延。我们走完一个流程，可以清晰得知道我们缺哪些，可以让我们马上补齐抽象的充分性，但可能在另一个场景这些特征就又不够了，我们需要考虑模块还需要具备哪些特征或者他应该还补齐哪些能力。

5 基础性

充分性、完整性与基础性可以说是3个相互辅助相互制约的原则。基础性指抽象底层表现形式较有效的基础性操作(似乎用自己在解释自己)。比如Set中的add操作，是一个基础性操作，在已经存在add的情况下，我们是否需要一次性添加2个元素的add2操作?很明显我们不需要，因为我们可以通过调用2次add来完成，所以add2并不符合基础性。

但我们试想另一个场景，如果要判断一个元素是否在Set集合中，我们是否需要增加一个contains方法。Set已经有foreach、get等操作了，按照基础性理论，我们也可以把所有的元素遍历一遍，然后看该元素是否包含其中。但基础性有一个关键词叫“有效”，虽然我们可以通过一些基础操作进行组合，但它会消耗大量资源或者复杂度，那它也可以作为基础操作的一个候选者。