我组织类时无意间遵守了依赖倒置原则

我每次開始写一个小项目的时候，都想把项目中的那些类组织得优雅一些，但最后的代码总是一团糟，这让我非常痛苦。我把希望寄托于设计模式，希望它能帮我解脱。遗憾的是，从接触设计模式到如今，已经快三年了，我的代码就仅仅出现过单例模式。

只是，从今天開始，一切都不一样了，我的代码里多了依赖倒置原则。
在讲依赖倒置原则在我的代码里的详细呈现之前，先总体说一下设计模式六大原则：
（1）单一职责原则。说的是一个类应该仅仅干一件事儿。
（2）里氏替换原则。说的是，程序中用子类对象替换父类对象。不应该改变程序行为。
（3）依赖倒置原则。说的是。高层不应该依赖低层，它们都应该依赖抽象。
（4）接口隔离原则。说的是。一个接口的大小应该设计得刚好，不应该出现一个类去实现一个接口须要实现与自己无关的方法。
（5）迪米特原则。

说的是，低耦合高内聚，也就是说，一个类应该尽量仅仅依赖与它的域、方法參数和返回类型类。

（6）开闭原则。说的是。一个程序应该对扩张开发，对改动关闭。（原则中的原则，它是其他原则的目标）
个人觉得，在这六个原则里，最难明确的就是依赖倒置原则了，我也是今天刚刚略懂了。

接下来，看看我的代码里是怎遵守这个原则的。

我有一个文件工具类，这个类提供遍历以指定目录形成的文件树并对遇到的文件及目录实施指定的操作的功能。

对遇到的文件及目录详细实施什么样的操作。如今并不知道，我自然没办法如今就告诉文件工具类如今干嘛。可是不知道详细操作，这个文件工具类没法開始写啊。于是我如今能做的就是告诉文件工具类一个抽象操作，于是我抽象出一个接口：

public interface FileOperate {
    public void action(File file);
}

然后能够開始写文件工具类了：

public class FileTools {
    /**
     * 单线程后根遍历文件树。对遇到的文件及目录运行指定的操作
     * 
     * @param startDirectory 起始目录
     * @param fileOperate 对目录的操作
     * @param fileOperate 对文件的操作
     */
    public static void traverse(File startDirectory,
            FileOperate directoryOperate, FileOperate fileOperate) {
        File[] childFiles = startDirectory.listFiles();
        for (File file : childFiles) {
            if (file.isFile()) {
                fileOperate.action(file);
            } else {
                traverse(file, directoryOperate, fileOperate);
            }
        }
        directoryOperate.action(startDirectory);
    }
}

文件工具类写好了。后来。我知道我想删除某个文件树上全部文件名称包括index的文件，可是不正确遇到的目录做不论什么操作，于是我写了以下两个类，传给FileTools的traverse方法：

public class DoNothing implements FileOperate {

    @Override
    public void action(File file) {

    }

}

public class DeleteIndexFile implements FileOperate {

    @Override
    public void action(File file) {
        String fileName = file.getName();
        if (fileName.contains("index")) {
            file.delete();
        }

    }

}

后来。我又想删除某文件树中的非html文件以及空目录。于是，我又写了以下两个类传给FileTools的traverse方法：

public class DeleteEmptyDirectory implements FileOperate {

    @Override
    public void action(File file) {
        if (file.isDirectory()) {
            file.delete();
        }
    }

}

public class DeleteNoneHtmlFile implements FileOperate {

    @Override
    public void action(File file) {
        String fileName = file.getName();
        if (!fileName.endsWith("html")) {
            file.delete();
        }

    }

}

到这里。大家应该发现。FileOperate和FileTools的设计是对扩展开放的。对改动关闭的，它是一个不错的设计。为什么会有这种结果了，由于它遵守了依赖倒置原则。

FileTools依赖FileOperate，DoNothing 等详细实现类也依赖FileOperate。它们都依赖抽象， 高层模块（FileTools）不依赖底层模块（DoNothing ）。
我的这个遵守依赖倒置原则的小项目说完了，如今来说说。理解这个原则的难点——倒置体如今哪里？通常情况。是高层依赖底层。就像靠纳税人钱生活的人总是依赖着纳税人。毕竟拿人家的手短，这和FileTools使用详细的操作一样，可是如今FileTools不直接依赖详细操作了，它仅仅是依赖抽象FileOperate，而详细操作也依赖抽象FileOperate，抽象是最高层，于是变成了低层依赖高层了。这相似于我们常常感受不到那些靠纳税人钱活着的人真是如此。由于我们的税是由第三方交的。
最后，我能够说，我的代码变得优雅了一点儿了，设计模式是能够指望的。