当一个小部件需要使用功能进行修饰时（可能需要几个不同的小部件），我一直在采用mixin方法。
例如，对于自定义小部件库，我可以看到一些mixin： - L10n支持（例如，通过提供直接函数来覆盖类似f10Callback（），使得通过F10捕获某些键变得微不足道） - 自定义主题支持（如为跨越许多不同小部件的特定于域的情况添加某些css类）
我有点像在一个小部件上打一个mixin的想法，这对我来说似乎只是在正在做mixin的小部件的小部件生命周期之后添加函数和属性。
一些问题： - 我是否过度使用了这个混合的想法？ - 如何防止mixins被多次应用到同一个小部件（比如什么时候 - 你扩展的模块已经有了mixin）？ - mixin应该保持状态吗？ - mixin的暴露功能应该如何？通过提供其小部件需要覆盖的功能？或者更多的酒吧/分方法？
真的只是在寻找与dojo mixins的一般建议。
答案 0 :(得分：0)
我认为你对如何使用mixin是正确的：它们意味着小巧，便携，并且对其他对象的行为进行了特定的调整。
没有内置的mixin幂等机制：你需要自己管理它。我从未在现场遇到过这种情况，因为我倾向于在运行中声明类，并且mixin在使用之前发生。例如，如果我使用mixin进行主题化，我会在我的顶级“界面”（负责将所有小部件粘合在一起）而不是每个可以主题的类中进行。
Mixins可以并且保持状态。例如，参见dijit / form / _FormWidgetMixin.js
mixin的暴露功能如何？好吧，我会说这取决于整体设计，没有正确的方法。我的mixins通常只是透明地扩展基类的API：即它们在不添加API的情况下添加到类行为中。在某些情况下，基类是一个抽象接口，并且需要mixins来实现行为（主要是在我实现策略或构建器模式时）。