第5章 弯曲，或折断

读书笔记 摘自：《程序员修炼之道》

---

26 解耦与得墨忒耳法则　

36. 将模块之间的耦合减至最少
Minimize Coupling Between Modules
通过编写 “羞怯的”代码并应用得墨忒耳法则来避免耦合。

对象间直接的横贯关系有可能很快带来依赖关系的组合爆炸：
１.这样的大型项目，用于链接某个单元测试的命令比测试程序自身还要长。　
２.对某个模块的“简单”改动会传遍系统中的一些无关模块。
３.开发者害怕改动代码，因为他们不清楚哪些代码可能会受到影响。

依赖关系保持最少！　　适应性更好、更健壮
违反规范化规则，以换取速度。使若干模块紧密耦合，可以获得重大的性能改进

迪米特法则（Law of Demeter），意译的话是”最少知识原则”。这里采用如此奇怪的音译显得很唐突。

解耦包含逻辑解耦与物理解耦，其实关键就是一个：最少知识原则。能不知道的就尽量别知道，能不依赖的就尽量别依赖。当你写代码是发现需要再include一个头文件时：三思。

27 元程序设计　　

37. 要配置，不要集成
Configure, Don’t Integrate
要将应用的各种技术选择实现为配置选项，而不是通过集成或工程方法实现。
38. 将抽象放进代码，细节放进元数据
Put Abstractions in Code, Details in Metadata
为一般情况编程，将细节放在被编译的代码库之外。

系统变得高度可配置。适应性，灵活性

以声明方式思考（规定要做什么，而不是怎么做），并创建高度灵活和可适应的程序。
为一般情况编写程序，把具体情况放在别处－在编译的代码库之外。
推迟大多数的细节定义，易于改动。

• 基础点讲，就是不要硬编码；
• 提升点讲，就是指软件的配置信息，尽量保存在在注册表中，或者配置文件中，可以动态配置
• 再提升点，就是软件设计中我们要封装变化，比如封装在接口之后，但如果可行，封装到代码之外才是最灵活的。

28 时间耦合　　

39. 分析工作流，以改善并发性
Analyze Workflow to Improve Concurrency
利用你的用户的工作流中的并发性。
40. 用服务进行设计
Design Using Services
根据服务—-独立的、在良好定义、一致的接口之后的并发对象—-进行设计。
41. 总是为并发进行设计
Always Design for Concurrency
容许并发，你将会设计出更整洁、具有更少假定的接口。

时间有两个方面很重要：并发（事情在同一时间发生）和次序（事情在时间中的相对位置）
容许并发，并考虑解除任何时间和次序上的依赖。

主要讲并发，要考虑并发，就要考虑：
1. 单个操作是否足够独立
2. 多个操作是否可以并行。

不要只考虑程序中并发，看看你的工作中，你们团队中工作流程的并发要求。

29 它只是视图

42. 视图与模型分离
Separate Views Form Models
要根据模型和视图设计你的应用，从而以低廉的代码获取灵活性。

不要把程序写出一大块，分而治之

ＭＶＣ既让模型与表示模型的ＧＵＩ分离，也让模型与管理视图的控件分离
MVC模式，我觉得是观察者模式的一种特殊情况。通过接口实现了具体类之间的解耦，并实现了发布/订阅的工作模式。

30 黑板

43. 用黑板协调工作流
Use Blackboards to Coordinate Workflow
用黑板协调完成不同的事实和因素，同时又使各参与方保持独立和隔离。

是更进一步的解耦，连Item29中需要的共同接口都解掉了。

部分评论摘自豆瓣书评

---

===========文档信息============
读书笔记由博主整理编辑，供非商用学习交流用
版权声明：非商用自由转载-保持署名-注明出处
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://my.csdn.net/dkjkls