0

当我总是使用强制转换并且想知道我是否真的可以避免它们时，我很少遇到这种情况？

1.考虑来自 sf 的接口 - org.springframework.validation.Validator

当我们实现这个接口时，我们将得到以下方法：

public void validate(Object event, Errors arg1) {

        Event e = (Event) event;

    }

受到这个线程的启发，而且在此之前，每当 IDE 建议我时，我真的很担心自己会做演员表。而且我几乎没有几个案例实际上导致了强制转换异常，并且永远不能理解为什么它不能被强制转换以及我们应该怎么做。另外，我们总是可以准确地注释其他开发人员会注意到的对象类型。

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

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

2.我从不同的上下文中检索一些东西，比如数据库

例如 Hibernate 会返回我现在可能想要的 List 数据结构？我被禁止从 List 转换为 ArrayList 只是因为它不漂亮？

3.session.setAttribute() ; session.getAttribute()- 然后对象传递给服务方法？- 没有铸造如何？

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

4

1 回答 1

1

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

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

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

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

于 2013-09-26T02:18:04.147 回答