<分区>
我以前也有过类似的案例，这里只是举例说明:
我要在我的 android 应用程序中实现一个新功能(但这适用于任何类型的 OO 项目)，此时我需要在每个编辑文本的“setVisibility”方法中实现一些“操作”我的每项 Activity 。
为此，我必须子类化“EditView”，并覆盖“setVisibity”方法:
@Override
public void setVisibility(int visibility)
{
super.setVisibility(visibility);
// --> do my stuff here! <--
}
到目前为止，一切顺利...问题是要更改我拥有的所有 Activity (超过 200 条代码行)，然后我想:“我到底为什么没有开始这个项目子类化标准 EditText，因为我知道我需要实现类似这样的东西”。
这就是重点:将一个“标准类”子类化为一个新的完全相同的东西但只是“假设”这样的情况的 OOP 不好吗？我的意思是，子类化一切，例如按钮、 Activity 等。
AFAIK、设计模式和 OOP 不鼓励“假设因素”，但我想听听你们根据你们的编程经验“在现实生活中做了什么”(或考虑一下)。
此外，也许这类问题(“你的想法”、“你的意见”)在 SO 中不是一个好的做法，但我找不到更好的地方来提出它。