当前位置：文江博客话题详情

装饰器与继承

发布于 2024-11-16 05:34:03 字数 180 浏览 4 评论 0原文

当装饰器和继承都可行时，您如何决定使用两者？

例如，这个问题有两种解决方案。

我对Python特别感兴趣。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

怪我太投入 2024-11-23 05:34:03

装饰器...：

...如果您想要做的是“包装”，则应该使用。包装包括获取某些内容、修改（或将其注册到某些内容）和/或返回一个行为“几乎完全”与原始对象相同的代理对象。
...只要您不创建大量代理对象，就可以应用类似 mixin 的行为。
...有一个隐含的“堆栈”抽象：

例如

@decoA
@decoB
@decoC
def myFunc(...): ...
    ...

相当于：

def myFunc(...): ...
    ...
myFunc = decoA(decoB(decoC(myFunc)))  #note the *ordering*

多重继承...：

...最适合向类添加方法；你不能轻易地用它来装饰函数。在这种情况下，如果您只需要一组“鸭子类型”额外方法，它可以用于实现类似 mixin 的行为。
...如果您的问题与超类构造函数等问题不太匹配，则可能有点难以处理。例如，子类 __init__ 方法将不会被调用，除非显式调用它（通过方法-解析-顺序协议）！

总而言之，如果装饰器不返回代理对象，我会使用装饰器来实现类似 mixin 的行为。一些示例将包括返回原始函数的任何装饰器，稍作修改（或者在将其注册到某个地方或将其添加到某个集合之后）。

您经常会找到装饰器的东西（例如记忆）也是不错的候选者，但如果它们返回代理对象，则应适度使用；它们的应用顺序很重要。太多的装饰器以一种不应该使用的方式相互使用它们。

如果这是一个“经典继承问题”，或者如果我混合行为所需的只是方法，我会考虑使用继承。一个经典的继承问题是，只要可以使用父级，就可以使用子级。

一般来说，我尝试编写不需要增强任意事物的代码。

Decorators...:

...should be used if what you are trying to do is "wrapping". Wrapping consists of taking something, modifying (or registering it with something), and/or returning a proxy object that behaves "almost exactly" like the original.
...are okay for applying mixin-like behavior, as long as you aren't creating a large stack of proxy objects.
...have an implied "stack" abstraction:

e.g.

@decoA
@decoB
@decoC
def myFunc(...): ...
    ...

Is equivalent to:

def myFunc(...): ...
    ...
myFunc = decoA(decoB(decoC(myFunc)))  #note the *ordering*

Multiple inheritance...:

... is best for adding methods to classes; you cannot use it to decorate functions easily. In this context, it can be used to achieve mixin-like behavior if all you need is a set of "duck-typing style" extra methods.
... may be a bit unwieldy if your problem is not a good match for it, with issues with superclass constructors, etc. For example, the subclasses __init__ method will not be called unless it is called explicitly (via the method-resolution-order protocol)!

To sum up, I would use decorators for mixin-like behavior if they didn't return proxy objects. Some examples would include any decorator which returns the original function, slightly modified (or after registering it somewhere or adding it to some collection).

Things you will often find decorators for (like memoization) are also good candidates, but should be used in moderation if they return proxy objects; the order they are applied matter. And too many decorators on top of one another is using them in a way they aren't intended to be used.

I would consider using inheritance if it was a "classic inheritance problem", or if all I needed for the mixin behavior were methods. A classic inheritance problem is one where you can use the child wherever you could use the parent.

In general, I try to write code where it is not necessary to enhance arbitrary things.

回复收藏 0 原文

ゝ偶尔ゞ 2024-11-23 05:34:03

其他答案都很好，但我想给出一个简洁的优缺点列表。

mixins 的主要优点是可以使用 isinstance 在运行时检查类型，并且可以使用 MyPy 等 linter 进行检查。与所有继承一样，当您具有is-a关系时应该使用它。例如，dataclass 可能应该是一个 mixin，以便公开特定于数据类的自省变量，例如数据类字段列表。

当您没有is-a关系时，应该首选装饰器。例如，从另一个类传播文档或在某个集合中注册类的装饰器。

装饰通常只影响它所装饰的类，而不影响从基类继承的类：

@decorator
class A:
    ...  # Can be affected by the decorator.

class B(A):
    ...  # Not affected by the decorator in most cases.

现在Python有了__init_subclass__，装饰器可以做的所有事情都可以通过mixin完成，而且它们通常会影响子类：

class A(Mixin):
    ... # Is affected by Mixin.__init_subclass__.

class B(A):
    ... # Is affected by Mixin.__init_subclass__.

Mixin还有另一个优点，那就是它们可以提供空的基类方法。子类可以用一些“增强”行为重写这些方法，然后调用 super.装饰器不能轻易提供这样的基类方法。这是 mixin 更加灵活的另一种方式。

总之，在决定 mixin 和装饰时应该问的问题是：

是否存在 is-a 模式？
- 您会调用 isinstance 吗？
- 您会在类型注释中使用 mixin 吗？
您希望这种行为影响孩子们的班级吗？
您需要增强方法吗？

一般来说，倾向于继承。

The other answers are quite great, but I wanted to give a succinct list of pros and cons.

The main advantage of mixins is that the type can be checked at runtime using isinstance and it can be checked with linters like MyPy. Like all inheritance, it should be used when you have an is-a relationship. For example dataclass should probably have been a mixin in order to expose dataclass-specific introspection variables like the list of dataclass fields.

Decorators should be preferred when you don't have an is-a relationship. For example, a decorator that propagates documentation from another class, or registers a class in some collection.

Decoration typically only affects the class it decorates, but not classes that inherit from the base class:

@decorator
class A:
    ...  # Can be affected by the decorator.

class B(A):
    ...  # Not affected by the decorator in most cases.

Now that Python has __init_subclass__, everything that decorators can do can be done with mixins, and they typically do affect child subclasses:

class A(Mixin):
    ... # Is affected by Mixin.__init_subclass__.

class B(A):
    ... # Is affected by Mixin.__init_subclass__.

Mixins have another advantage, which is that they can provide empty base class methods. Child classes can override these methods with some "augmenting" behavior, and then call super. The decorator cannot easily provide such base class methods. This is another way in which mixins are more flexible.

In summary, the questions you should ask when deciding between a mixin and decoration are:

Is there an is-a pattern?
- Would you ever call isinstance?
- Would you use the mixin in a type annotation?
Do you want the behavior to affect child classes?
Do you need augmenting methods?

In general, lean towards inheritance.

回复收藏 0 原文