moco代码赏析三

今天看的是作者的第三次提交，这次提交并没有添加哪些实质性的功能，而是重构了一些类和方式的命名，以及对现有的项目结构做了一些调整。之前的实现方式依然存在耦合比较多的情况并且命名方式比较模糊，新的实现方式则是创建了两个新的接口RequestMatcher和ResponseHandler，这两个接口分别代表的是输入时参数的匹配器与返回时的结果处理器。从很直观的看，这次改动会让一个从没看过之前代码的人，可以简单的通过代码的架构和类的命名来看懂这些类的作用以及如何使用这个项目。同时，把之前在MocoServer中的两个方法: withContent()和withUri()放在了Moco类中，并重命名。

    public RequestSetting withContent(String requestContent) {
        return new ContentRequestSetting(this, requestContent);
    }

    public RequestSetting withUri(String uri) {
        return new UriRequestSetting(this, uri);
    }

    public static RequestMatcher eqUri(String uri) {
        return new UriRequestMatcher(uri);
    }

    public static RequestMatcher eqContent(String content) {
        return new ContentRequestMatcher(content);
    }

我认为这两个方法确实不应该属于一个服务器类里，暂时放在了这个程序的入口Moco我觉得只是暂时的策略，后期一定会把这两个方法重构在其他地方。

---

前面提到的RequestMatcher有两个实现类，分别是ContentRequestMatcher类和UriRequestMatcher类，他们替代了前有的RequestSetting实现类。并且作者将之前并没有实现的match中的逻辑实现了，做到了根据匹配Request中的参数来组装他的Response。谈到组装Response，作者在本次提交中，将原有的实现方式（在MocoHandler全部包办），改成了把writeToResponse()方法分离出来写进ResponseHandler的方式，再由ResponseHandler调用不同实现类中的不同的writeContent()方法，这样实现好处在于，我可以根据调用response()方法时，传入的参数不同而采用不同的策略。

---

这一次的提交，总体给人的感觉就是更加清晰了，无论是项目的结构还是作者的思路，都让我一个局外人看的更加清楚。