moco代码赏析十一

今天来看一下2012.11.7的后三次提交，这三次提交做的事情是比较统一的：用RequestExtractor、ContentRequestExtractor、XPathRequestExtractor、HeaderRequestExtractor、UriRequestExtractor来替代了ContentMatcher、HeaderRequestMatcher、XPathRequestMatcher、Header、XPath。

新加入了一个接口：RequestExtractor。

    public interface RequestExtractor {
        String extract(HttpRequest request);
    }

ContentRequestExtractor、XPathRequestExtractor、HeaderRequestExtractor实现了这个接口，重写了extractor()方法。这个方法的作用就是从请求中提取出xpath、header或者stream，表达会更加准确。再由以上三种extractor生成EqRequestMatcher对象，从这一步和以前的实现方式是统一的，所以作者无需改动测试类的调用方法。这也是这份代码写的好的地方之一，一直在遵循一个原则，把接口的方法与内部方法隔离开，耦合很低，所以当内部扩展时，并不会改变外部的调用。

    public class EqRequestMatcher implements RequestMatcher {
        private RequestExtractor extractor;
        private String expected;
    
        public EqRequestMatcher(RequestExtractor extractor, String expected) {
            this.extractor = extractor;
            this.expected = expected;
        }
    
        @Override
        public boolean match(HttpRequest request) {
            return this.expected.equals(extractor.extract(request));
        }
    }

之所以把这几个类由matcher转变成extractor，就是因为这几个extractor的作用和and/or、get/post、EqRequestMatcher起到的作用不同，他们不应该在同一层中出现。不过这次改动也把之前几个matcher的组合模式变成了类组合模式，并不严格遵守组合模式。设计模式也是为了解耦合，易扩展，可读性强，如果有其他更好的方式实现，何乐而不为呢？不应该为了使用设计模式而使用设计模式，本末倒置。