标题可能说得不是很清楚,还是上代码:
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 원칙) 추상화됩니다.
이 예는 위의 두 항목과 일치합니다. 플라스크는 애플리케이션 컨텍스트를 생성하는 기능이 필요하며 여러 곳에서 사용됩니다.
으아악또 다른 이점은
RequestContext
이 상대적으로 내부 클래스라는 점입니다. 대부분의 경우 사용자는 이를 직접 사용하지 않습니다. 사용자가 이 클래스의 객체를 생성할 수 있도록 저자는 최소 인터페이스 원칙(사용자에게 가장 작은 인터페이스를 제공하도록 노력)으로 간주되는Flask.request_context()
메서드를 캡슐화했습니다.캡슐화의 또 다른 장점은 인터페이스가 고정되어 있는 한 내부 구현을 마음대로 변경할 수 있다는 것입니다. 귀하의 버전에서 초기화는
ctx = _RequestContext(self, environ)
입니다. 제가 설치한 버전(Flask==0.12)에서 이 코드 줄은ctx = RequestContext(self, environ)
입니다. 이것은 단지 클래스 이름의 단순한 변경일 뿐이지만,RequestContext
의 구현이나 초기화가 변경되면 모든 호출자가 변경될 필요가 없으며, 그렇지 않으면 모든 호출자가 Revise를 따라야 한다는 것을 이를 통해 이해할 수 있습니다.물론 여기에 요약된 내용은 단 한 문장에 불과합니다. 이러한 이점은 그다지 명확하지 않으며 제 입장에서는 다소 무리한 것처럼 보입니다. 하지만 이는 작성자의 생각에서 나온 결과인 것 같습니다.
RequestContext
는 Flask에서 상대적으로 중요한 클래스이고, 향후 수정(일부 속성 추가, 초기화 매개변수 변경 등)될 가능성이 매우 높기 때문입니다. 향후 발생할 수 있는 변화에 쉽게 대처할 수 있는 계층입니다. 결국 소프트웨어 엔지니어링에서 중요한 것은 변화에 대응하는 것입니다.객체지향 멤버변수가 외부에 보이는가에 대한 질문입니다. 여기서 동작하는 것은 클래스의 멤버변수 중 직접접근에 적합하지 않은 멤버변수입니다.
부동산을 꼽으라면 부동산의 장점은 무엇이라고 생각하시나요?
물론 필요한 속성을 직접 획득하는 것이 아니라 계산을 통해 획득하는 경우에는 속성 획득 방식만 수정하면 됩니다.