1700456694
1700456695
private final static ArrayList＜NovelBook＞bookList=new ArrayList＜NovelBook＞（）；
1700456696
1700456697
把原有IBook的依赖修改为对NovelBook实现类的依赖，想想看，我们这次的扩展是否还能继续下去呢？一旦这样设计，我们就根本没有办法扩展，需要修改原有的业务逻辑（也就是main方法），这样的扩展基本上就是形同虚设。
1700456698
1700456699
最后，如果我们在IBook上增加一个方法getScope，是否可以呢？答案是不可以，因为原有的实现类NovelBook已经在投产运行中，它不需要该方法，而且接口是与其他模块交流的契约，修改契约就等于让其他模块修改。因此，接口或抽象类一旦定义，就应该立即执行，不能有修改接口的思想，除非是彻底的大返工。
1700456700
1700456701
所以，要实现对扩展开放，首要的前提条件就是抽象约束。
1700456702
1700456703
2.元数据（metadata）控制模块行为
1700456704
1700456705
编程是一个很苦很累的活，那怎么才能减轻我们的压力呢？答案是尽量使用元数据来控制程序的行为，减少重复开发。什么是元数据？用来描述环境和数据的数据，通俗地说就是配置参数，参数可以从文件中获得，也可以从数据库中获得。举个非常简单的例子，login方法中提供了这样的逻辑：先检查IP地址是否在允许访问的列表中，然后再决定是否需要到数据库中验证密码（如果采用SSH架构，则可以通过Struts的拦截器来实现），该行为就是一个典型的元数据控制模块行为的例子，其中达到极致的就是控制反转（Inversion of Control），使用最多的就是Spring容器，在SpringContext配置文件中，基本配置如代码清单6-11所示。
1700456706
1700456707
代码清单6-11 SpringContext的基本配置文件
1700456708
1700456709
＜bean id=“father”class=“xxx.xxx.xxx.Father”/＞
1700456710
1700456711
＜bean id=“xx”class=“xxx.xxx.xxx.xxx”＞
1700456712
1700456713
＜property name=“biz”ref=“father”＞＜/property＞
1700456714
1700456715
＜/bean＞
1700456716
1700456717
然后，通过建立一个Father类的子类Son，完成一个新的业务，同时修改SpringContext文件，修改后的文件如代码清单6-12所示。
1700456718
1700456719
代码清单6-12 扩展后的SpringContext配置文件
1700456720
1700456721
＜bean id=“son”class=“xxx.xxx.xxx.Son”/＞
1700456722
1700456723
＜bean id=“xx”class=“xxx.xxx.xxx.xxx”＞
1700456724
1700456725
＜property name=“biz”ref=“son”＞＜/property＞
1700456726
1700456727
＜/bean＞
1700456728
1700456729
通过扩展一个子类，修改配置文件，完成了业务变化，这也是采用框架的好处。
1700456730
1700456731
3.制定项目章程
1700456732
1700456733
在一个团队中，建立项目章程是非常重要的，因为章程中指定了所有人员都必须遵守的约定，对项目来说，约定优于配置。相信大家都做过项目，会发现一个项目会产生非常多的配置文件。举个简单的例子，以SSH项目开发为例，一个项目中的Bean配置文件就非常多，管理非常麻烦。如果需要扩展，就需要增加子类，并修改SpringContext文件。然而，如果你在项目中指定这样一个章程：所有的Bean都自动注入，使用Annotation进行装配，进行扩展时，甚至只用写一个子类，然后由持久层生成对象，其他的都不需要修改，这就需要项目内约束，每个项目成员都必须遵守，该方法需要一个团队有较高的自觉性，需要一个较长时间的磨合，一旦项目成员都熟悉这样的规则，比通过接口或抽象类进行约束效率更高，而且扩展性一点也没有减少。
1700456734
1700456735
4.封装变化
1700456736
1700456737
对变化的封装包含两层含义：第一，将相同的变化封装到一个接口或抽象类中；第二，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。封装变化，也就是受保护的变化（protected variations），找出预计有变化或不稳定的点，我们为这些变化点创建稳定的接口，准确地讲是封装可能发生的变化，一旦预测到或“第六感”发觉有变化，就可以进行封装，23个设计模式都是从各个不同的角度对变化进行封装的，我们会在各个模式中逐步讲解。
1700456738
1700456739
1700456740
1700456741
1700456743
设计模式之禅 6.5 最佳实践
[
上一页 ]
[ :1.700456694e+09 ]
[
下一页 ]