業務邏輯類的正確接口

在具有獨立UI和業務邏輯的程序中;我有一個車庫，包含一個車輛列表（licenseplate，coniditionOfVehicle）業務邏輯類的正確接口

我想讓車庫的用戶可以收到一個特定給定conditionOfVehicle的所有licensePlate列表。

應該是什麼方法的返回類型？（確切地說是什麼要求陳述）與車輛IList（允許客戶看到汽車的更多屬性，從而提高可擴展性）
我們甚至允許返回車輛？這將允許用戶改變我們可能不希望他的東西。（假設客戶端訪問「車輛」，因爲它是用生成器來接收車輛，然後調用Garage.AddVehicle（車輛），將其添加到車庫）

感謝

2014-04-12 Tomer Yoskovich

始終貫徹的事情，當你真正需要它們，從來沒有當你只是預見到你需要他們。

如果需求說'用戶需要licensePlates列表'，那麼只需返回用戶需要的內容，而無需預測他們可能需要什麼。否則，你在浪費時間進行預測，你正在增加可能的問題（用戶改變車輛），你讓代碼對於用戶（他們期望licensePlates）和維護者（他們不知道新的需求來自哪裏），最糟糕的是 - 新的'功能'可能不會被用戶使用。

另一個原則正嘗試通過返回整車例如侵犯是KISS (Keep It Simple, Stupid)：

如果你有一個簡單的解決方案和一個複雜之間進行選擇，然後選擇了複雜性將是愚蠢的。

返回字符串列表更簡單，滿足要求。沒有必要爲您的系統增加不必要的複雜性。

來源

2014-04-12 08:19:47

感謝您的評論。我同意這一點，但是想知道如果你以這種方式實施後你會做什麼，客戶來找你說他還需要知道相關車輛的顏色（因爲他想做一個汽車狀況圖與他們的顏色）。你現在可以製作一個簡單的新型（LicensePlate，Color）嗎？還是你會返回Vehicle？ –

@ Jackl56取決於。通常我會盡量避免向系統添加新的數據類型。但是，如果您通過網絡（DTO）或其特定的視圖模型傳輸數據，那麼通常創建新的數據類型將是更好的解決方案。因此，您應該在增加新類型和增加用戶不需要的額外數據之間增加系統複雜性。 –

也許我錯了，但我認爲這不是一個偏好問題。假設我沒有通過網絡傳輸數據，我正在尋找更好的方式來做到這一點，或者至少有一些指導方針來決定兩者之間的關係。因爲我無法爲每一種想要的方法創建一個新類返回一組不同的值 –

業務邏輯類的正確接口

回答

相關問題