服務訪問控制（設計決策）

比方說，我們有一個接口'IA'，我們有一個實現'A'。在我們的應用領域，沒有容器對象'X'，對象'A'永遠不會存在。所以'A'永遠不會直接操作。 'A'聚合在'X'中。服務訪問控制（設計決策）

我們不想將'A'暴露給外部世界。爲此我們採取了這種方法，不要讓公共接口'IA'直接在'X'中使用實現'A'。不知何故，我覺得這不是正確的方法。可能是我錯過了一些基本的面向對象的概念。

請認真考慮。

PS：在給出的理由不提供「IA」爲：人們可能會拿出自己的隨機執行A和與系統玩。

好的。讓我把這個實際問題放在這裏。我正在開發一個Web應用程序。我們有幾個層次 - Dao，Doamin，Service，Web。服務層通過DAO在域對象上提供各種服務。我們有域對象 - Wire和WireRequest。 WireRequest可以有任何數量的導線。與這些域對象相對應，我們有兩個服務 - WireService和WireRequestService。使用spring在WireRequestService中注入WireService。

當我們暴露我們的service.jar中來的客戶，他們可能可以獨立使用WireService和不WireRequest對象來創建線對象。我們想要阻止這一點。基本上我們想要控制對一些服務的訪問。（我們可以通過授權春季方面做到這一點，但希望使用一些OO方式）

-Nayn

來源

2009-12-09 Nayn

是否有一個特定的語言，這將在內部實現？ – Kenaniah 2009-12-09 05:55:35

它是用Java實現的 – Nayn 2009-12-09 06:13:57

做最簡單的事情，可以工作。

除非我失去了一些東西沒有什麼本質上的「非OO」有關隱藏聚合對象或確實你的類中的任何其他屬性的實現細節。

正如Kenaniah所說，標記A類internal（或任何與您的語言相同的東西），並且它不會從外部世界看到。那麼你的班級的集合屬性可以是protected（或其他），並且它不會在該班級以外顯示。

某些語言，例如.NET，還提供了「內部類」：

public class X 
{ 
    internal class A 
    { 
    } 

    protected IEnumerable<A> ACollection { get; set; } 
}

這裏，A是不是X的外部可見的。

來源

2009-12-09 06:05:29

你的建議的基本概念是健全的。不幸的是，你的例子只限制訪問集合，而不是類型，這使得它可以通過* new X.A（）; *這與OP的目標相反。他想阻止實例化。如果你將A聲明爲內部類A {...}，並將訪問器聲明爲* internal *，那麼你可以在類庫的層次上隔離OP所需要的類。 – 2009-12-09 14:03:57

@JasonD - 的確如此。我已經更新了回覆。 – 2009-12-10 09:15:27

@JeremyMcGee：我從你的答案中得到了春天的想法。 – Nayn 2009-12-10 09:44:37

爲什麼不把的保護的所有方法和屬性？

來源

2009-12-09 05:54:59 Kenaniah

讓我看看我是否理解正確;改寫問題，你有容器X，它擁有從IA派生的A的實例 - 但是爲了X只有A的實例，你限制它只容納A的類型而不是IA。我是否正確？

對我來說，這其實很好。您正在定義可在編譯期間加強的約束。將接口IA僅用於其他目的仍然有效 - 您可能需要具有由IA定義的行爲的另一個對象列表;將接口IA的對象引用傳遞給多態等仍然很有用。

唯一的缺陷是系統已關閉 - 列表只能使用類型A.如果下一次您需要同時列出A和B並且不是C，該怎麼辦？（假設全部來自IA）。在這種情況下添加適當的數據/狀態驗證，而不是限制爲一種類型會更好。

來源

2009-12-09 06:08:31 Extrakun

根據A的X的複雜性，以及相對複雜（或簡單），這聽起來像你所描述，這可能是一個Facade Pattern或包裝/ Adapter Pattern

要麼是完全可行的給定一套場景，並且通常用於在域/子域邊界保持清晰。

編輯：鑑於OP的最近除了...，它的聲音聽起來有點像「如何使用Spring和代碼注入，當我控制訪問WireService和電線......」

我不熟悉春它如何注入事物。
但是，如果它服從任何合理的圖書館創建規則，它應該只需要那些你希望消費者必須公開的東西......所以你應該能夠保留WireServiceRequester作爲唯一的公共對象。給所有其他人提供他們實現的公共接口，並從任何具體的實現類之前刪除public。

如果春天沒有理智，因爲我假設，那麼你使用內置到春天的訪問控制機制可能是最安全的...

來源

2009-12-09 06:21:55

我更新了問題。請看看它是否合理。 – Nayn 2009-12-09 07:34:51

這仍然不是問題。這是澄清你的具體情況。嘗試制定幾個問題來跟蹤上下文。如： *我在做什麼合適？是否有覆蓋這些場景的設計模式？有沒有另一種方法來解決這個問題？....等等*我們可以推斷哪些信息可能對你最重要，但是，我們只是猜測。詢問具體問題可以讓社區更容易地提供相關和有意義的反饋。這最終會幫助你。 – 2009-12-09 13:14:50

嗯。我非常欣賞這一點。我認爲你正確理解我的問題。我得到了一個非常簡單的解決方案來解決這個問題。 Spring通過實際創建對象來處理依賴注入。我可以將'wireService'bean定義爲'wireRequestService'bean的內部bean。由於內部bean不能在容器bean之外使用，因此不能獨立創建。它和內部類的概念是一樣的。我想這符合我的目的。非常感謝你們。 – Nayn 2009-12-10 08:44:35

公衆service.jar中只能包含接口的類和實施應該通過在這種情況下，某種IOC

的獲得，使用彈簧來實施結合動態

因此service.jar中應包含

WireRequestServiceInterface僅

來源

2009-12-09 15:47:05 Dapeng

服務訪問控制（設計決策）

回答

相關問題