python - flask中为何有这么多的直接返回‘一句话’调用的方法呢？

Question

标题可能说得不是很清楚，还是上代码：

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中其他地方也还有很多，那么这样使用有什么明显的好处吗？ (或者说像我那样写的直接返回的句子有什么明显的坏处吗？)

Answer 1

これはデザインと好みの問題であり、技術的な問題ではありません。

あなたが挙げた例を見てみましょう。ここにはカプセル化の層があることがわかりますが、カプセル化されたコンテンツが単純すぎるため、それが必要かどうか疑問に感じます。この質問に答えるには、なぜカプセル化が必要なのかを考える必要があります。関数であってもクラスであっても、次の理由で定義できます:

• それらは私たちが理解できるように特定の論理関数を提供します

• このロジックは頻繁に呼び出されますので、重複を避けるため(DRY原則)、抽象化します

。

この例は上記の 2 つの項目と一致しています: flask にはアプリケーション コンテキストを作成する関数が必要であり、それは多くの場所で使用されます。

リーリー

もう 1 つの利点は、RequestContext が比較的内部クラスであることです。ほとんどの場合、ユーザーはそれを直接使用しません (また使用すべきではありません)。ユーザーがこのクラスのオブジェクトを作成できるようにするために、作成者は Flask.request_context() メソッドをカプセル化しました。これは、最小インターフェイス原則とみなされます (ユーザーに最小のインターフェイスを提供するように努めます)。 RequestContext 算是比较内部的一个类，大多数情况下用户不会（也不应该）直接使用它。而为了让用户可以创建这个类的对象，作者封装了 Flask.request_context() 方法，算是最小接口原则（尽量提供最小的接口给用户）。

封装还有一个好处，只要接口固定，内部实现是可以随便更改的。你的版本里初始化是 ctx = _RequestContext(self, environ)，在我安装的版本里（Flask==0.12）这行代码是 ctx = RequestContext(self, environ)。虽然这里只是一个类名的简单变化，但是通过它我们可以明白，如果我们对 RequestContext 的实现或者初始化发生了变化，所有的调用方是不用改动的；不然的话，所有的调用方都要跟着修改。

当然这里封装的内容只有一句，这些好处不是那么明显，甚至显得我有点牵强附会。但是我猜测，这是作者思考过的结果，因为 RequestContext カプセル化のもう 1 つの利点は、インターフェイスが固定されている限り、内部実装を自由に変更できることです。お使いのバージョンでは、初期化は ctx = _RequestContext(self, environ) です。私がインストールしたバージョン (Flask==0.12) では、このコード行は ctx = RequestContext(self, environ) です。 )。これはクラス名の単純な変更ですが、これにより、RequestContext の実装または初期化が変更された場合、すべての呼び出し元を変更する必要はなく、変更する必要があることがわかります。それに応じて。

もちろん、ここに要約されている内容はほんの 1 文にすぎません。これらの利点はそれほど明白ではなく、私にとっては少し突飛なようにさえ思えます。しかし、これは作者の考えの結果だと思います。RequestContext は Flask の比較的重要なクラスであり、将来変更される可能性が非常に高いためです (属性の追加、初期化パラメーターの変更など)。 .) 、将来起こり得る変更に簡単に対処できるように、レイヤーでカプセル化します。 🎜結局のところ、ソフトウェアエンジニアリングで重要なことは、変化に対応することです🎜。 🎜

Answer 2

これは、オブジェクト指向のメンバー変数が外部から見えるかどうかという問題です。ここで操作されるのは、直接アクセスに適さないクラスのメンバー変数です。
不動産について言及することができます。不動産の利点は何だと思いますか?
もちろん、必要な属性を直接取得するのではなく、計算によって取得する場合は、属性の取得方法を変更するだけで済みます。