在面对日后项目不确定的变更，需求的迭代，如何尽量保持代码的可撤销性，今天分享一下。（可撤销性在另一个分享里讲到，大家可以在找一下拿来品味品味。）

做出可撤销性的决策以使自己的代码在面对不确定的世界时保持灵活性和可适应性。

首先我们看一下耦合-解耦与得墨忒耳法则/迪米特法则

得墨忒耳定律（Law of Demeter，缩写LoD）亦称为“最少知识原则（Principle of Least Knowledge）”，是一种软件开发的设计指导原则，特别是面向对象的程序设计。得墨忒耳定律是松耦合的一种具体案例。该原则是美国东北大学在1987年末在发明的，可以简单地以下面任一种方式总结:

每个单元对于其他的单元只能拥有有限的知识：只是与当前单元紧密联系的单元；

每个单元只能和它的朋友交谈：不能和陌生单元交谈；

只和自己直接的朋友交谈。

一个简单例子是，人可以命令一条狗行走（walk），但是不应该直接指挥狗的腿行走，应该由狗去指挥控制它的腿如何行走。遵循Demeter法则的优点是所得到的软件更易于维护和适应。由于对象较少依赖于其他对象的内部结构，因此可以在不重新处理其调用者的情况下更改对象容器。可以降低软件错误的概率，因为每个类中定义的方法的数量可以增加软件错误的可能性。

一个多层架构可以被认为是在软件系统中实现迪米特法则有系统的机制。在分层体系结构中，每个层中的代码只能调用层中的代码和下一层内的代码。“跳层”会违反分层架构。1

缺点尽管LoD增加了软件系统的适应性，但它可能（但不一定会）导致必须编写许多包装器方法来传播对组件的调用;在某些情况下，这会增加明显的时间和空间开销。

元程序设计

保持灵活的一种好办法是少写代码，“元程序设计”将解释怎么把各种细节完全移出代码，这样会更容易修改。要配置不要集成，例如设置一款扫地机器人，每4小时清洁地面一次，每8小自动充电1小时。

如果将其写入配置文件或配置规则里，在每次进行调整时即可脱离代码层的耦合，不用在代码里每次的改动，从而做到了灵活性、适配性。

为并发设计编程

缩写线性代码，我们很容易做出一些假定，把我们引向不整洁的编程。但并发迫使你更仔细地对事情进行思考，这不再是一个人的舞会，因为事情现在可能会在“同一时间”发生，你可能会突然看到某些基于时间的依赖关系。一旦设计了具有并发要素的架构，对许多并发服务的处理进行思考就会变得更容易：模型变成了普通的。

还有一种技术就是可以进一步解除模块间的耦合，就是提供一个“聚会地点”，让各个模块在那里进行交换数据。