是否可以构建可选扩展基本插件但应用程序仍然不知道的回购插件结构？

Question

我正在尝试制作一个基本的 in-repo 插件，通过 platform/services/whatever 等命名空间提供功能。

除此之外，如果另一个插件 isEnabled() 扩展或重新打开相同的服务（以某种方式），我希望它全部合并在一起，而不必按名称调用第二个插件的服务，例如 platform-second/services/whatever

我只想要一个漂亮干净的抽象。我这样做的原因是因为基于 ENV 变量，我需要在 index.html 和不同的 app.imports 中构建/注入不同的东西。

我希望它完全分离成单独的小回购插件以保持清洁。

我希望应用程序不需要知道platform，而只需能够使用通用platform 插件的方法。

因此，例如platform.services.whatever.myMethod() 默认情况下可能是一个 noOp，但如果第二个插件扩展它并实现它，它将自动触发该版本。

不知道我是否有任何意义 LOL

如果您对如何实施此设置有任何提示或建议，请告诉我。

我目前已经构建了 in-repo 插件，但理想情况下，我将基本 platform 插件作为实际具有 app 文件夹内容的插件和“扩展”或“覆盖”方法的其他插件/ 基于该 ENV 变量，该插件对象的 / 属性将只是 isEnabled()。

我应该补充一点，我不能简单地合并树并覆盖原始文件，因为我需要这些文件的基本功能。

因此，如果我扩展了基础 platform.services.whatever.myMethod() 的一种方法，那么我仍然需要该服务的其余方法和属性。

Answer 1

所以，我很难说得太具体，因为你的问题对细节有点模糊，但不用担心。我会抛出一些想法，希望我们可以一起得出一些有用的结论:)

如果您在运行时需要不同的对象，诀窍是根据配置在依赖注入容器中注册不同版本的服务（这在基于 DI 的编程中很常见）。所以在你的插件中有你的基础服务，甚至是一些具体的实现，用某些方法的不同实现来扩展基础。然后，在您的应用程序中，您有一个初始化程序，它查看不同的 ENV 变量并确定要注入哪些服务。你总是在同一个键 service:some-service 下注入。因此，baseClass = Ember.Object.extend() 和impl1 = baseClass.extend({methodToOverride: ...} 允许您保留除您覆盖的方法之外的所有基类方法。所以你成功地避免了调用者必须知道是某个父母或孩子正在处理service.someMethod

现在，如果它只是在构建时，那么你在 node.js 中的土地（require() 和 module.exports。使用 pojos 或 es6，你有很多方法可以实现继承（原型继承，$.extend 用于分层合并pojos，es6 extends)...选择。但从编程设计模式的角度来看，您的插件似乎需要公开一个工厂，该工厂抽象出符合某个接口的对象的创建。所以导出一些具有 create 方法的模块，该方法接受选项对象并返回正确的 impl。