1700484750
❑检查是否存在配置文件中配置的方法。
1700484751
1700484752
❑检查方法的返回值是否是String，并且无输入参数，同时必须继承指定类或接口。
1700484753
1700484754
逻辑校验需要把所有的对象都初始化一遍，在Action类较多的情况下，效率较低，但它可以提前发现出现访问异常的情况，把问题解决在萌芽状态。我们继续来看两个策略的场景类，如代码清单38-7所示。
1700484755
1700484756
代码清单38-7 策略的场景类
1700484757
1700484758
public class Checker{
1700484759
1700484760
//使用哪一个策略
1700484761
1700484762
private IXmlValidate validate；
1700484763
1700484764
//xml配置文件的路径
1700484765
1700484766
String xmlPath；
1700484767
1700484768
//构造函数传递
1700484769
1700484770
public Checker（IXmlValidate_validate）{
1700484771
1700484772
this.validate=_validate；
1700484773
1700484774
}
1700484775
1700484776
public void setXmlPath（String_xmlPath）{
1700484777
1700484778
this.xmlPath=_xmlPath；
1700484779
1700484780
}
1700484781
1700484782
//检查
1700484783
1700484784
public boolean check（）{
1700484785
1700484786
return validate.validate（xmlPath）；
1700484787
1700484788
}
1700484789
1700484790
}
1700484791
1700484792
与通用策略模式稍有不同，每个模式在实际应用环境中都有其个性，很少出现完全照搬一个模式的情况，灵活应用设计模式才是关键。
1700484793
1700484794
在FilterDispatcher的init方法中，我们刚刚说它有两个职责：第一个职责是XML文件校验，这个我们完成了；第二个职责是启动监控程序。问题是要监控什么呢？监控XML有没有被修改，如果修改了就立刻通知校验程序对它进行校验。这就又用到了观察者模式：发现文件被修改，它立刻通知检查者处理，该片段的类图如图38-5所示。
1700484795
1700484796
1700484797
1700484798
1700484799
图38-5 XML文件监控类图