为什么有些Django视图类没有定义为抽象基类?

brccelvz  于 2023-03-13  发布在  Go
关注(0)|答案(1)|浏览(105)

我正在为自己编写一个小型轻量级的类似Django的后端框架,只是为了做实验。
如果我们看一下ProcessFormView视图(以及其他一些视图):

class ProcessFormView(View):
    def get(self, request, *args, **kwargs):
        return self.render_to_response(self.get_context_data())

    def post(self, request, *args, **kwargs):
        form = self.get_form()
        if form.is_valid():
            return self.form_valid(form)
        else:
            return self.form_invalid(form)

    ...

对我来说,将这个类定义为“抽象基类”听起来像是一个有效的案例。
毕竟,它需要子类提供render_to_response()get_context_data()get_form()form_valid()form_invalid()(它们将由TemplateResponseMixinFormMixin提供)。
我可以这样做:

class ProcessFormView(View, metaclass=ABCMeta):
    @abstractmethod
    def render_to_response(self, context):
        pass

    @abstractmethod
    def get_context_data(self):
        pass

    @abstractmethod
    def get_form(self):
        pass

    @abstractmethod
    def form_valid(self, form):
        pass

    @abstractmethod
    def form_invalid(self, form):
        pass

    def get(self, request, *args, **kwargs):
        return self.render_to_response(self.get_context_data())

    def post(self, request, *args, **kwargs):
        form = self.get_form()
        if form.is_valid():
            return self.form_valid(form)
        else:
            return self.form_invalid(form)

    ...

或者更好的是,我们可以将这些抽象方法分解到另一个ABC类中,并从它继承,以使事情变得清晰。
我知道这当然是一个决定,没有什么错。我最感兴趣的是,如果做我刚才展示的,它会如何在未来造成问题?有什么缺点,我不知道?
我能想到的唯一缺点是我应该写很多抽象类!这会使代码库变得更大。

rhfm7lfc

rhfm7lfc1#

除了前面提到的代码库会变得大得多这一事实外,我想我找到了主要原因。
的确,如果我们子类化ProcessFormView并且“* 打算使用它的getpost方法 *",我们最终必须以某种方式提供那些提到的方法。但是如果出于某种原因,我们只想使用它的post方法,并为get提供我们自己的定制方法呢?(它们只在postget内部被调用)。
这样我们就不必实现render_to_responseget_context_data()抽象方法,将它们定义为abstractmethod会不必要地强制子类实现它们。

相关问题