第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
用黑板协调工作流
网友评论