Question

以下内容使我感到惊讶，尽管也许不应该如此。但是，我从未见过其他地方这样做

def bar_method(self):
    print( f"in Foo method bar, baz={self.baz}")
    # and pages more code in the real world


class Foo(object):
   def __init__(self):
       self.baz = "Quux"
   bar = bar_method

>>> foo = Foo()
>>> foo.bar()
in Foo method bar, baz=Quux
>>>

这是根据def的定义得出的，该定义是在当前上下文中函数对象对其名称的赋值。

就我而言，最大的优点是，我可以将大型方法定义移到类主体之外，甚至移到另一个文件中，而只需一次分配即可将它们链接到类中。实例化该类将它们照常绑定。

我的问题很简单，为什么我以前从未见过这样的事情？这里有潜伏的东西可能会咬我吗？或者，如果它被认为是不好的风格，为什么？

（如果您想知道我的上下文，那是关于Django View和Form子类的。我非常希望保持它们的简短，以便易于理解它们背后的业务逻辑。我宁愿只使用方法具有美容意义的位置移至其他位置。

Answer 1

就我而言，最大的优点是，我可以将大型方法定义移到类主体之外，甚至移到另一个文件中

我个人不会认为这是“很大的优势”。

我的问题很简单，为什么我以前从未见过这样的事情？

因为很少有这样做的充分理由，而有很多不这样做的充分理由。

或者如果它被认为是不好的风格，为什么？

因为，这使得了解正在发生的事情变得非常简单。调试非常困难，而且您必须导航的每个文件也增加了“心理负担”。

我非常希望能使它们简短，以便易于理解它们背后的业务逻辑。我宁愿只将具有装饰意义的方法转移到其他地方

然后将重要部分放在类声明的开头，并将修饰部分放在结尾。

另外，问自己是否在正确的地方做事-就我而言，“业务逻辑”主要属于领域层（模型），而“化妆品”则建议表示层（视图） /模板）。当然，某些对象（特别是表单和视图）实际上在处理业务规则和表示，但是即使那样，您仍可以经常将这个领域的某些部分移至模型（视图或表单将在其上调用）和某些表示部分到模板层（使用过滤器/自定义标签）。

我的2美分...

NB：很抱歉，如果上面的内容听起来有点让人受宠-我不知道您的代码是什么样子，所以我无法判断您是否显然已经意识到这一点，并且已经在做正确的事情，只是试图进一步改进，否则您还是一个新手，仍然在努力实现适当的代码分离...

在其类块之外定义对象方法，有没有理由？

1 个答案: