敏捷设计
当开发人员最初编写一个模块时，代码对于他们来说看起来也许是清晰的。这是由于他们使自己专注于代码的编写，并且他们对于代码非常的熟悉。在熟悉减退以后，他们或许会回过头来再去看那个模块，并想知道他们怎么会编写如此糟糕的代码。为了防止这种情况的发生，开发人员必须要站在代码阅读者的位置，共同努力对他们的代码进行重构，这样代码的阅读者就可以理解代码。他们的代码也需要被其他人评审。
So, in short, the agile developers knew what to do because they followed these steps.
1. They detected the problem by following agile practices.
2. They diagnosed the problem by applying design principles.
3. They solved the problem by applying an appropriate design pattern.
单一职责原则SRP
就一个类而言，应该仅有一个引起它变化的原因。
SRP是所有原则中最简单的之一，也是最难正确运用的之一。我们会自然地把职责结合在一起。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。
开闭原则OCP
在许多方面，OCP都是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处（也就是，灵活性、可重用性以及可维护性）。然而，并不是说只要使用一种面向对象语言就是遵循了这个原则。对于应用程序中的每个部分都肆意地进行抽象同样不是一个好主意。正确的做法是，开发人员应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。
Liskov 替换原则（LSP）
表面看起来，好像没有问题。其实隐藏着一个别扭的设计问题。加入到第三方持久性集合中的元素必须得从PersistentObject派生。由于PersistentSet只是把调用委托给第三方持久性集合，所以任何要加入PersistentSet的元素也必须得从PersistentObjet派生。可是，Set的接口没有这样的限制。
OCP是OOD中很多说法的核心。如果这个原则应用得有效，应用程序就会具有更多的可维护性、可重用性以及健壮性。LSP是使OCP成为可能的主要原则之一。正是子类型的可替换性才使得使用基类类型的模块在无需修改的情况下就可以扩展。这种可替换性必须是开发人员可以隐式依赖的东西。因此，如果没有显式地强制基类类型的契约，那么代码就必须良好地并且明显地表达出这一点。
术语“IS-A”的含意过于宽泛以至于不能作为子类型的定义。子类型的正确定义是“可替换性的”，这里的可替换性可以通过显式或者隐式的契约来定义。
依赖倒置原则（DIP）