本博客为笔者阅读《程序员修炼之道：从小工到专家》的读书笔记十一月第一篇，也是整个过程的第五篇，值得一提的是，每月两篇正好八篇，而本书正好八章，因此每一篇博客都将是对于对应章节的记录和感受描写
26.解耦与德墨忒尔法则
前文正交性和合约设计的羞怯工作方式，不向别人暴露你自己，不与太多人打交道；
德墨忒尔法则，最小知识原则，把代码组织成最小单位/模块，并限制他们之间的交互；
使耦合程度最少；对象间的直接关系导致依赖关系的组合爆炸，修改影响很多模块，害怕修改；
德墨忒尔试图使程序中的模块耦合程度减至最低，设法阻止你为了获得第三个对象的方法访问而进入某个对象；
把你的代码组织成最小单位（模块），并限制他们之间的交互。如果随后必须替换某个模块，其他模块仍能够继续工作。
应使耦合减至最少。对象间直接的横贯关系，有可能很快带来依赖关系的组合爆炸。比如对某个模块的“简单”改动会传遍系统中的一些无关模块。
函数的得墨忒耳法则，它规定了某个对象的任何方式都应该只调用属于以下情形的方法：
- 它自身
- 传入该方法的任何参数
- 它创建的任何对象
- 任何直接持有的组件对象
得墨忒耳法则的好处是它使得代码的适用性更好，更健壮，但这也有一定的代价。如果某些解耦的操作很复杂，或者解耦带来某些时间和空间的重大开销，这时就需要根据实际情况考虑，可以暂时舍弃该法则。
27.元程序设计
细节会弄乱我们整洁的代码，把细节赶出代码；
动态配置：让系统高度可配置，不要集成，用元数据描述应用的配置选项：参数，偏好，安装目录等；
元数据，是关于数据的数据；
将抽象放进代码，将细节放进元数据
迫使你解除你的设计的耦合；
迫使你通过推迟细节处理，创建更健壮、抽象的设计
无需重新编译应用，可以对齐进行定制；
与通用编程语言比，可以用更接近问题领域的方式表式元数据；
不要变写渡渡鸟代码：
没有元数据，代码及不能有它的适应性与灵活性；
元数据是关于数据的数据，即对应用进行描述的数据。典型情况，元数据在运行时，而不是编译时被访问和使用。
我们想要让我们的系统变得高度可配置，像是屏幕颜色，提示文本等，这些应该作为配置项而不是作为代码集成到项目中。
以声明方式思考（规定要做什么，而不是怎么做），并创建高度灵活的可适应的程序。结合元数据就是，将抽象放进代码，细节放进元数据。
Enterprise Java Beans 是一个用于简化分布式、基于事务的环境中的编程框架。它处理了不同机器、在不同数据库供应商之间，不同线程及复杂平衡的事务。它的使用只需我们编写一个 bean，并将其放到 bean container 中。
更好的协作式配置是让应用自身适应其环境，进行动态配置。
28 时间耦合
- 时间是软件架构设计经常忽略的因素：并发和次序；
- 日常编写程序，经常事情是线性的；
- 通过容许并发，解除任何时间或次序上的依赖；
-
在设计架构时，用服务进行设计而不是组件。饥饿的消费者模型是在多个消费者进程间进行快速而粗糙的负载平衡的一种有效途径。编写线性代码，我们很容易做出一些假定，把我们引向不整洁的编程。但并发会迫使你更仔细的对事情进行思考。尽可能使用线程安全的类，开发时也应尽可能设计线程安全的类。
29 它只是视图
- 事件使得系统耦合减至最少；
- 发布/订阅；推模式/拉模式；
- 视图与模型分离：
- 模型：表示目标对象的抽象数据模型；
- 视图：解释模型的方式
- 控制器：控制视图，并向模型提供新数据的途径
30 黑板
黑板方法：没有侦探需要知道其他任何侦探的存储；侦探可能受过不同训练，具有不同程度的背景；
很多项目设计工作流或分布式数据采集过程；
黑板系统让我们完全解除我们的对象之间的耦合，提供一个”论坛“，知识消费者和生成者可以在哪里匿名，异步交换数据；
一种键值对模型为基础实现；
与黑板有单一、一致的接口；消除了太多接口的需要，带来更优雅、一致的方案；
例子：黑板，结合封装法律需求的规则引擎；
原文地址：http://www.cnblogs.com/Arkiya/p/16844550.html
