確保施工前或施工時對象的有效性

我正在爲具有顏色的汽車建模。我想確保顏色是有效的。所以我在Car類中創建了一個嵌套枚舉，它將保存有效的顏色。我想了解這個想法：確保施工前或施工時對象的有效性

應該怎樣創造一輛汽車？
- 暴露枚舉。並在構造函數期望一個枚舉值。這確保了有效的顏色。
- 枚舉是我的！我班的用戶不需要知道它！我會讓他給我一個字符串，我將解析任何枚舉值。如果它不是有效的，我會拋出一個異常

我與暴露更傾向於。我有什麼理由不喜歡這樣做嗎？例如，可能使用戶創建汽車實例時過度複雜？（儘管我猜他會比運行時異常更喜歡這個）。

你說什麼？

2014-04-14 Tomer Yoskovich

你認爲實現枚舉作爲一個獨立的類的什麼？它目前只是該車的一個特色，但它也可能被其他類使用。而一種顏色本身並不是如此的汽車...... –

考慮工廠模式。您可以隱藏所有支票和顏色處理代碼，您的Car可以保持原樣（使用Color作爲枚舉參數）。工廠不具備構造的限制，你可以自由，你想給的名稱爲您的方法，例如：

public class CarFactory{ 
    public static Car createRedCar() { return new Car(Color.RED); } 
    public static Car createBlueCar(){ return new Car(Color.BLUE); } 
}

來源

2014-04-14 07:13:14 Kojotak

我看不出我問的問題和是否使用工廠的決定的關係。但我會用這個來推出另一個問題：我不會按照你所建議的方式進行方法的爆炸嗎？對於汽車的每種顏色，我都需要一種方法，然後爲汽車的任何其他屬性（例如車輪數量）給我：createRedCarWith4Wheels（），createRedCarWith6Wheels（）。我預見你會告訴我使用建造者模式。但我仍然不明白建築工程師會如何接收我的參數。也許你可以與我分享，如果你這樣做？ –

工廠對象只是一個幫手。您仍然可以使用您的構造函數創建新車（使用顏色或車輪數量等參數）。關鍵是，汽車的創造與汽車本身分離到一個地方。如果你有更多的參數（車輪數量，引擎類型......）比抽象工廠更合適。工廠參數如何綁定到汽車的構造方式完全取決於您。 – Kojotak

工廠解決方案這是不錯的，優雅的，但迫使你添加新的方法每你需要添加一種新顏色。如果你想添加諸如「車輪數量」之類的東西，那麼你遇到了麻煩，因爲你會使工廠方法的數量增加一倍。我會堅持暴露解決方案。它非常容易理解，給你一些靈活性（增加一種新顏色，就像在你的enum類中添加一行一樣簡單），它是Java的風格。你知道，Java非常詳細！但這只是一個意見。

來源

2014-04-14 07:20:02 JavierV

感謝您的輸入JavierV。如果要求規定您需要具有可以不同的汽車和摩托車的有效顏色，您將如何處理案件？創建2個枚舉（每個都在它的相應類中）或一般枚舉？ –

好問題...兩個枚舉將是快速和詳細的，但你可以選擇實現一個普通的枚舉和一個顏色「過濾器」ColorValidator（枚舉顏色）。通過這種方式，您可以使用所有顏色獲得泛型枚舉，併爲不同的「驗證器」中的每個類指定限制。驗證器將作爲您的汽車/摩托車課程的靜態部分實施，並讓您決定哪些顏色可以用於摩托車，哪些用於汽車 – JavierV

我認爲在這種情況下暴露enum不是問題。關於有效值，使用字符串的方法並不是非常安全。使用枚舉明確定義哪些值是有效的。這就是畢竟的枚舉;-)

你還應該考慮進一步使用汽車類。如果您需要在另一個環境中獲取汽車的顏色，則還需要返回枚舉而不是字符串，這意味着您必須將其公開。

如果覺得工廠模式不適合你的情況，但很難在不知道整個來龍去脈你的車類中使用的話。

來源

2014-04-14 08:22:43

我完全同意，這是我在來到這裏之前的偏見。但Uwe Allner得到了一個觀點，他說：你需要汽車的顏色？但你也有摩托車，其有效的顏色是其他。您（Andre）和我同意的解決方案將創建2個顏色枚舉。他建議在兩種情況下都使用更一般的* 1 *枚舉。我不知道什麼更好。有人知道在這種情況下什麼更好？ –

確保施工前或施工時對象的有效性

回答

相關問題