Question

令人好奇的是，这个例子中的装饰器函数几乎可以编写为一个类而不是一个函数，使用正确的运算符重载协议。如下的略微简化的替代版本类似地工作，因为当@装饰器应用于类的时候，触发__init__，并且当创建了一个主体类实例的时候触发其__call__。这次，我们的对象实际是Tracer的实例，并且这里，我们实际上只是为避免使用对一个实例属性的封闭作用域引用：

正如我们在前面见到的，这个仅针对类的替代方法像前面一样处理多个类，但是，它对于一个给定的类的多个实例并不是很有效：每个实例构建调用会触发__call__，这会覆盖前面的实例。直接效果是Tracer只保存了一个实例，即最后创建的一个实例。自行体验一下看看这是如何发生的，但是，这里给出该问题的一个示例：

这段代码输出如下——由于这个跟踪器只有一个共享的实例，所以第二个实例覆盖了第一个实例：

这里的问题是一个糟糕的状态保持——我们为每个类创建了一个装饰器实例，但是不是针对每个类实例，这样一来，只有最后一个实例保持住了。其解决方案就像我们在前面针对装饰方法的类错误一样，在于放弃基于类的装饰器。

前面的基于函数的Tracer版本确实可用于多个实例，因为每个实例构建调用都会创建一个新的Wrapper实例，而不是覆盖一个单个的共享的Tracer实例的状态。由于同样的原因，最初的非装饰器版本正确地处理多个实例。装饰器不仅仅具有无可争辩的魔力，而且微妙的程度令人难以置信。