Java 对象最具体的子类?
我有两个类 A 和 B,其中 B 是 A 的子类,而 A 不是抽象的。 因此,我可以拥有作为 A 实例的对象和作为 B 实例的对象(因此也是 A 的实例)。
如何区分仅是 A 实例的对象?
当然,我可以写类似“object instaceof A && !(B的对象实例)”之类的内容,但这是一个非常糟糕的设计,因为每次向 A 添加新子类时我都需要更改代码。更好的替代方案?
I have two classes A and B, where B is subclass of A and A is not abstract. Therefore I can have objects that are instance of A and objects that are instance of B (and therefore of A).
How can I distinguish objects that are only instance of A?
Sure, I can write something like "object instaceof A && !(object instance of B)" but this is a very poor design since I'll need to change the code every time I add new subclasses to A. Better alternatives?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
为什么要让他们区分? 通常这与面向对象相反。 您有不需要区分的不同实例,因为不同的实现可以正确执行所有操作。
如果您需要这样做,那么应该有一个协议。 为此目的有一个方法可以返回一些可识别的内容。 这也更灵活。
如果没有充分的理由使用它,我会认为 instanceOf 和 getClass 已经考虑了不好的风格
Why you want them to distinguish? Usually this is the opposite of OO. You have different instances that you don't need to distinguish because the different implementation does everything right.
If you need to do so than there should be a protocol for it. Have a method for that purpose that returns something to recognize. That is more flexible,too.
I would instanceOf and getClass already consider bad style if this is used without good reason
更好的方法是使测试成为方法的结果
然后,如果添加扩展 A 的 C,则可以允许它返回 true 或 false。
isSomeTest 的名称应该清楚地表明返回 true 或 false 的含义。
A better approach is to make the test the result of a method
Then if you add a C which extends A you can allow it to return true or false.
The name of isSomeTest should make it clear what returning true or false should mean.
这就是我认为您要说的:
稍后在代码中:
以下是您可能会发现有用的一些选项:
关于最后一个选项,您编写以下内容:
多态性在这里几乎总能帮助我们。 您关于每次添加子类时更改代码的观点正是您应该将其视为标准面向对象设计演变的症状。 想想你试图产生的行为。 您能否将其推入类本身,而不是将其委托给外部提供者,后者必须推断出当前正在处理的类?
如果没有更多信息,我无法提供太多指导,但这里有一个相当简单的示例:
修改设计,使其变得更像这样:
在稍后的执行代码中,您将之前的 if 测试替换为:
不可否认,这几乎是微不足道的面向对象的设计审查,但它可能会松动一些东西并帮助您解决子类化问题。
This is what I think you're saying:
later in code:
Here are some options that you may find useful:
Regarding the last option, you write the following:
Polymorphism almost always helps us here. Your point about changing code every time you add a subclass is exactly the kind of symptom that you should recognize as standard object-oriented design evolution. Think about the behavior that you are trying to produce. Can you push that into the class itself rather than delegating it to an outside provider looking in that has to deduce what class it's currently working on?
Without more information, I can't give too much guidance but here's a fairly straightforward example:
Modify the design to become more like this:
Where later in the execution code, you replace your previous if test with:
Admittedly, this is a nearly trivial object-oriented design review but it may shake something loose and help you with your subclassing problem.
这难道不表明B并不是真正的A吗?
我不完全确定你应该陷入这种情况吗? 也许你可以改进你的设计?
Doesn't this show that B isn't really an A?
I'm not entirely sure you should get into this situation? Perhaps you could improve your design??