python - 在其类 block 之外定义对象方法，有什么理由不这样做？

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 的定义，它是在当前上下文中将函数对象分配给它的名称。

就我而言，最大的优点是我可以将大型方法定义移到类主体之外，甚至移到不同的文件中，并且只需通过单个赋值将它们链接到类中。实例化类会像往常一样绑定(bind)它们。

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

(如果你想知道我的上下文，它是关于 Django View 和 Form 子类的。我非常希望保持它们简短，以便它们背后的业务逻辑很容易理解。我宁愿只使用装饰意义已转移到其他地方)。

Answer 1

The great advantage, as far as I am concerned, is that I can move large method definitions outside the class body and even into a different file

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

My question is simply, why have I never seen this done before?

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

Or if it's regarded as bad style, why?

因为这让我们更难理解正在发生的事情，很简单。调试已经够困难的了，而且你必须浏览的每个文件也增加了“精神负担”。

I would dearly love to keep them short, so that the business logic behind them is easy to follow. I'd far rather that methods of only cosmetic significance were moved elsewhere

然后将重要部分放在类声明的开头，而装饰部分放在末尾。

另外，问问自己是否在正确的地方做事 - 就我而言，“业务逻辑”主要属于领域层(模型)，而“装饰”则建议表示层( View )/模板)。当然，某些对象(特别是表单和 View )实际上同时处理业务规则和表示，但即使如此，您通常也可以将某些域部分移动到模型( View 或表单将调用模型)和某些表示部分到模板层(使用过滤器/自定义标签)。

我的2美分...

注意:抱歉，如果上面的内容听起来有点居高临下 - 我不知道你的代码是什么样的，所以我无法判断你是否显然已经意识到这一点并且已经在做正确的事情并且只是试图进一步提高，或者您是一个初学者，仍在努力解决如何实现正确的代码分离...