問題描述

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

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

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

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

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

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

問題解答

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

就拿你舉的這個(gè)例子來說，我們看到這里有一層封裝，但是因?yàn)榉庋b的內(nèi)容太過于簡(jiǎn)單，所以讓你疑惑是否有這個(gè)必要。要回答這個(gè)問題，我們要想想為什么會(huì)有封裝？不管是函數(shù)也好，類也好，我們定義它們可能是因?yàn)橐韵略颍?/p>

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

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

這個(gè)例子是符合上面這兩條的：flask 需要一個(gè)創(chuàng)建 application context 的功能，并且是在多處會(huì)用到它。

? 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)

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

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

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

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