3.5 要么为继承而设计, 并提供文档说明, 要么就禁用继承

  • 继承是传播性的, 使用继承必须考虑到所有的super中是否有影响

  • 合理暴露方法, 需要认真设计好哪些方法应该是private 哪些protected 哪些 public,因为任何 public 和protected 方法都可能被继承(除非你声明final 禁止指定方法被覆盖)

  • 方法之间如果有顺序或者依赖性, 要考虑被覆盖后,是否会导致问题出现

  • 文档说明要及时准确, 否则可能导致使用者错误的使用

如果无法控制好继承体系, 上一篇建议的复合可以考虑

  • 继承当然不是一无是处, 因为大部分情况下,我们的工作是小组的形式, 而每个人有自己的大概维护范围,同时你也可以很方便找到他们 ,继承的缺点其实也不是一定会那么大, 比如我们就经常设计 BaseDao , BaseService ,

  • 包括jdk 也有非常多的继承的类, 以上的说明只是帮我们认识到继承体系在极端情况下可能带来的问题, 对这些东西有个心理预期

  • 总之, 合理利用继承, 知道某些(很多)情况下, 复合同样也可以解决我们的问题. 不要只知道继承就可以了

资源下载: