David Wheeler有一句名言：“计算机科学中的大多数问题都可以通过增加一层间接性来解决。”间接代表着迂回。世间没有哪一条道路是完全笔直的。蜿蜒曲折的道路并非出于美的灵感，不过是因为我们需要绕开路途中的障碍罢了。

我们在设计中遇到的最大障碍，无疑就是变化。若能御变化于实现之外，软件开发就会变得美好。

应对变化的要诀是隔离。设计者需要界定对象的不变部分与可变部分，然后将可变部分隐藏起来，即使发生了变化，也不会影响到外部。这就是封装的含义。正如地壳核心的变化如此的狂暴与迅捷，但对于地面上生活的人类而言，几乎微不可察。然而，一旦地壳的变化冲出地表，就会酿成天大的灾难。变化对软件系统造成的灾难，并不亚于地震或者火山。封装为对象内部的实现设定了一层隔离带，将复杂变化的业务逻辑或者算法策略隐藏在对象之内。只要保证对象的接口不发生变化，调用者与对象内部的实现就可以单独演化了。

当我们发现一个对象需要依赖另一个不稳定的对象，同时，还需要执行复杂的交互逻辑时，就可以考虑引入一个新的对象来封装这些逻辑，从而解除二者之间的耦合，隔离变化。Spring MVC中的ModelAndView对象扮演的正是这一角色。根据MVC模式，控制器需要将模型对象所持有的数据以及数据的变化呈现到视图中。它通过寻找正确的视图对象，完成页面的展现。控制器承担了这一职责，就意味它必须依赖于视图对象。例如这样的代码：

public class CustomerController implements Controller { 
    @Override 
    public View handleRequest( 
            HttpServletRequst request, 
            HttpServletResponse response) throws Exception { 
        Map model = new HashMap(); 
        model.put(“customers”, getCustomerList()); 
        return new InternalResourceView(”/WEB-INF/jsp/customerList.jsp”); 
    } 
}

View具体对象的创建，使得CustomerController与InternalResourceView紧紧地绑定起来，失去了灵活性，导致我们无法***改变View的实现。作为一个灵活的MVC框架，显然很难容忍这二者之间的强耦合。要打破这种耦合关系，就需要封装寻找以及创建视图的职责，并将这一职责放到合适的对象中。这正是引入ModelAndView类的缘由。Controller放心地将所有与View相关的职责转移给ModelAndView，而它只需要悠闲地传递一个视图名称即可。

public class CustomerController implements Controller { 
    @Override 
    public ModelAndView handleRequest( 
            HttpServletRequst request, 
            HttpServletResponse response) throws Exception { 
        Map model = new HashMap(); 
        model.put(“customers”, getCustomerList()); 
        return ModelAndView(”customerList”, model); 
    } 
}

通过字符串类型的名称常量去寻找合适的视图，而不是具体的View对象，就使得Controller冲破了View类型的约束，变得自在而开放。因为封装的作用，Controller对象变得无知，然而，“无知者无畏”，它也不用害怕视图呈现所发生的变化了。隔离变化的另一条途径是寻觅对象的共性，对这些共性进行抽象。我们不必考虑对象实现细节的不同之处，只需要把握对象的共同特征，即可完成接口的定义。接口可以看做是对象的角色。Rebecca认为：“客户访问接口比访问具体类要灵活得多，它们不需要知道具体实现，而只需明了接口中声明的公共角色即可。”【注：Rebecca Wirfs-Brock《对象设计：角色、责任和协作》】角色代表一种功能或职责的扮演，它并非演员本身，只是形象化地以某种形态或语言来表现角色的喜怒哀乐而已。例如，我们需要在项目中指定规则以限定渲染的格式。这个规则可以是数据区间，只要数据在这个区间范围之内，就应该设置为对应的格式；也可以是某种约束条件，当条件满足时，以相应的格式渲染。从实现细节来看，区间与约束是迥然不同的两种实现；可是从抽象的角度看，它们无疑扮演的都是同一种角色，那就是匹配器。只要规则匹配，就应该获得正确的格式。public interface Matcher { 
    public boolean matches(Object value); 
}

public class Range implements Matcher{ 
    private double min; 
    private double max; 
    public Range(double min, double max) { 
        this.min = min; 
        this.max = max; 
    } 
    private boolean in(double data) { 
        //判断data是否在此区间 
    }

    public boolean matches(Object value) { 
        try { 
            return in((double)value); 
        }catch (InvalidCastException) { 
            return false; 
        } 
    } 
}

public class Constraint implements Matcher { 
    private String expected; 
    private boolean ignoreCase; 
    public Constraint(String expected) { 
        this.expected = expected; 
        ignoreCase = true; 
    }

    public Constraint(String expected, boolean ignoreCase) { 
    } 
    public boolean matches(Object value) { 
        if (ignoreCase) { 
            return expected.equalsIgnoreCase(value.toString()); 
        } else { 
            return expected.equals(value.toString()); 
        } 
    } 
}

Matcher接口抽象了区间与约束的共性特征，使得二者在规则中能够友好相处： 
public class Rule { 
    public Rule(Matcher matcher, Format format){} 
    public Matcher getMatcher(){} 
    public void setMatcher(Matcher matcher){} 
    public Format getFormat(){} 
    public void setFormat(Format format){} 
}

如果需要更多的匹配器，只要实现Matcher接口，就可以放入Rule中，作为格式规则的一部分。这种包容变化的能力，正是抽象能够提供的。

本文转自wayfarer51CTO博客，原文链接：http://blog.51cto.com/wayfarer/478189，如需转载请自行联系原作者