0

当一个小部件需要用功能来装饰时（可能需要几个不同的小部件），我已经更倾向于使用 mixin 方法。

例如，对于一个自定义的小部件库，我可以看到一些 mixin： - L10n 支持（例如，通过提供像 f10Callback() 这样的直接函数来覆盖某些键，例如 F10，使其变得微不足道） - 自定义主题支持（比如为跨越许多不同小部件的特定领域情况添加某些 css 类）

我有点喜欢在小部件上添加一个 mixin 的想法，对我来说，这似乎只是在执行 mixin 的小部件的小部件生命周期之后添加函数和属性。

一些问题： - 我是否过度使用了这个 mixin 的想法？- 你如何防止 mixins 被多次应用到同一个小部件（比如当你扩展的模块已经有 mixins 时）？- mixin 是否应该保持状态？- mixin 应该如何暴露功能？通过提供他们的小部件需要覆盖的功能？还是更多的发布/订阅方法？

真的只是在寻找有关 dojo mixins 的一般建议。

4

1 回答 1

0

我认为您在如何使用 mixin 方面是正确的：它们旨在小型、可移植并且对其他对象的行为进行特定调整。

mixin 幂等性没有内置机制：您需要自己管理它。我从来没有在现场遇到过这种情况，因为我倾向于动态声明类，而 mixin 在使用之前就发生了。例如，如果我使用 mixin 进行主题化，我会在我的顶级“界面”（负责将所有小部件粘合在一起）而不是在每个可以主题化的类中这样做。

Mixins 可以并且确实可以保持状态。参见例如 dijit/form/_FormWidgetMixin.js

mixin 应该如何暴露功能？好吧，我会说这取决于整体设计，并且没有正确的方法。我的 mixin 通常只是透明地扩展基类的 API：即它们添加到类行为中而不添加到 API。在某些情况下，基类是一个抽象接口，并且需要 mixin 来实现行为（主要是当我有策略或构建器模式要实现时）。

于 2013-11-03T13:07:04.750 回答