基於角色的面向對象設計 - 控制器

Question

我想實現一個實際包含3的系統，每個系統的功能因用戶角色類型而異。即一個允許用戶根據角色類型執行不同任務的系統;角色類型在創建用戶時確定。用戶不能使用他們的角色訪問系統的其他組件/功能，並且用戶界面對於每個用戶都是唯一的。*

我需要這些「系統」彼此獨立行動，但我發現一些常見行爲（通常是組成機會）。

目前，我有3個控制器，因爲這是我設計的原始意圖 - RoleType1Controller，RoleType2Controller，RoleType3Controller。顯然，這些分支獨立出來，觸摸他們需要觸摸的類。

我正準備在功能上做出一些相當大的增強功能，只要我將腳放在地上，並且需要考慮這些增強功能，因爲其中一些功能將成爲系統的共同驅動點。即我希望系統能做幾件事情，但同樣重要，但目前只能實現一項主要功能。

關於OOD，我認爲這個「三個系統合一」的方法可能最適合即將到來的變化。然而，這些組合的機會以及與擁有單一控制器的標準保持一致的願望正在嚴重影響我的決策過程。

有沒有人有這樣的經驗，或者，如果不是，經驗在OOD，並可以指向我在正確的方向嗎？我從頭開始構建，所以（顯然）在第一次迭代中定義了系統的框架。我希望它儘可能健壯和靈活。

任何幫助將不勝感激。

*我不使用用戶界面來驅動我的設計過程......我只是認爲這些額外的信息可能會有所幫助。

Answer 1

在這種情況下，答案是有多個控制器。不一定是角色（儘管這是我目前形成的領域模型）;這些應該通過委派用例控制者責任的過程來定義。我通過設計的初始階段發現了這一點 - 定義固態硬盤和類圖。

在UML和模式應用：介紹面向對象分析與設計迭代開發（一個令人難以置信的入門書拉從多方面的，經過驗證的最佳實踐定義它的上下文和它們的作者），Craig Larman與狀態有兩種的方式接近定義你的控制器：

分配責任代表以下選擇之一的類：

•代表整個「系統」，「根對象」，該軟件是一個設備內部運行，或主要 子系統 - 這些都是門面控制器的變體。

•表示發生系統事件的用例場景，通常稱爲Handler， 協調器或會話（用例或會話控制器）。

•對同一用例場景中的所有系統事件使用相同的控制器類。

•非正式地，會話是與演員對話的實例。會話可以是任意長度，但通常按用例（用例會話）組織。

以往的經驗一直使我第一個解決方案，因爲我幫助設計的系統是複雜的低得多的水平。但是，我碰到這個問題：臃腫的控制器。

從相同的文字，Larman與建議如下：

問題和解決方案

設計糟糕的，一個控制器類將具有低粘結性的聚焦和處理的責任太多的領域;這被稱爲臃腫的控制器。腹脹的跡象是：

•系統中只有一個控制器類接收所有系統事件，並且其中有許多控制器類。 如果選擇了外觀控制器，有時會發生這種情況。

•控制器本身執行完成系統事件所需的許多任務，而不委託 工作。這通常涉及違反信息專家和高凝聚力。

•控制器具有許多屬性，並且它維護關於系統或域的重要信息，該信息應該已分發給其他對象，或者它複製其他地方找到的信息。 其中治癒臃腫的控制器有兩個：

1. 添加多個控制器，系統並不一定只有一個需要。使用用例控制器，而不是門面控制器。例如，考慮一個包含許多系統事件的應用程序，例如航空公司預訂系統。它可能包含以下控制器：

使用情況控制器

MakeReservationHandler

使用情況控制器

ManageSchedulesHandler

ManageFaresHandler

設計控制器，以便它主要代表每個系統操作責任 到其他對象的實現。

2）本身是不會幫我，因爲我有演員講相同的類，但以自己的方式......我已經委託儘可能多的責任，我可以到其他類，同時試圖爲用戶保持簡單而一致的交互。如前所述，這導致了我「臃腫的控制器」問題。

因爲OOA/D是一個不斷髮展的過程，我不能說這是我的最終解決方案，直到它真正實現。真的，這些用例控制器可能會導致我失去一條不同的路徑...而不是像每個（類似）用例那樣的控制器，我可能會以3（或4或5或6）結束，這可能只是到達那裏的一種手段。但就目前來看，事情比以前要順利得多 - 我開始看到最終解決方案的實現。