2

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

一个例子？鉴于：

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

我对模态框库的选择：

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

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

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

[编辑：]
这是我发现的唯一一篇说明我的担忧的文章。正如文章所说，

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

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

4

2 回答 2

3

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

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

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

许多现有项目已经使用这种方法，例如Backbone.js依赖 underscore.js 和jQuery Mobile依赖于 jQuery。RequireJS之类的工具可以轻松列出和解决应用程序的 javascript 依赖项，甚至可以用于将所有单独的.js 文件组合成一个单一的、缩小的资源。

于 2012-08-15T13:21:40.397 回答
1

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

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

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

帮助解决 1. 你的项目网站可以自定义下载，所以核心代码和可选组件一起下载。喜欢现代化的下载页面。

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

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

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

于 2012-08-15T13:19:49.027 回答