為什麼那麼多框架都設計有context？

03-30

為什麼需要context？把所有環境上的東西都掛載到context，是不是類似於全局變數的作用？不擔心各個插件會對context上的「環境變數/全局變數」造成重名？

這在設計模式裡面有時被稱作「足球模式」

即，整個調用鏈把一個足球從最上層的調用者踢到最下層的被調用者，然後再一層層踢回來

雖然名字很搞笑，但是複雜度到一定程度的系統都需要或多或少的「足球模式」，因為把足球打散成幾十個變數更愚蠢。即使是函數式編程也毫不例外（當然他們的做法是每次複製一個新球，繼續踢，這樣就immutable了，多棒！）

我覺得就是起個全局變數的作用，比如窗口的handle，配置文件的那個不斷和文件sync的instance。主要是方便從一個Context改成另一個，以及多實例共存的時候方便管理，以及總有那麼些東西你要到處傳來傳去(比如涉及UI的，就得有個窗口的handle好往裡面加控制項之類的)。

IntelliJ有Project，Android有Context(大多數時候是Activity嘛)，而Eclipse就用的全局變數。而且API返回的都是那種繼承鏈頂端的幾乎啥也沒有的介面。。

context 是局部的全局變數。

全局變數是全局的 context。

我理解 context 就是「你就是會用到的所有數據的集合」。

就好像語文中的「上下文」就是「為了理解某段話，你需要知道的所有知識的集合」。

我覺得這個問題問大了，應該有好幾層含義，不同領域的人會給你不同的回答。

具體來說：

比如圖形學領域，面向過程的函數介面，contex相當於 this 或者 self或者是句柄，用來指向當前繪圖環境用到的實例，不同的context還會形成堆棧關係。

比如非同步調用，需要攜帶一些標示信息或者參數，在回調後用來區分或者使用，這個額外的參數是context。這個應用可以拓展到fp。

對於多線程，協程之類的，需要在切換時保存現場以及相關的參數，相關參數就是context。

對於面向對象的應用程序，儘管application實例只有一個，但是在實際編碼中，如果不去定義context，就很容易發現一些工具類或者服務管理器為了寫代碼方便會被錯誤實現為單例模式。而實際上，考慮到代碼可測性，一個重要的概念就是，依賴是可以被替換的，而單例模式就是難以替換，因此將依賴封裝到context里去，就是一種實現技巧，比如 Android 就是。

我覺得原題問的應該是最後這個吧。

@ShaoDan 貼了一個鏈接，發現知乎相關問題回答質量明顯下降

1. 你的程序只是「流水線」中的一環，所以有了「context」

2. 為了讓你的程序在這個「流水線」上能運行起來，並發揮作用

3. 如何定義「環境」，確切的說，是「流水線」上，你這一環需要，或可能需要的東西。

4. 你的擔心是正確的。現在問題來了，如何避免這樣的問題，是你的問題還是流水線的問題？

因為框架一般都需要支持線程/協程/進程/中斷等存在切換執行過程的操作，這就需要在切換前用context來記錄當前程序執行的相關狀態，待重新切換回來時，需要用之前保存的context來從中斷處繼續執行。還有一點，context並非一定是環境變數或全局變數，將其當作與執行流程綁定的局部數據可能會更合適一點。

可以參考這個問題下面的答案

編程中什麼是「Context(上下文)」？?

www.zhihu.com

上帝的概念似乎在哪裡都是存在的，即便是在代碼中。

有多種語義的上下文。其中最經典的是oo中一個場景_如何解決一個人在不同場合下不同身份。比如在家裡對父親是父親，在公司對父親做同事。這需要對像能感知環境。因此引入上下文來解決對象對環境的感知。另外還有一種上下文比如請求上下文，會話上下文，應用上下文(其實是對環境的細分)。

問題，springcontext和beanfactory的區別是？

因為編程的上下文是一種哲學。

畢竟起名叫做mixed_bag看起來很low啊

我認為,現實中的語言,是用於人和人溝通,計算機語言,是為了人和計算機溝通.因此,可以類比.

基本語法已經可以進行溝通,但如果加上一些修辭手法,可以讓語言變得更有藝術性,也能表達更多的內涵.同樣context,就是這麼一種東西,和人類語言類似,一種"修辭手法".

結論就是為了裝個B,其實對計算機而言沒卵用.

一些人認為這樣可以讓計算機語言顯得更有格調,才有"context".本質上是方便人類"裝逼"用的一種語法,當然,偶爾會顯得更加簡潔,優雅.