面对对象中的继承
优势以下:框架
- 代码共享,减小建立类的工做量,每一个子类都拥有父类的方法和属性
- 提升代码的重用性
- 子类能够形如父类,但又异于父类
- 提升代码的可扩展性,不少开源框架的扩展接口都是经过继承父类来实现的
- 提升产品或项目的开放性
缺点以下:spa
- 继承是侵入性的.只要继承,就必须拥有父类的全部属性和方法
- 下降代码的灵活性.子类必须拥有父类的属性和方法,让子类自由的世界中多了些约束
- 加强了耦合性.当父类的常量、变量和方法被修改时,须要考虑子类的修改,有时更会带来很是糟糕的结果--大段代码须要重构
里氏替换原则的定义
若是对每个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的全部程序P在全部的对象o1都代换成o2时,程序P的行为没有发生变化,那么类型S是类型T的子类型.设计
通俗点讲,只要父类能出现的地方子类就能够出现,并且替换成子类也不会产生任何错误或异常,使用者可能根本不须要知道是父类仍是子类.可是反过来就不行了,有子类出现的地方,父类未必能适应.对象
里氏替换原则的规范(继承的规范)
1.子类必须彻底实现父类的方法blog
例若有一个打枪的游戏,类图以下继承
其 Soldier 代码以下接口
注意: 在类中调用其余类时,要使用父类或接口,不然就违背了里氏替换原则游戏
这时,若是有一个玩具枪 ToyGun, 继承自 AbstractGun,显然是不合适的,由于玩具枪没有伤害,能够新建一个抽象类 AbstractToy,将声音、形状都委托给 AbstractGun 处理,而后两个基类下的子类自由延展,互不影响产品
注意: 若是子类不能完整的实现弗雷的方法,或者弗雷的某些方法在子类中已经发生"畸变",则建议断开父子继承关系,采用依赖、汇集、组合等关系替代class
2.子类能够有本身的个性
里氏替换原则能够正着用,但不能反着用.在子类出现的地方,父类未必就能够胜任
3.覆盖或实现父类的方法是输入参数能够被放大
举个例子,先定义一个 Father 类
而后再定义一个子类:
虽然子类方法与父类方法同名,但不是覆写父类方法,而是重载,由于输入参数不一样
父类的参数范围小,当调用子类 doSomething方法时,若参数为HashMap调用父类方法,若为Map调用子类方法
要是反过来,子类的 参数比父类范围下,就违背了里氏替换原则
4.覆写或实现父类的方法是输出结果能够被缩小
这个也不难理解,也就是说父类方法返回的是Map时,子类能够返回HashMap
可是反过来,父类返回的是HashMap,而子类返回Map类型就违背了里氏替换原则
采用里氏替换原则的好处
加强程序的健壮性,版本升级是也能够保持很是好的兼容性.即便增长子类,原有的子类还能够继续运行.在实际项目中,每一个子类对应不一样的业务含义,使用父类做为参数,传递不一样的子类完成不一样的业务逻辑,完美!
采用里氏替换原则,应尽可能避免子类的"个性",一旦子类有"个性",这个子类和父类之间的关系就很难调和了,把子类看成父类使用,将子类的"个性"抹杀;把子类单独做为一个业务来使用,会让代码间的耦合关系变得扑朔迷离