我應該公開構圖對象嗎？

Question

這裏是使用這種設計

我需要發佈一些API，以便外部世界可以配置用戶及其服務。配置用戶主要包括基於輸入參數（如id，密碼，級別等）創建新用戶並創建新的連接對象。一旦用戶對象被創建，服務配置是必需的。這是一個兩步的過程 - 啓用服務，修改服務細節。修改服務細節由一組操作組成。這些操作僅針對該服務。對於其他服務，這些操作將有所不同。

這是我目前的執行

用戶類是由service_manager，連接，組班。 service_manager類管理一組服務（比如ServiceA，ServiceB ... ServiceN）。每項服務都有一個海水班。

用戶類有一個公共職能assignService。該函數需要一個參數，用於標識服務類。它返回相應服務類的一個對象。這是一個相同的僞代碼。

serviceObjectA = user.assignService ('A'); 

後來，這個服務對象可用於執行操作，具體該服務。

serviceObjectA.performActionA1(...); 
serviceObjectA.performActionA2(...); 
serviceObjectA.performActionA10(...); 

這裏是問題，我面臨着這樣實現：

一）功能的performAction需要用戶類的一些屬性（如ID，密碼，位置等）和連接對象。這些用戶屬性是準備請求所必需的。連接對象需要通過已創建的連接發送此請求。 目前，我在服務類構造函數中管理它，其中，我傳遞這些用戶屬性和連接對象作爲構造函數參數。由於各種服務類別需要不同的用戶屬性，因此它變得有點難以管理。

請爲此建議一些替代方案。

b）將服務對象暴露給外部世界真的是一種很好的做法嗎？

我還是OOP世界的新手，很抱歉，如果我理解錯誤的話。 如果你可以用僞示例來演示它，我將會非常棒。解決你的一些問題

Answer 1

一種方式是遵循builder pattern

所以你不會使用，包括越來越多的參數和施工的慣例，以滿足所有這些不同的選擇。您不需要構造函數中的所有必要選項，而是可以使用所有期望的選項設置「構建器」類，然後構建正確設置的類（返回實例）。

這與另一個沒有公共構造函數但靜態工廠方法的選項類似。如果你的構造函數越來越難辨別並且參數失控，這些將會很有幫助。擁有靜態工廠方法意味着您可以更方便地描述方法名稱，並避免模糊性和複雜性。有效的Java有幾個與此相關的主題，對於更好的設計模式的深入討論將是一個很好的解讀。

不知道更多關於您的設計和使用，很難說什麼應該暴露，什麼不應該。在我看來，最好讓你的班級的用戶只與「用戶」進行交互，隱藏這些操作由各種服務執行的事實。這可以使複雜性降低一些，並且可以在稍後根據需要更改實現。