我总是使用铸造的情况很少，并且想知道我是否真的可以避免使用它们？
1。考虑来自sf的接口 - org.springframework.validation.Validator
当我们实现此接口时，我们将获得以下方法：
public void validate(Object event, Errors arg1) {
Event e = (Event) event;
}
受到这个thread的启发而且从来没有像我建议的那样，我真的很担心自己在做演员表。而且我几乎没有什么案例能够真正导致铸造异常，而且从来没有理解为什么它不能被铸造以及我们应该怎么做。另外，我们总能准确评论其他开发人员需要注意的对象类型。
假设第三方库接口的实现总是会产生Object参数，那么该线程中的大概是什么？显然，图书馆创建者必须使用像Object这样的通用来解释我们不同的背景。
或许我可以在这种情况下以其他方式做到这一点？
2. 我从不同的上下文中检索某些内容，例如数据库
Hibernate例如返回我的列表数据结构，这可能是我现在想要的？我被禁止从List转换为ArrayList只是因为它不漂亮？
3。 session.setAttribute(); session.getAttribute() - 然后对象传递给服务方法？ - 没有铸造怎么样？
通过完成这个问题，我认真地认为“不要这样做，因为它是坏的”要么是错误的态度，要么从一开始就不应该存在API中的组件/功能。
答案 0 :(得分：1)
强制转换的主要问题是您没有获得编译时类型的安全性。在可能的情况下，我们使用接口（例如，List，而不是您提到的ArrayList）或继承。我们也有通用类型，例如。 List<String>而不是Object对象列表。
有时在api中提供特定类型而不使api过于重量级是不切实际的，我们最终得到了Object引用然后转换它们因为我们知道它们被使用的上下文。
关于List vs ArrayList示例...这里使用List很好。 api提供程序只是说它们将返回一个实现List接口的对象，因此您可以作为列表访问它。您的程序不想知道您的api提供程序的内部实现，并且他们不希望给您的客户任何特殊考虑。通过使apis尽可能通用（特定于客户端，但实现通用），它们往往尽可能健壮。
所以“不要这样做 - 这很糟糕”真的意味着将它作为最后的手段。如果可能，接口或类似接口可能是更好的选择。