方法重构:从许多kwargs到一个arg-object

Question

有时,方法的kwargs数量会增加到我认为应该重构的水平.

例:

def foo(important=False, debug=False, dry_run=False, ...):
    ....
    sub_foo(important=imporant, debug=debug, dry_run=dry_run, ...)

我目前的首选解决方案

class Args(object):
    ...

def foo(args):
    sub_foo(args)

第一个问题:如何打电话Args？有一个众所周知的描述或设计模式？

第二个问题:Python是否有我可以用作基类的东西Args？

更新

我从13年开始每天使用Python工作.我使用了许多kwargs的方法,并用许多kwargs编写了方法.在过去的几周里,读了一本书"干净的代码",我喜欢它.不知怎的,就像现在戴着另一副眼镜一样.我的旧代码有效,但看起来并不好.将长方法拆分成几种较小的方法很容易.但我不知道如何处理kwargs-bloat的方法.

Answer 1

我认为你所描述的是“上下文”设计模式的一个例子。

我通常将你的“Args”称为“Context”（或者“FooContext”，如果它足够特定于 foo）。

我认为我看到的最好的解释是在这里：http://accu.org/index.php/journals/246（“封装上下文模式”，由 Allen Kelly 在 Overload Journal #63 - Oct 2004 中看到，我从另一个所以答案： https: //stackoverflow.com/a/9458244/3427357）。

如果您想深入探索，还有一些不错的论文可以进一步阐述： http: //www.two-sdg.demon.co.uk/curbralan/papers/europlop/ContextEncapsulation.pdf https://www.dre。 vanderbilt.edu/~schmidt/PDF/Context-Object-Pattern.pdf

正如另一个SO答案（/sf/answers/79481811/）所指出的，某些人认为上下文模式是危险的（参见http://misko.hevery.com/2008/07/18/打破德墨忒尔法则就像大海捞针/）。

但我认为“德米特法则”的警告是关于不要让你的早期设计过于复杂化，而不是清理你在解决其他问题时意外增长的残骸。如果您通过多个函数调用层传递“重要”布尔值，那么您已经在测试地狱了，在这种情况下，根据我的经验，您所描述的重构通常是纯粹的胜利。

我不认为 python 中有一个标准的基类，除非你懒得传递 argparse.Namespace 作为你的上下文对象，只是因为你已经在那里有了你的参数值。