《程序员修炼之道》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
用黑板协调工作流