如何协调 Javascript 库中的 DRY 和松散耦合？

Question

我正在构建自己的 JS 库；
这个想法是该库应该由小的独立模块和一些稍大的实用程序组成，主要用于消除浏览器的差异。
我无法完成任何事情，因为我无法在保持干燥或松散耦合之间做出决定。

一个例子？给定：

• 一个小型库，负责从模板生成 dom 元素
• 另一个负责处理鸭子类型问题（is_function、is_array...）
• 最后一个创建模态框。最后一个需要：
  • 一些类型检查
  • 将仅使用模板库中的一个函数创建模式

我对模态框库的选择：

1. 100% 干燥，并依赖于其他两个库。但这意味着，如果您是只想下载模态框库的用户，则必须与其他两个一起制作
2. 允许用户在启动时传递一个选项对象，以允许他们指定所需的功能；默认为库中的那些。这更好，但实际上，在 90% 的情况下，这仍然意味着使用提供的库，因为创建具有相同签名的函数可能很麻烦。此外，它还增加了模态框代码的复杂性。
3. 100% 松散，重现我的模态框库中所需的功能；可能更有效，因为更有针对性，并且不需要检查边缘情况；但是：任何错误都必须在两个地方修复，并且我的下载大小会增加。

所以我浪费时间在两个极端之间摇摆不定，重构一百万次却从不满足。
我本来想问一个更通用的问题，但后来我意识到它确实与 JS 相关，因为它涉及大小和性能问题以及广泛使用。

在这种情况下是否有任何已知的模式可以遵循？什么是公认的方式来解决这个问题？欢迎任何想法。

[编辑：]
这是我发现的only article，它说明了我的担忧。正如文章所说，

DRY 很重要，但 [...] 低耦合和高内聚也很重要。 [...] 您必须考虑所有 [原则] 并权衡它们在每种情况下的相对价值

我想我无法在这种情况下衡量它们的价值。

Answer 1

就我个人而言，我一直认为Loose Coupling 指的是在您的代码中创建接缝。在 Java 等经典语言中，这是通过创建隐藏具体实现的接口来实现的。这是一个强大的概念，因为它允许开发人员在您的应用程序中“解开接缝”并用模拟和测试替身（或者实际上是他们自己的实现）替换具体的实现。由于 JavaScript 是一种动态语言，开发人员依赖于鸭子类型而不是接口：由于没有任何东西被冻结，每个对象都成为代码中的一个接缝并且可以被替换。

直接回答您的问题，我认为始终致力于将您的代码分解和模块化为更小的库是有好处的。您不仅要避免重复代码（出于多种原因，这不是一个好主意），而且您还鼓励其他只想重复使用您的库的一部分的开发人员重复使用。

与其重新发明轮子，不如利用一些更流行的 JavaScript 库；例如，underscore.js 是一个轻量级库，它为鸭式检查提供了丰富的工具包，Mustache.js 可以很好地满足您的模板需求。

许多现有项目已经使用这种方法，例如，Backbone.js 依赖 underscore.js，jQuery Mobile 依赖 jQuery。 RequireJS 等工具可以轻松列出和解析应用程序的 javascript 依赖项，甚至可以用于combine all the separate.js files into a single, minified resource。

Answer 2

我喜欢 DRY 的概念，但你的权利有几个问题。

1. 您的最终用户开发人员需要知道他们需要下载组件的依赖项。

2. 您的最终用户开发人员需要知道他们需要配置依赖项（即传入的选项）。

帮助解决 1.您的项目网站可以自定义下载，因此核心代码与可选组件一起下载。喜欢modernizer download page。

为了帮助解决 2. 与其允许用户传入选项，不如使用合理的默认值来检测包的哪些部分已加载到浏览器中并自动绑定它们。 这种松散耦合还可以为您带来巨大的优势，如果用户已经安装了第三方框架，也可以依赖它们。例如selectivizr 允许您根据浏览器已经加载的内容使用 jquery 或 dojo 等。

也许您可以使用requirejs 来帮助解决依赖管理问题。我的印象是，它并不是真正让库直接使用，而是最终用户开发人员......但它可能是一个不错的选择。

我知道我的回答并没有直接回答你的问题，但也许它可以帮助平衡 DRY 的一些负面因素。