这些特殊情况是不是可以避免？

Posted 2023-02-22

【中文标题】这些特殊情况是不是可以避免？

【英文标题】：Are these particular situations casting avoidable?这些特殊情况是否可以避免？

【发布时间】：2013-09-26 01:28:14

【问题描述】：

我总是使用强制转换的情况很少，想知道我是否真的可以避免它们？

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

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

public void validate(Object event, Errors arg1) 

        Event e = (Event) event;

    

受到thread 的启发，在此之前，我从未真正关心过自己是否会在 IDE 建议时进行强制转换。而且我几乎没有几个案例实际上导致了强制转换异常，并且永远不能理解为什么它不能被强制转换以及我们应该如何处理它。此外，我们始终可以准确地注释其他开发人员会注意到的对象类型。

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

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

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

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

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

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

【问题讨论】：

“从一开始的组件/功能甚至不应该存在于 API 中”在某些情况下可能是正确的，但不幸的是我们确实犯了错误，在 API 上下文中，你不能像这样更改它那是因为它会破坏使用它们的程序。所以这就是为什么我们有deprecated 装饰......

【参考方案1】：

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

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

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

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