问题标签 [decorator]

我一直在尝试创建一个可以与 python 中的函数和方法一起使用的装饰器。这本身并不难，但是当创建一个接受参数的装饰器时，它似乎是。

上面的代码正确地包装了函数/方法，但在方法的情况下，request参数是它正在操作的实例，而不是第一个非 self 参数。

有没有办法判断装饰器是否应用于函数而不是方法，并进行相应处理？

我正在寻找一种装饰任意python函数的方法，以便调用替代函数而不是原始函数，所有参数作为列表或字典传递。

更准确地说，是这样的（其中 f 是任何函数，replacement_f 接受一个列表和一个字典）：

但是，我不能replacement_f在里面引用new_f。而且我不能使用传递replacement_ftonew_f作为不同参数的默认值的标准技巧，因为我使用的是*args和**kwargs变量参数列表。

调用原始函数的位置不能更改，并且将接受位置参数和命名参数。

我担心这不是很清楚，但如果需要，我很乐意澄清。

谢谢

我正在尝试制作棋盘游戏Carcassonne的 C++ 实现。我正在尝试制作一个具有四个侧面和三个基本地形（田野、道路、城市）之一的瓷砖对象。

我能想到的创建磁贴的最佳界面是以下形式：

Tile 类的定义如下...

我希望构造函数初始化从基类 Side 继承的每个特定 Side（TopSide、RightSide、BottomSide、LeftSide）。想法是在 Terrain 类中定义一个虚拟 Decorate 方法，该方法将为特定类型的 Terrain 返回 SideDecorator 的实例。

根据侧面的地形类型，它将有不同数量/类型的地形分段。例如：带有字段的一侧只需要一个 FieldSegment，而带有道路的一侧需要三个段：一个 RoadSegment 和两个 FieldSegment。因此，向棋盘添加图块将需要具有不同实现和成员的 Sides。

我可以制作具体的类，如 TopFieldSide、BottomRoadSide 等，但我认为装饰器模式会更干净。然而，我不确定的是 Decorate() 方法的多态使用是否是一种误用。

当然，我可以创建以下形式的 Tiles：

但以前的版本似乎更干净。

我的问题是......这是一种可以接受的方法还是我错过了一种更简单/更清洁的方法？

我对这种方法的使用使我遇到了耦合问题，因为我必须在 Terrain 中包含 SideDecorator 的路径，并且 Terrain 用于 SideDecorator 和派生类中。terrain.h 中的简单指令 #include "side_decorator.h" 会导致许多编译错误，因此很难判断它是前向声明问题还是我的代码中没有注意到的其他问题......

我正在尝试编写一个获得单个 arg 的装饰器，即

所以，天真地，我尝试了：

这没关系，但它也可以用作不接收 args 的装饰器，即

我怎样才能防止这种情况？

我实际上正在努力处理一些代码。我确实知道它可以重构，但我找不到漂亮-智能-优雅的解决方案。

这是两个函数（我的代码中有更多此类函数）：

我的第一个想法是使用这个装饰器：

最后：

不幸的是，我对这个解决方案不满意：

• 这个装饰器是“侵入式的”并且特定于 fooA 和 fooB 函数
• fooA & fooB 主体中不再使用 param2，但我们必须将其保留在函数签名中

也许我没有将装饰器用于其最初目的？

有没有其他方法可以重构代码？

非常感谢！

我目前正在使用 Oracle 的 ADF Faces JSF 实现表示层的遗留系统。该系统依赖于规则引擎来根据用户与它们的交互或输入的值来使某些表单元素成为必需、禁用甚至突出显示。

在当前阶段，应用程序正在“工作”，有点。当前处理规则引擎和前端更新的实现不是很优雅，并且由大量的 if 语句组成，类似于：

为了使混合更复杂，我们还混合了我们自己的对象，因此整个集合不共享一个共同的祖先，从而消除了我们执行以下操作的选项：

问题是是否值得重新编写这部分代码以使其更清晰。由于大多数屏幕元素都是 ADF Faces 元素，我们不能/不允许更改它们的祖先以添加其他方法。

代码更改的目标有两个：清理旧代码并改进代码库，以便添加新元素或控件不会导致大的代码更改（特别是存在于许多地方的 if 语句） .

那么，如果我们继续进行这种改变，那将是实现我们正在寻找的更好的选择？子类化所有元素（每次我们使用另一个预先存在的控件时都需要一个新类）或实现装饰器模式？我对装饰器的唯一担心是它仍然需要为每个附加元素更改代码。这两个选项似乎都可以减少代码更改，因为包含这些 if 块的多个方法不需要更新。

除了子类化和装饰器之外，任何有关处理此类情况的方法的输入都是受欢迎的！

这是来自的示例：dofactory

我重新格式化了一下以更好地适应（压缩）：

现在与这个比较（来自 C# Design patterns 3.0 - O'reilly）：

几个问题，一个简单的问题： 1. 具体的装饰器（如第一个例子）是否必须调用基类？2. 在第二个例子中根本没有具体的组件，似乎只有一个组件和装饰器，仅此而已，对吗？还是装饰器模式吗？对我来说似乎是这样。只是想澄清一些事情。

谢谢

我正在移植一个 2D 平台游戏，我需要一种从关卡图块中获得一些可扩展性的好方法。我不确定 Decorator 在这里是否正确，但没有想到其他任何东西。也许我需要一些独特的东西。

无论如何，假设我有一个基本的 Tile，其中包含图像之类的东西，以及玩家是否可以穿过它（背景或前景）。现在我想给它们添加一些属性，比如让一些瓷砖充当梯子，或者在接触时伤害或杀死玩家。也许有些会消失。可以组合一些属性。

这听起来像装饰器，但我真的不喜欢我的基类如何实现所有东西的虚拟版本，比如isLadder()，isLethal()等等。有更好的方法吗？我不会改变我的设计，让它看起来像 GoF 书中的东西。

抱歉，如果这个问题以前被问过一百万次，我在相关问题中并没有完全找到它。

I'm currently trying to use Zend_Form, and it's decorators mechanism, in order to output some well formated HTML, but I don't manage to have the wanted output.

Concretely, I have a radio button form element (Zend_Form_Element_Radio), with a multiple option registred in it, like this:

Here is the wanted HTML output:

I have turned in many ways the problem, but I don't see any solution. Any help will be appreciated !

我试图在一个类中装饰一个方法，但 python 抛出一个错误。我的课看起来像这样：

pageutils.py：

Python 抛出以下错误

我在哪里偷懒？