针对第五章——“弯曲，或折断”的论述。
生活中我们常常会面临一些困境，不得不做出一些改变。写代码也是如此，保持代码的灵活性，以保证在应对各种突发情况时，都有补救的方法，我认为这是一个合格的程序员所具备的能力。
一般我们为某个目标而写一些类的时候，经常会让彼此有一定的关系。这种关系就像是在二者之间插上一根铁棍让彼此相连，这种硬性连接确实起到了显著作用，但也让代码失去了它的灵活性，至少在出现问题的时候，一定会发生相应的连锁反应，因此，使耦合减至最小，是我们的目标。为了减至最小，我们会联想到“得墨忒耳法则”，但请注意，这种法则并不是在任何情况下都适用的，它可能会在具有较大响应集的类中更容易出现错误。
第二就是“元程序设计”，这里需要用到元数据，即关于数据的数据，最常见的可能是数据库schema或数据词典。在使用元数据时，要尽可能多地通过元数据配置和驱动应用，我们的目标应该是以声明方式思考，并创建高度灵活和可适应的程序。此外，我们还需要培养自己的商业逻辑，因为与项目的其他方面比较，商业政策与规则更有可能发生变化，这时以一种非常灵活的格式维护它们很有意义。
除了模块耦合之外，还有时间耦合。在代码方面我们对时间的考虑的可能只有时间复杂度，但我们在工程中要考虑并发与次序。如果在这方面节省时间的话，我们要熟悉工作流，看看有没有什么是可以“同步”的。在做并发设计的同时，还要考虑到接口问题，“杂乱”的接口容易发生失误，我们需要尽可能地让接口更加“整洁”。
开发的时候你不可能直接跟客户谈代码，他们听不懂，这时候需要抽象成视图让对方去理解，这种概念我们都知道。一般的视图谁都会做，问题是怎样把它变得巧妙一些。书中提到一个观点：使视图与模型分离。这带来的是灵活性，这也只是其中一个考虑方向，还有其他的改进之处，需要我们去发现。
最后便是“黑板”，在项目中，都会有一个讨论的过程，它往往是围绕着简单的黑板模型设计解决方案。这时候，就有了“黑板系统”的概念，它最初是为在人工智能中应用而发明的。我们也可以用它来做些事情。