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

当我总是使用铸造，并且想知道我是否可以避免它们时，我有几个案例？这些特殊情况是否可以避免？

从SF考虑界面 - org.springframework.validation.Validator

当我们实现了这个接口，我们会得到下面的方法：

public void validate(Object event, Errors arg1) { 

     Event e = (Event) event; 

    }

本thread和前所未有的灵感它让我非常担心自己会在IDE向我推荐时进行演员表演。而且我几乎没有什么时候会真的导致抛出异常，而且从来没有火箭科学去理解为什么它不能被铸造，我们应该怎么做。另外，我们总是可以准确评论其他开发人员需要注意的对象类型。

只是假设如果第三方库接口的实现总是会导致Object参数，那么该线程中的大惊小怪？很显然，图书馆创作者必须使用像Object这样的一般东西来说明我们不同的情境。

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

2.我检索来自不同背景的东西，如数据库

休眠比如我返回列表数据结构这也许现在我想要什么？我被禁止从List转换到ArrayList仅仅是因为它不漂亮？

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

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

来源

2013-09-26 Aubergine

”在开始时应该不存在组件/功能性应用程序甚至不应该存在于API中“在某些情况下可能是正确的，但不幸的是，我们确实犯了错误，并且在API上下文中，您不能像这样更改它，因为它会中断使用它们的程序。所以这就是为什么我们有'弃用'装饰... – justhalf

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

有时候在api中提供特定类型而不使api过重，并且最终得到对象引用，然后进行投射，因为我们知道它们被使用的上下文。

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

所以“不要这样做 - 这很糟糕”真的意味着把它作为最后的手段。如果可能，界面或类似可能是更好的选择。 “

来源

2013-09-26 02:18:04 Aaron

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

回答

相关问题