尝试扩展 Java 对象时如何避免向下转型

发布于 2024-10-27 04:39:52 字数 503 浏览 7 评论 0原文

我通过调用外部 API 获得了多个 Foo 类型的对象。在本地,我想用一些附加信息来处理这些对象,因此我有一个子类 FooSon 来添加这些额外的字段。如何将我获得的所有对象转换为新的继承类型?向下转型似乎不是一个选项,因为这些对象并不是真正的 FooSon

我想出的唯一解决方案是创建一个转换函数,该函数将 Foo 对象作为参数,然后将所有公共/受保护的值复制到一个新的 FooSon 对象,该对象是然后回来了。

缺点是:

  • 丢失信息(私有值)
  • 如果 Foo 发生更改,则必须调整转换函数。

Foo 类没有实现复制构造函数或克隆运算符。我有 Foo 源代码,但我想避免更改它以保持与未来版本的兼容性。尽管如此,如果它是唯一可行的选择,我会更改 Foo 实现以获得我需要的东西。

I get several objects of type Foo from a call to an external API. Locally I want to process those objects with a little added information so I have a subclass FooSon that adds those extra fields. How can I convert all those objects I get, to my new inherited type? Downcasting doesn't seem to be an option because those objects aren't really FooSon.

The only solution I have come up with is creating a convert function that takes the Foo object as an argument and then copies all public/protected values to a new FooSon object that is then returned.

The disadvantages are:

  • Loosing information (private values)
  • Having to adapt the convert function if Foo is ever changed.

Class Foo doesn't implement a copy constructor or clone operator. I have the Foo source code but I would like to avoid changing it in order to keep compatibility with future releases. Nevertheless if it is the only viable alternative I would change the Foo implementation to get what I need.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

小苏打饼 2024-11-03 04:39:52

FooSon 中可以有一个 Foo 字段。然后将返回的值分配到该字段中。然后,您可以在 Fooson 中创建方法,将其调用委托给 Foo 字段,以从外部获取 Foo 所需的信息。

FooSon could have a field in it that is a Foo. then just assign the returned value into that field. You could then create methods in Fooson that delegate their calls to the Foo field for the information that you need from the Foo from outside.

掩饰不了的爱 2024-11-03 04:39:52

我认为装饰器模式应该在这里工作:

class Foo implements FooApi {...}

class FooSon implements FooApi {
    private FooApi decoratedFoo;
    private String additional;

    public FooSon(FooApi decoratedFoo) {
        this.decoratedFoo = decoratedFoo;
    }
    ...
}

但只有当您有 Foo 对象的接口时,您才能执行此操作。

I think decorator pattern should works here:

class Foo implements FooApi {...}

class FooSon implements FooApi {
    private FooApi decoratedFoo;
    private String additional;

    public FooSon(FooApi decoratedFoo) {
        this.decoratedFoo = decoratedFoo;
    }
    ...
}

but you can do this only if you have interface for your Foo object.

不寐倦长更 2024-11-03 04:39:52

也许我还没有完全理解这个问题,但是为什么你不将 Foo 像字段类型一样存储在 FooSon (组合)中,而不是子类化 Foo (继承)?

无论如何,如果由于对象被定义到外部库中而无法修改对 Foo 类型的访问控制,则无法直接访问私有字段(这正是私有字段的属性)。如果可以通过 getter 和 setters 方法访问这些私有字段,请将这些方法包装在 FooSon 类中。

Maybe I haven't fully understood the problem, but why instead of subclassing Foo (inheritance) aren't you storing Foo like a field type in FooSon (composition)?

In anycase, if you can't modify access control to Foo type because the objects are defined into an external library, you can't get direct access to private fields(this is exactly the property of a private field). If those private fields can be accessed from getters and setters method, so wrap that methods in your FooSon class.

心凉 2024-11-03 04:39:52

好吧,正如您已经发现的那样,向下铸造不适用于这种情况。我看到以下选项:

  • 外部库提供了一些工厂机制,您可以使用它实例化 FooSon 而不是 Foo

  • 接收者将 Foo 对象包装在 FooSon 对象中,可能使用委托者模式。

  • 接收者通过使用以 Foo 作为键的映射,在逻辑上将附加信息附加到 Foo 对象。

Well, as you already found out down casting is not applicable in this situation. I see the following options:

  • The external library provides some factory mechanism you could use to make it instantiate FooSon instead Foo.

  • The recipient wraps Foo objects in FooSon objects, possibly using the delegator pattern.

  • The recipient logically attaches additional information by to Foo objects by using a map with Foo as key.

献世佛 2024-11-03 04:39:52

你不应该沮丧,你不能保证它会成功,并且有更好的方法来处理这个问题。
对于其中一个,您可以将 Foo 对象包装在另一个类中,并将适当的方法调用委托回 Foo 对象。

我建议您花一些时间来确保您了解一些基本的面向对象概念。
特别是,谷歌搜索“组合与继承”,这个链接似乎是一个不错的解释。

You should not downcast, you have no guarantee it will succeed and there are better ways of dealing with this problem.
For one you could wrapper the Foo object in another class and delegate the appropriate method calls back to the Foo object.

I suggest you take some time to make sure you understand some basic OO concepts.
In particular, google for "composition versus inheritance", this link seems like a decent explanation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文