這些特殊情況是否可以避免？

當我總是使用鑄造，並且想知道我是否可以避免它們時，我有幾個案例？這些特殊情況是否可以避免？

從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

這些特殊情況是否可以避免？

回答

相關問題