問題描述

標(biāo)題可能說得不是很清楚，還是上代碼：

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

然后可以看到，實際上會調(diào)用

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

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

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

問題解答

這是一個設(shè)計的和品位的問題，而不是一個技術(shù)問題。

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

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

這段邏輯是會被經(jīng)常調(diào)用到的，為了避免重復(fù)（DRY原則），我們把它抽象出來

這個例子是符合上面這兩條的：flask 需要一個創(chuàng)建 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 算是比較內(nèi)部的一個類，大多數(shù)情況下用戶不會（也不應(yīng)該）直接使用它。而為了讓用戶可以創(chuàng)建這個類的對象，作者封裝了 Flask.request_context() 方法，算是最小接口原則（盡量提供最小的接口給用戶）。

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

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

這就是面向?qū)ο蟮某蓡T變量是否對外可見的問題了，這里操作的是類的成員變量的成員變量，不適合直接獲取。可以參考一下property，你覺得property的優(yōu)勢在哪里？明顯的就是當(dāng)你所需要的屬性不是直接獲得而是通過計算獲得的話只需要修改屬性的獲取方法就可以了。