今天总结的是程序员修炼之道的第四部分内容：
Chap5 弯曲，或折断
解耦：任何一个单独的模块尽量不要依赖其他模块的特性，除了有些特殊情况下会违背这个原则换取一定的效率。
元数据：用于将代码功能灵活化。将容易改变的、不确定的数据用“元数据”进行配置而不要固定地编织到代码中；可以将某些并非模块固定功能的逻辑（比如客户的个性化需求）通过配置而非代码的方式表示，这样就不用反复为了适应需求而修改代码、重新编译。可以时不时检查加载新的配置以免修改配置便需要重启的麻烦状况。
时间的解耦：进行流程分析，分析各任务时间上的相互依赖，进行并发编程，可以提高程序的效率。要对全局变量、静态数据的访问与调用进行保护。接口要设计得更整洁，避免接口对调用时间的依赖。
发布/订阅协议：某个模块只关心特定的事件，并对不同事件分别作出响应。模块通过“订阅”(subscribe)某个事件对事件作出响应。而模块引发某个事件时，依次调用各个订阅者通知事件发生。
MVC：将Model（数据模型）， View（视图）和Controller（视图控制器）解耦。MVC模型虽然用于GUI开发，但可以更泛化地理解为Model为抽象数据模型；View为解释模型的方式，向Model与Controller订阅事件；Controller控制View并向Model提供新数据，向Model与View发布事件。
黑板：将各个信息放在一个信息流里，各模块与信息流进行交互，从而可以达到统一简便的交互，而不需要在各个模块之间两两规定严密的发布/订阅协议，发布者与订阅者不需要了解对方。
这个设计用于较为复杂，每个模块的行为都会带来新的改变，随时有可能有事件发生并引起其他模块的行为的系统，此时在各个模块之间一一设计接口几乎不可能。
这个设计很优美，但我产生了两个疑惑：这样大的数据量是否会对数据的维护和模块的查找带来负担？是否会出现信息泄漏的风险？对于第一个问题，维护问题我没有想好，但查找可以通过良好地组织数据结构简化；对于第二个问题，可以通过限制权限得到改善，但似乎还是会有风险。