java - 这些特殊情况类型转换是可以避免的吗？

Question

我经常使用强制转换，想知道我是否真的可以避免它们？

1.考虑 sf 的接口(interface) - org.springframework.validation.Validator

当我们实现这个接口(interface)时，我们将得到以下方法:

public void validate(Object event, Errors arg1) {

        Event e = (Event) event;

    }

受到此启发thread在此之前，每当 IDE 建议我进行强制转换时，我都不会真正关心自己是否进行强制转换。我遇到的情况很少，这实际上导致了强制转换异常，并且理解为什么它不能强制转换以及我们应该采取什么措施从来都不是火箭科学。另外，我们始终可以准确地注释其他开发人员会注意到的对象类型。

假设，如果第三方库接口(interface)的实现总是会导致对象参数，那么该线程中有什么大惊小怪的呢？显然，库创建者必须使用像对象这样的通用东西来解释我们不同的上下文。

或者在这种情况下我可以采取其他方式吗？

2.我从不同的上下文(例如数据库)检索一些内容

例如，Hibernate 返回给我列表数据结构，这可能是我现在想要的？我被禁止从 List 转换为 ArrayList 仅仅因为它不美观？

3.session.setAttribute() ; session.getAttribute() - 然后将对象传递给服务方法？ - 没有选角怎么办？

通过完成这个问题，我认真地思考“不要这样做，因为它不好”要么是错误的态度，要么组件/功能从一开始就不应该存在于 API 中。

Answer 1

强制转换的主要问题是无法获得编译时类型安全性。在可能的情况下，我们使用接口(interface)(例如，List 而不是您提到的 ArrayList)或继承。我们也有通用类型，例如。 List<String>而不是 Object 对象的列表。

有时，在 api 中提供特定类型而不使 api 过于重量级是不切实际的，我们最终会拥有对象引用，然后对它们进行强制转换，因为我们知道使用它们的上下文。

关于 List 与 ArrayList 的示例...在这里使用 List 很好。 api 提供者只是说他们将返回一个实现 List 接口(interface)的对象，因此您可以将其作为列表访问。你的程序不想知道你的 api 提供者的内部实现，他们也不想给你的客户任何特殊的考虑。通过使 API 尽可能通用(特定于客户端，但实现通用)，它们往往会尽可能强大。

所以“不要这样做——这很糟糕”实际上意味着将其作为最后的手段。如果可能的话，界面或类似的可能是更好的选择。