Redis这么多集群方案，要用哪种？

我们在这里做了一些值得注意的更改。

首先，我们将插件与“核心(core)”计算器方法(如plus和minus)分开，方法是将其放入自己的插件对象中。将我们的插件存储在plugins 对象中可使我们的系统更安全。现在，访问此 plugins 的插件将看不到BetaCalc属性，而只能看到 betaCalc.plugins 的属性。

其次，我们实现了一个 press 方法，该方法按名称查找按钮的功能，然后调用它。现在，当我们调用插件的 exec 函数时，我们将当前的计算器值(currentValue )传递给该函数，并期望它返回新的计算器值。

本质上，这个新的 press 方法将我们所有的计算器按钮转换为纯函数。他们获取一个值，执行一个操作，然后返回结果。这有很多好处：

• 它简化了API。
• 它使测试更加容易(对于BetaCalc和插件本身)。
• 它减少了我们系统的依赖性，使其更松散地耦合在一起。

这种新架构比第一个示例受到更多限制，但效果很好。我们基本上为插件作者设置了护栏，限制他们只能做我们希望他们做的改动。

实际上，它可能太严格了!现在，我们的计算器插件只能对 currentValue 进行操作。如果插件作者想要添加高级功能(例如“记忆”按钮或跟踪历史记录的方式)，那么他们将无能为力。

也许这就是好的。你给插件作者的能力是一种微妙的平衡。给他们太多的权力可能会影响你项目的稳定性。但给它们的权力太小，它们就很难解决自己的问题——在这种情况下，你还不如不要插件。

我们还能做什么?

我们还有很多工作可以改善我们的系统。

如果插件作者忘记定义名称或返回值，我们可以添加错误处理以通知插件作者。像QA开发人员一样思考并想象一下我们的系统如何崩溃，以便我们能够主动处理这些情况，这是很好的。

我们可以扩展插件的功能范围。当前，一个BetaCalc插件可以添加一个按钮。但是，如果它还可以注册某些生命周期事件的回调(例如当计算器将要显示值时)怎么办?或者说，如果有一个专门的地方让它在多个交互中存储一段状态呢?这会不会开辟一些新的用例?

我们还可以扩展插件注册的功能。如果一个插件可以通过一些初始设置来注册呢?这是否能使插件更加灵活?如果一个插件作者想注册一整套按钮，而不是一个单一的按钮——比如“BetaCalc统计包”?需要做哪些改动来支持呢?

你的插件系统

BetaCalc及其插件系统都非常简单。如果你的项目较大，则需要探索其他一些插件架构。

一个很好的起点是查看现有项目，以获取成功的插件系统的示例。对于JavaScript，这可能意味着jQuery，Gatsby，D3，CKEditor或其他。你可能还想熟悉各种JavaScript设计模式，每种模式都提供了不同的接口和耦合程度，这给你提供了很多好的插件架构选择。了解这些选项有助于你更好地平衡使用你的项目的每个人的需求。

除了模式本身之外，你还可以借鉴许多好的软件开发原则来做出此类决策。我已经提到了一些方法(例如开闭原则和松散耦合)，但是其他一些相关的方法包括Demeter定律和依赖注入。

我知道这听起来很多，但你必须进行研究。没有什么比让每个人都重写他们的插件更痛苦的了，因为你需要更改插件架构。这是一种快速失去信任的方式，让人们失去对未来贡献的信心。

总结

从头开始编写好的插件架构是困难的!你必须平衡很多考虑因素，才能建立一个满足大家需求的系统。它是否足够简单?功能够强大吗?它是否能长期工作?

不过这也是值得的，有一个好的插件系统对大家都有帮助，开发者可以自由地解决他们的问题。最终用户可以从中选择大量可选择的特性。你可以围绕你的项目建立一个生态系统和社区。这是一个三赢的局面。


 

（编辑：平顶山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!