第五章 弯曲，或折断

为了赶上今天近乎疯狂的变化步伐，我们需要尽一切努力编写尽可能宽松灵活的代码。否则，我们可能就会发现我们的代码很快就会变得过时，或是太脆弱，以至于难以清理。

1. 解耦与得墨忒耳法则

好篱笆促成好邻居

a) 把你的代码组织成最小组织代码(模块)，并限制它们之间的交互.当我们要求某个对象完成特定服务时，我们想要它替我们完成该服务。我们不希望这个对象给我们一个第三方对象，我们必须对其加以处理才能获得所需的服务。对象间直接的横贯关系很可能很快带来依赖关系的组合爆炸

b) 德墨忒尔法则也叫“最少了解原理”，它旨在使模块之间的耦合减至最小。某个对象的任何方法都应该只调用属于以下情形的方法：

它自身

传入该方法的任何参数

它创建的任何对象

任何直接持有的组件对象

c) 使用德墨忒尔法则将使你的代码适应性更好、更健壮，但也有代价：作为“总承包人”，模块必须直接委托并管理全部子承包人，而不牵涉你的模块的客户。在实践中，这意味着你会编写大量包装方法，它们只是把请求转发给被委托者，这些包装方法既会带来运行时代价，还会带来空间开销。有时需要对该法则折中，通过反转德墨忒尔法则，来提升性能。

d) 除了逻辑上的解耦，在设计时还要考虑物理的解耦，考虑组成系统的文件、目录与库之间的关系。

2. 元程序设计

再多的天才也无法胜过对细节的专注。每次改动代码，都会有引入新的bug的危险

a) 动态配置

1) 要让系统变得高度可配置，文本提示、算法、数据库产品、界面风格等，让这些作为配置选项，而不是集成到系统里。

2) 可以使用元数据来描述应用的配置选项。元数据是关于数据的数据，更宽泛的说，是任何对应用进行描述的数据。

b) 元数据驱动的应用

1) 除了使用元数据来配置简单地偏好，还可以通过元数据配置和驱动应用。为了达到以声明方式思考（规定要做什么，而不是怎么做），并创建高度灵活的程序的目的，我们采用一条一般准则：把抽象放进代码，细节放进元数据。

2) 这样做的好处：迫使你接触你的设计的耦合，使程序更灵活；迫使你通过推迟细节处理，创建更健壮、更抽象的设计；虚无·无需重新编译应用，就可以对其进行定制。通过推迟大多数细节的定义，并尽可能让细节保持“软和”，让系统尽可能易于改动。

c) 商业逻辑。商业逻辑与政策更有可能发生变化，以一种非常灵活的格式维护它们很有意义。

d) 不要编写渡渡鸟代码。毛里求斯岛上的渡渡鸟不能适应人类和她们的家畜的出现，很快就灭绝了。同样的，没有元数据，代码就没有足够的适应性，项目也将很快“灭绝”。

3) 时间耦合

a) 时间在两个方面对软件很重要：并发（事情在同一时间发生）和次序（事情在时间中的相对位置）。大多数人的思考方式是线性的，总是先做这个，然后再做那个，但这会带来时间上的耦合。我们需要容许并发，并考虑接触任何时间或次序上的依赖。

b) 总是为并发进行设计

1) 编写线性代码，我们很容易做出一些假定。但并发迫使你更仔细地对问题进行思考-这不再是你一个人的舞会。

2) 必须对任何全局或静态变量加以保护，使其免于并发访问

3) 不管调用的次序是什么，都需要确保给出的是一致的状态信息。

c) 如果在设计时就考虑并发，可以更容易地满足可伸缩性或需求性能，而设法给非并发应用增加并发会困难很多。

欢迎关注我的个人公众号【菜鸟程序员成长记】

《程序员修炼之道》笔记(四)