问题标签 [proxy-object]

我们正在使用一个外部 python 库（例如 Lib1），它有几个类（例如 A 类、B 类）。我们希望在该库之上创建一个包装器组件，以便将来如果我们想用其他库替换该库，我们的应用程序不需要更改代码。对于此组件的初始实现，我们可以使用与 Lib 1 中相同的类和方法创建此组件。

如果A类有方法m1和m2，B类有方法m3和m4，m3和m4以A类实例为参数；我们不想最终得到带有方法 m1 和 m2 的 Class Wrapped_A 和带有方法 m3 和 m4 的 Class Wrapped_B。

有没有办法实现一个通用的代理/委托对象或类，这样我们就不必在 Wrapped_A 和 Wrapped_B 中包装每个方法，但我们的应用程序仍然可以在它们上调用 def m1、m2、m3 和 m4（同样，仍然是一个对象A 类被传递给 m3 和 m4)。

我是 python 新手，试图了解装饰器和元编程，但这并没有帮助。此外，我们目前的要求不是在类或其方法中添加任何新逻辑，而只是创建代理对象/方法，它将仅将调用委托给外部库对象/方法。

谢谢您的帮助 ！

我将一个对象包装在一个代理中，然后遍历它。如何控制它迭代的键？

如果我不覆盖密钥，代理将起作用：

但是，如果我更改ownKeys处理程序中的键，则不会记录任何内容。

如果我返回"hello"作为ownKeys唯一"hello"记录的一部分。

显然enumerateES6 中有一个陷阱，但它已从 ES7 中删除。

是否仍然可以for...in使用代理控制循环？为什么enumerate从规范中删除？

我编写了这个 C++17 代码，并希望它能开箱即用。

我试图通过设置我的迭代器的成员 typedefsvalue_type和referenceto来匹配所有标准 OutputIterators 的行为void（因为这些类型对于operator*不返回引用的迭代器来说毫无意义）。

然而，Boost 抱怨：

看起来 Boost 正在尝试将生成operator*的签名硬编码为reference operator*() const. 也就是说，boost::iterator_facade 可以operator*()通过简单地传递 ; 返回的任何内容来推断出正确的返回类型dereference()。但由于某种原因，它只是不配合。

解决方案是什么？我不能proxy作为基类的模板参数传递，因为proxy尚未定义。我可以拉出proxy一个详细的命名空间：

但这似乎很尴尬，绝对是“不必要的”。

这是一个错误iterator_facade吗？它是功能而不是错误吗？如果是后者，那么我应该如何使用它来创建 OutputIterators？

另外，一个小问题：即使我使用 detail 命名空间的解决方法也是“错误的”，因为std::is_same_v<putc_iterator::reference, detail::proxy>当我想要的（与标准迭代器相同）是std::is_same_v<putc_iterator::reference, void>.

我想知道一个属于集合类的对象在被迭代时是否可以知道它正在被迭代并知道它所属的集合类？例如

我已经做了一些谷歌搜索但找不到任何东西，我猜这是不可能的，因为它在某处破坏了 OOP 主体，但我想我还是会问！

有没有办法确定正在读取的代理对象的属性是最终属性还是中间属性。

现在，如果我正在读取一个属性proxyObject.a.b.c.d，get 处理程序将被调用 4 次，每个属性一次。
有没有办法让我弄清楚何时为该d属性触发 get 以及何时为某些中间属性触发 geta或b

我正在处理来自一系列文件的数据。为了达到这个目的，我构建了一个类来分发数据。我启动了 4 个进程，它们将访问同一个类并检索数据。问题是，如果我使用类方法 (retrieve()) 来检索数据，内存会不断增加。如果我不这样做，内存是稳定的，即使数据通过 getData() 不断刷新。如何在检索数据时保持稳定的内存使用？或任何其他方式来实现相同的目标？

我正在尝试创建一个对象代理。属性/属性查找可以通过简单地实现__getattribute__,__setattr__和__delattr__方法来完成。但是，其他功能（例如，len(x), x[], bool(x)需要实现其他类似的 dunder 方法__len__, __getitem__, __bool__）。如果您没有在代理类上实现这些，但您代理的对象支持它们，您的代理将不完整并导致运行时错误。

因此，我想要一份我需要实施的所有事情的综合清单，但我在网上找不到任何可靠的清单。

这是我从typingandbuiltins模块中获得的 97 个独特的 dunder 方法名称。我知道他们中的很多人在做什么，但有些我不知道。为我的代理类实现全部或大部分它们会很痛苦，所以如果有解决方法我会很高兴。

在我们的项目中，我们有一部分代码根据传递的对象的类来执行操作。像这样的东西：

现在，A 和 B 是 Hibernate 实体。有时会发生方法 manageA 收到一个代理对象，但它无法按照它的实现方式做事。所以我们添加了一个Hibernate.unproxy来获取未代理的对象。

但是我担心这可能会产生一些副作用，即可以与代理对象一起使用的东西不再起作用。我注意到，通过调试，当取消代理对象时，我失去了“处理程序”属性（来自 Hibernate），但我不知道它做了什么，或者 Hibernate 是否仍然以其他方式处理它的东西。

我知道我可以做到这一点

保持代理对象不变。但我认为取消代理 Hibernate 对象是否有一些副作用，这对于未来来说是值得了解的。

值得一提的是，我并不害怕方法外部发生的事情，而是方法本身内部可能发生的事情（假设它从 Spring Data JPA 存储库调用 save 或 refresh 并且可以与代理对象一起使用的东西不适用于未代理的对象）

为什么要撤销代理？能提供一个实际应用Proxy.revocable()吗？

根据MDN Proxy.revocable() 文档，我了解它允许垃圾收集。但是，如果您刚刚删除 Proxy 对象，它是否也允许垃圾收集？

附录：如果这个问题有什么问题，请让我知道它是什么，我很乐意改写它或添加更多信息。

@艾米：

我认为这似乎是一个不必要的内置功能，因为我可以像这样创建一个可撤销的代理：

但是，垃圾收集似乎确实是问题所在，因为我可以撤消对象的访问权限，但不能删除 Proxy 对象内部对它的内部引用。除非...

因此，通过创建一个两层代理，您可以创建一个可回收和可撤销的垃圾代理。那么，为什么要内置呢？使用方便？还是我错过了什么？虽然它并不完全是垃圾回收的，但仍然有一个瘦包装器，它引用了一个具有空原型的对象。