所谓"抽象化"，就是指从具体问题中，提取出具有共性的模式，再使用通用的解决方法加以处理。
抽象时机应遵循以下原则：
1. DRY原则（Don't repeat yourself）
也就是说，如果多次遇到同样的问题，就应该抽象出一个共同的解决方法，不要重复开发同样的功能。
2. YAGNI原则（You aren't gonna need it）
这是"极限编程"提倡的原则，指的是你自以为有用的功能，实际上都是用不到的。因此，除了最核心的功能，其他功能一概不要部署，这样可以大大加快开。
3. Rule Of Three原则
Rule of three 称为"三次原则"，指的是当某个功能第三次出现时，才进行"抽象化"。
抽象时应遵循的原则：
1. 单一职责原则
单一职责是指一个模块应该只做一件事，并把这件事做好。
2. 开放封闭原则（Open/Closed Principle, OCP）
开放封闭原则是指对扩展开放，对修改封闭。
3. 依赖倒置原则（Dependency Inversion Principle, DIP）
依赖倒置原则是指高层模块不应该依赖于低层模块的实现，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖与抽象。前面提到，“软件领域的任何问题，都可以通过增加一个间接的中间层来解决”. 其实所有的协议和标准化都是 DIP 的一种实现。包括 TCP、HTTP 等网络协议、操作系统、JVM、Spring 框架的 IOC 等等。设计模式里有不少模式，也是典型的依赖倒置，例如状态模式、工厂模式、代理模式、策略模式等等，下图是策略模式的结构图。
4. 里氏替换原则（Liskov Substitution Principle, LSP）
里氏替换原则是指子类必须能够替换成它们的基类
5. 接口隔离原则（Interface Segregation Principle, ISP）
接口隔离原则是指客户端不应该被迫依赖它们不使用的方法。比如一个类继承了一个无法实现的接口。
6. 迪米特法则（Law of Demeter）
它是指模块不应该了解它所操作的对象的内部情况。
下面这种情况就不符合迪米特法则：
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
