在子类中设置一些属性后调用方法的超类实现的java
我正在为Android应用程序制作baseactivity。我需要在子类的onCreate方法中设置一些属性,然后再调用它的超类实现来完成这项工作。那么这是一种不好的做法吗?要在子类中设置属性,然后调用设置属性的方法的超类实现
多谢各位
你可以在下面搜索框中键入要查询的问题!
我正在为Android应用程序制作baseactivity。我需要在子类的onCreate方法中设置一些属性,然后再调用它的超类实现来完成这项工作。那么这是一种不好的做法吗?要在子类中设置属性,然后调用设置属性的方法的超类实现
多谢各位
# 1 楼答案
是的,这是个坏习惯
# 2 楼答案
不,我不会说这一定是坏习惯。事实上,这在面向对象语言中相当常见。这样想,通常您希望覆盖或扩展某些超类行为。这样做时,您有三个基本选项:
根本不要调用超类版本。例如,如果要完全替换旧行为
调用超类版本,然后执行一些额外的操作。如果您想保留旧的行为,然后向其添加您自己的扩展
做一些额外的事情,然后调用超类版本(然后可能再做一些额外的事情)。如果您想影响旧的行为而不必完全替换/重新实现它
当然,当您从1->;移动时,脆性会增加;2->;3.如果像#1中那样完全绕过超类方法,那么将来对超类的更新几乎不可能破坏代码。如果调用超类方法,然后添加自己的代码,则超类中的未来更改将导致代码中断的可能性更大,特别是如果您的代码依赖于超类代码执行所导致的任何副作用。最后,如果你在调用超类方法之前通过注入副作用来添加影响超类方法的代码,那么你的代码有一天被超类更新破坏的可能性更大,因为超类的作者无法知道您正在使用哪些副作用来影响它的行为,并且没有义务继续以相同的方式对它们做出响应
因此,我们需要进行权衡。选项#3可能是解决问题的最快方法,但它也最有可能因未来对超类的更改而意外中断,因为它依赖于有关超类实现行为的各种假设。这是否是一个严重的问题取决于超类更改的频率、您所依赖的行为更改的可能性、您接受修改后的超类版本时的控制程度、,无论您是否拥有超类和子类的代码所有权,切换到选项2或选项1有多困难,依此类推
归根结底,这并不是一个好的实践与坏的实践的问题,更多的是了解每个选项的优缺点,并选择最适合您的项目的选项