里氏替换原则--java设计模式

本文章参考《设计模式之禅》、《设计模式精解》等。

在《设计模式之禅》关于里氏替换原则中开头就讲了继承的优缺点，现总结如下：

        优点：1、代码共享；相当于一件衣服制作一次，两个人都可以穿，这样当然会省布料；

                   2、提高代码的重用性；

                   3、子类可以形视父类，但又异于父类；

                   4、提高代码的可扩展性；

                   5、提高产品或项目的开放性。

          缺点：

                   1、继承是侵入性的，因为它必须拥有父类的属性和方法，就像富二代接班时自然就有了父亲资产，责任，企业法人等等这些属性（如果要接班的话）。

                   2、降低代码的灵活性；3、增加了耦合性。

 

      原有定义是：If for each object o1 of type S there is an object o2 type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

      原谅我英文不好，上文如此拗口，以至于我读不下去。

      依照简单的解释就是：子类可以替换父类，但是父类不可替换子类。就这么简单，因为父类有的，子类一定都有，但是子类有的，父类不一定就有。

       注意：如果子类不能完整的实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集，组合等关系代替继承。OK，以上是《设计模式之禅》的，但是个人觉得他这是重新解释了一些继承而已；

      下面是重点：在《设计模式精解》中讲到了原则和策略，作如下总结：

       开放-封闭原则：模块，方法和类应该对扩展是开放的，而对更改是封闭的。换一句话说就是：业务修改了，但是要少修改代码；对，是的。也就是说：提高扩展性。

       从场景的角度去进行设计的原则：

       针对未来都是场景的产品，作为架构师，思维一定也要从产品的绝对的高度，并对产品的将来有一定的预见性的基础上去设计架构，这样无论业务作出多大的变化，架构的思维模式也不会大变，只会小处修改。

       从场景的角度去分析能够让我们的思维角度直接关照到现实的业务及交互场景，而不再只是关注一段又一段的代码。

       这里截图给大家看看：

       

              在《设计模式精解》中写道：作者设计的目标之一是：决不让一个类包含两件变化并以某种方式耦合在一起的事物。

         但是要学会适度包容。