使用情況作爲當前項目中OOP

對象，我們區域試圖實現用例爲對象，例如：使用情況作爲當前項目中OOP

public class SaveSalesOrderUseCase { 
    public void Execute(SalesOrderUseCaseModel salesOrderModel) { 
     // implementation as list steps defined in use-case 
    } 
}

這有什麼感覺來設計系統，這種方式？它如何能夠（正面和負面地）影響關於OOP，SOLID原則和領域模型等方面的系統設計？

有沒有經驗？

謝謝。

來源

2014-02-12 Zdenek Sejcek

使用案例並非旨在反映系統的結構它們旨在反映它的行爲。

這樣設計系統是否有意義？

不是，需求經常改變。這可能導致課程不再反映它的意圖。

它如何（積極和消極地）影響系統的設計關於OOP，固體原理和領域模型等？

從OOP的角度來看，這並沒有什麼意義。

用例標題旨在描述良性解決的整個問題。這將導致類名稱不反映單一責任。

這可能導致各種設計缺陷（特別是在讀取時）。

來源

2014-02-12 12:20:11

如果您將系統行爲視爲一等公民，封裝行爲的類將承擔一項責任。這就是DCI做得很好。 – ciscoheat

此方法可能會引入重複代碼，並且一個用例可能跨越不同的領域，您可能會發現難以維護代碼。即將到來的OOP，我覺得這是一個偏差，用例不是真正的對象。這種方法可能基於SOLID原則，但我認爲它並不是因爲您的用例可以跨越您的域之間的情況saveOrder可能觸及客戶域和庫存以及一些財務，並且每個都有其自己的SOLID類你應該有Facade類saveOrder來使用它們。

來源

2014-02-12 10:01:11 Kumar

如果您想「實現」用例的執行，例如處理隊列或批處理，您可能會這樣做。但是，與用戶採取的手動操作密切相關的用例，我看不出太多用處。

另一個原因可能是，如果你想定義關於用例在一般操作：撤銷/重做，記錄執行等則

您的使用情況很可能不得不雖然繼承一個公共基類。

否則，我會說KISS/YAGNI適用，它是矯枉過正。

來源

2014-02-12 11:28:59 guillaume31

我認爲這樣做完全可以接受。有一個名爲DCI (Data, context and interaction的架構模式，其中一個用例在上下文中實現，並且域對象在該上下文中扮演一定角色以履行場景。

其中一個原因是系統的行爲不應該分散在您的應用程序中。這可能會讓人很難理解正在發生的事情。

DCI並不比其他體系結構更好或更差，它只是一個可供您選擇的選項。

來源

2014-02-13 11:54:04 Jeroen

DCI肯定比傳統的面向對象「更好」，因爲它的目標是緩解在這種範式中發現的問題。 – ciscoheat

使用情況作爲當前項目中OOP

回答

相關問題