《程序员修炼之道》Tips摘录04

第5章 弯曲，或折断 Bend，or Break

26. 解耦与得墨忒耳法则

提示36: Minimize Coupling Between Modules
使模块之间的耦合减至最少

使用得墨忒耳法则将使你的代码适应性更好、更健壮，但也有代价：作为“总承包人”，你的模块必须直接委托并管理全部子承包人，而不牵涉你的模块的客户。

27. 元程序设计

细节会弄乱我们整洁的代码——特别是如果它们经常变化。每当我们必须去改动代码，以适应商业逻辑、法律或管理人员个人一时的口味的某种变化时，我们都有破坏系统——或引入新bug——的危险。

提示37: Configure,Don't Integrate
要配置，不要集成

元数据到底是什么？
严格地说，元数据是关于数据的数据。
最为常见的例子可能是数据库schema或数据词典。
schema含有按照名称、存储长度及其他属性、对字段（列）进行描述的数据。

提示38: Put Abstractions in Code,Details in Metadata
将抽象放进代码，细节放进元数据

28. 时间耦合

时间有两个方面对我们很重要：并发（事情在同一时间发生）和次序（事情在时间中的相对位置）。

提示39: Analyze Workflow to Improve Concurrency
分析工作流，以改善并发性

要善于画图，找出其中的可并行性。
还是要深入了解自己做的事情。

提示40: Design Using Services
用服务进行设计

不能依赖巧合编程。

提示41: Always Design for Concurrency
总是为并发进行设计

29. 它只是视图

通过单个例程推送所有事件为什么不好？它破坏了对象封装——现在一个例程必须对许多对象间的交互有密切的了解。

发布/订阅:

提示42: Separate Views from Models
使视图与模型分离

30. 黑板

提示43: Use Blackboards to Coordinate Workflow
用黑板协调工作流