問題描述

標題可能說得不是很清楚，還是上代碼：

Flask.wsgi_app(self, environ, start_response): ctx = self.request_context(environ)

然后可以看到，實際上會調用

def request_context(self, environ):return _RequestContext(self, environ)

之后再進入到class _RequestContext(object): 的__init__函數中，后面就不再寫了。

我的疑惑是，在第一句生成ctx的時候，為何要弄出一個request_context 方法來呢？這個方法就只有簡單的一個返回語句，那么我直接在開始的時候實例化不就好了：ctx = _RequestContext(self, environ) ？ 而且像這樣的使用方式在flask中其他地方也還有很多，那么這樣使用有什么明顯的好處嗎？ (或者說像我那樣寫的直接返回的句子有什么明顯的壞處嗎？)

問題解答

這是一個設計的和品位的問題，而不是一個技術問題。

就拿你舉的這個例子來說，我們看到這里有一層封裝，但是因為封裝的內容太過于簡單，所以讓你疑惑是否有這個必要。要回答這個問題，我們要想想為什么會有封裝？不管是函數也好，類也好，我們定義它們可能是因為以下原因：

它們提供了邏輯上的某個功能，便于我們理解

這段邏輯是會被經常調用到的，為了避免重復（DRY原則），我們把它抽象出來

這個例子是符合上面這兩條的：flask 需要一個創建 application context 的功能，并且是在多處會用到它。

? flask grep '.request_context' -rin ../app.py:1918: with app.request_context(environ):./app.py:1925: ctx = app.request_context(environ)./app.py:1948: return self.request_context(builder.get_environ())./app.py:1977:ctx = self.request_context(environ)

另外一個好處是，RequestContext 算是比較內部的一個類，大多數情況下用戶不會（也不應該）直接使用它。而為了讓用戶可以創建這個類的對象，作者封裝了 Flask.request_context() 方法，算是最小接口原則（盡量提供最小的接口給用戶）。

封裝還有一個好處，只要接口固定，內部實現是可以隨便更改的。你的版本里初始化是 ctx = _RequestContext(self, environ)，在我安裝的版本里（Flask==0.12）這行代碼是 ctx = RequestContext(self, environ)。雖然這里只是一個類名的簡單變化，但是通過它我們可以明白，如果我們對 RequestContext 的實現或者初始化發生了變化，所有的調用方是不用改動的；不然的話，所有的調用方都要跟著修改。

當然這里封裝的內容只有一句，這些好處不是那么明顯，甚至顯得我有點牽強附會。但是我猜測，這是作者思考過的結果，因為 RequestContext 是 Flask 中比較重要的類，以后對它進行修改的可能性很大（增加一些屬性、改變初始化的參數等），把它封裝一層，可以輕松應對未來可能的變化。畢竟，軟件工程一個重要的事情就是應對變化。

這就是面向對象的成員變量是否對外可見的問題了，這里操作的是類的成員變量的成員變量，不適合直接獲取。可以參考一下property，你覺得property的優勢在哪里？明顯的就是當你所需要的屬性不是直接獲得而是通過計算獲得的話只需要修改屬性的獲取方法就可以了。