BestPractices:将标准类子类化为一个做同样事情但是"假设"未来变化的新OOP是不是很糟糕？

Question

我过去有过类似的案例,这只是一个例子来说明:

我将在我的Android应用程序中实现一个新功能(但这适用于任何类型的OO项目),此时我需要在每个活动中的每个edittext中的"setVisibility"方法中实现一些"操作"有.

要做到这一点,我必须子类"EditView",并覆盖"setVisibity"方法:

@Override
public void setVisibility(int visibility)
{
    super.setVisibility(visibility);
    // --> do my stuff here! <--
}

到目前为止,这么好......问题是要改变我所有的活动(超过200个,以及thounsands代码行),然后我想:" 为什么我没有启动项目继承标准的EditText,"我知道某些事情,我需要实现这样的事情 ".

这就是重点:将"标准类"子类化为一个做同样事情的新标准是不是很糟糕,但只是"假设"这样的情况？我的意思是,将所有东西都分类,比如按钮,活动等.

AFAIK,设计模式和OOP不鼓励"推定因素",但我会根据您的编程经验,听听您们"在现实生活中做什么"(或考虑一下).

此外,也许这种类型的问题("你的想法","你的意见")在这里不是一个好的做法,但我找不到任何更好的地方来实现它.

Answer 1

除非您实际进行更改,否则没有理由删除代码.这是浪费精力,只是膨胀你的代码库.

如果您发现自己处于重复进行相同修改的情况,请考虑重构以共享公共代码.或者在某些情况下,生成这些代码片段是有好处的(例如,Avro会这样做).