好抽象要在简化与灵活性间取舍

提高编程抽象层次的基本困境是：如何设计出真正简单、又不丢失太多灵活性的模型？如果开发人员想在硬盘上直接建立快速索引，文件流抽象反而会成为阻碍。最好的抽象要能解决和封装问题中最难的部分，同时仍为使用者保留足够灵活性：封装太多或者封装错了，抽象就会变得毫无用处；封装太少，又达不到简化编程的目的——正如Alan Kay所说，”简单的事情应该简单，但依旧保有完成复杂事情的可能”。MapReduce是个好例子：它抽象并封装了分布式数据处理中最难的部分（大量工作者实例的调度、失败节点的处理、数据的聚合），同时仍为程序员留有足够的灵活性来解决各种各样的问题。

结构图：

flowchart LR
  A["封装太多/封错<br/>→抽象毫无用处"]
  B["理想抽象<br/>封装最难的部分+保留灵活性"]
  C["封装太少<br/>→达不到简化目的"]
  A -.-> B
  C -.-> B
  B --> M["例:MapReduce封装调度/容错/聚合,仍留灵活性"]