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 最佳实践
1700456744
1700456745
软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的。我们要为不可预料的事情做好准备，这本身就是一件非常痛苦的事情，但是大师们还是给我们提出了非常好的6大设计原则以及23个设计模式来“封装”未来的变化，我们在前5章中讲过如下设计原则。
1700456746
1700456747
❑Single Responsibility Principle：单一职责原则
1700456748
1700456749
❑Open Closed Principle：开闭原则
1700456750
1700456751
❑Liskov Substitution Principle：里氏替换原则
1700456752
1700456753
❑Law of Demeter：迪米特法则
1700456754
1700456755
❑Interface Segregation Principle：接口隔离原则
1700456756
1700456757
❑Dependence Inversion Principle：依赖倒置原则
1700456758
1700456759
把这6个原则的首字母（里氏替换原则和迪米特法则的首字母重复，只取一个）联合起来就是SOLID（solid，稳定的），其代表的含义也就是把这6个原则结合使用的好处：建立稳定、灵活、健壮的设计，而开闭原则又是重中之重，是最基础的原则，是其他5大原则的精神领袖。我们在使用开闭原则时要注意以下几个问题。
1700456760
1700456761
❑开闭原则也只是一个原则
1700456762
[
上一页 ]
[ :1.700456713e+09 ]
[
下一页 ]