Java設計：方法實現

這是我以前的問題here的擴展。如果我要爲Car POJO實施一種名爲getGasMileage的方法，那麼最適合保留該方法的地方在哪裏。我看到4種設計策略：Java設計：方法實現

把它放在一個實用工具類
使它成爲一個Function
使用策略模式，創建一個策略接口和實現將被稱爲CarStrategy，傳遞策略對象爲Car通過構造並具有Car類的內部的getMileage方法調用CarStrategy對象方法
與像double getMileage(Car car)

這些方法的折衷是什麼？

編輯1：方法getGasMileage包含一噸的業務邏輯，其計算Car對象的返回值給定領域，例如重量，發動機類型，FWD等

2017-05-12 Richard

最明顯的事情似乎是5：在'Car'上有一個方法getGasMileage' – Thilo

這個問題背後沒有足夠的信息來給出超出意見的答案。從本質上講，如果你的架構很簡單，那就把它作爲Car的一個方法吧。人們會不同意我的觀點，「但是當......發生什麼......」評論時，從這樣一個基本的體系結構來看，有很多路徑讓你爲我旅行，爲你提供有關每種可能選項的建議。 –

這個問題不是太寬泛。這只是基於意見而已。只要把這個方法放在'Car'裏，那是我的意見。有支持和反對我的觀點的論據。 –

是氣體里程的靜態屬性一輛車的？這可能是因爲汽車模型估計與他們有關的汽油里程。如果是這樣，那麼我同意你的意見，你應該把它作爲一個吸氣劑在Car與私人領域。如果getGasMileage然而與它比我的意見相關的業務邏輯的動態是：

只要你有一個「實用」我相信這是一個味道。通常，實用程序是開發人員在不知道應該在哪裏放置代碼的地方。
你可以走這條路線，因爲單個方法接口和函數定義非常相似。我更喜歡這個接口，因爲它給出了定義的名稱，並且可以用與它的使用位置無關的方式對它進行記錄。如果你使用功能範例，你可以選擇這個選項。
我認爲Car不應該知道任何關於燃料算法。我更喜歡一個愚蠢的POJO，因爲它將數據和業務邏輯分開。
這給你很大的靈活性。定義一個界面，你可以實現不同的算法來計算里程。界面的實現有一個計算里程的好工作。這個選項是我的首選。確保Car不直接依賴於您的界面。對計算里程感興趣的類應該將接口的實例作爲構造函數參數。

來源

2017-05-12 01:49:54 Samuel

這對我有意義。那麼，使用函數與接口 – Richard

@Samuel的比較，你能解釋點1嗎？我正在研究幾項服務，每項服務都有一個共同的實用程序類。我們編寫在其他類中重用的常用方法。你是否認爲這是錯誤的？你會建議作爲替代方案嗎？ –

@TeenaGeorge有兩件事：第一 - 我看到他們的實用工具類是定義了「public static」方法的類。 Static is bad http://blog.snacktrace.com/post/141079889301/static-is-a-smell Second--實用程序類，正如我所見，它們通常包含一組可能相互關聯或可能不相關的方法集合。在面向對象的範例中，對象應該有單一的責任。你能描述一下你的實用課程嗎？ – Samuel

Java設計：方法實現

回答

相關問題