你能解釋Context設計模式嗎？

Question

我已經開始閱讀關於Context design pattern。下面是我從文字理解：

• 你有一個包含所有的變量

• 你把它傳給周圍誰需要它，這樣你就不必把所有的變量作爲地圖方法參數

我「得到」了嗎？

Answer 1

上下文對象提供對共享數據和函數的訪問。

它可以是一個優雅和靈活的替代品：

• 全局
• 單身
• 長參數列表

The ACCU provides a more detailed description.

如果你想有一個真實的例子Java中的上下文模式，請檢查Google Android API's。

使用上下文模式時，您需要注意您的dependency graph。 （這是KaptajnKold將其稱爲反模式的原因。）

要限制不必要的依賴關係，請針對不同的目的使用不同的上下文。保持上下文儘可能簡單，並在需要時使用組合或繼承來增加複雜性。

Answer 2

我「得到」了嗎？

對不起，說不完。

上下文對象的目標是而不是隱式地將大量參數傳遞給方法，作爲繞過強類型和封裝的手段。其目標是以範圍廣泛但可管理的方式存儲範圍內的數據，而不受協議和表示技術的影響。存儲在範圍內的數據本質上是共享的，仍然可以被構造，並且本質上不同於傳遞給方法的一次性參數。

上下文對象模式首次引入Core J2EE Patterns 2nd Ed。 「上下文」部分是指對象在範圍的上下文中保存數據這一事實，該事實包括
（諸如application/session/request/conversation/flash）的上下文。

它的目的是儘可能多地分離來自協議/演示技術特定類的應用程序數據和邏輯，例如HttpSession和HttpRequest。

模式實現

在上下文對象，用於應用/會話/請求/其他範圍的數據沒有直接放入ServletContext/HttpSession/HttpRequest /其它特定於協議的類。相反，數據存儲在POJO包裝類中，然後位於ServletRequest/HttpSession/HttpRequest/other中。

上下文對象可能將數據存儲在地圖中，但它不需要 - 它可以將數據存儲在與程序相關的任何結構/格式中。

應用程序可以使用每個作用域的一個Context對象類或幾個以有序的方式拆分數據的類，從而避免過多的類膨脹並促進問題的分離。

上下文對象由最前面的表示類（視圖，前端控制器，調度程序）使用。這些表示客戶端對象調用contextObject.get來檢索存儲的作用域數據，並使用contextObject.put來存儲作用域上下文數據。

它未被傳入業務/集成邏輯。它不被用作將大量參數傳遞到業務對象的方式，繞過強大的輸入。業務代表和集成層面由業務代表，應用服務& /或使用特定強類型參數的會話外觀所面向。

模式效益

• 可測性：單元測試只需要模擬一個簡單的POJO，而不是一個特定於協議的複雜的服務器類，如ServletContext或HttpRequest
• 靈活性&複用性：核心的應用程序獨立於特定於協議的「簡報」層類別。這意味着應用程序可以更容易地更改或添加協議或表示技術（例如HTML/HTTP/Servlet和WAP/Servlet和XML/SOAP/HTTP/EJB和HTML/HTTP/JSF）。

評論

• 是一個歷史模式
• 有人會認爲依賴注入框架，如CDI，吉斯，春，煤層，在協議中已經實現&別人給範圍存儲獨立的方式。即所有範圍已經被實現爲上下文對象，這意味着開發者不太需要創建額外的上下文對象。這並不否定該模式 - 這意味着CDI框架已經支持該模式。
• 如果正確實施，可以與落得「繞過極大的相上下文對象在整個應用程序」反模式

報價KaptajnKold： 我覺得你得到了它。然而，我也認爲這是更多的避免反模式。看看爲什麼here。

您的評論指的是錯誤實施的上下文對象版本。上下文對象本身不是反模式。

Answer 3

使用上下文進行初始化的類。考慮這個代碼

public class BuildTagHandler extends TagHandler { 

     public BuildTagHandler(ServiceContext context) { // constructor 
      this.tagDAO = context.getTagDAO(); 
      this.buildDAO = context.getBuildDAO(); 
     } 

你會用上下文來構造你的類。在上下文文件中，您將不會實現，而您擁有大量這些DAO對象。您可以將其解釋爲門面模式，或者一個巨大的接口涵蓋所有條目。