问题标签 [decoupling]

JavaScript 在大多数 Web 解决方案中扮演着越来越重要的角色，但我发现将 JS 代码与视图细节分离比服务器端代码更难。

人们使用什么技术来解耦 JS 代码，以减少维护负担并使其尽可能适应较小的视图更改？

为了提供一个具体的例子，我有一个看起来像下面这样的视图：

JS 部分分为两个文件——第一个是我的“业务逻辑”类，第二个主要用于接线：

以及接线部分：

上面代码的问题在于它与视图的外观（必须存在的元素 ID、结构等）之间的联系有多紧密，但我对如何改进它没有好主意。

在我看来，如果我继续沿着这条路走下去，JS 文件最终会变成一堆正确封装的逻辑以及各种特定于视图的东西。

这是我希望做的最好的事情，还是我可以应用任何技术来避免这种混乱？

我自己关于如何改进这一点的想法围绕着构建某种服务器端生成的“元素选择器”JS 类，这样我就可以编写 JS 而不使用对类和元素 ID 的大量字符串引用。但我不确定如何生成它，或者最终维护它是否会更糟。

我有这个主干模型：

对应的视图：

该应用程序还有一个加载 csv 数据的通用数据源：

每次更改模型属性时，我想在触发更改事件之前检查是否加载了该属性组合的数据。

我的问题是：将数据源与 Backbone 模型和视图解耦以便我可以轻松尝试注入的模拟数据的好方法是什么？

代码示例是 C#，但这是一个一般的 OO 问题。

我知道根据 OO 规则，应尽量减少类耦合，成员应尽可能保持私有，等等。

考虑这个例子：

您正在编写一个深奥的程序，该程序具有某种数据集（我不是在谈论System.Data.DataSet），它实际上用于程序的各个方面。事实上，程序的存在基本上只是为了加载、显示、操作和保存数据集。此外，任何时候都只能加载一个数据集，并且在程序打开时加载。

如果我们严格遵循 OO 规则，我们将有

但是，例如，我们可能会将public static Data成员存储在 中Program。

一方面，我们用一个稍短的函数签名换取了大大增加的类耦合。另一方面，我们不再将 Data 参数传递给几乎每个函数，无处不在。

正确的答案可能是：尽可能避免类耦合。本地数据变量只是指针，因此内存开销可以忽略不计，并且由于类是解耦的，它们可以在以后在其他地方使用。

虽然现实地说，Data 类的结构在不同的应用程序中可能会有显着的不同，所以你不能直接从这个程序中拉出一个类，然后把它放到其他地方而不做任何调整。以一种可以直接加入的方式编写类所需的额外时间和精力可能很难向利益相关者证明是合理的。

我现在正在研究这种程序，并且我使用了 OO-canon 方法：在需要的地方传递数据参数 我已经最小化了与 IData 接口的类耦合，以概括数据集以供将来代码重用。鉴于应用程序，我几乎可以肯定这段代码永远不会被重用。如果没有这些额外的接口和抽象，就最终用户而言，该程序的工作方式将完全相同，但对我来说将大大减少头痛和开发时间。

你怎么看待这件事？您是否认为花费所有额外的时间来编写接口和泛化以确保类在可能的情况下解耦是合理的，尤其是当您以后看不到在其他地方使用的类时？

我经常发现自己在为一个类放置序列化代码的地方感到困惑，并且想知道其他人对此主题的想法是什么。

沼泽标准序列化是不费吹灰之力的。只是装饰有问题的班级。

我的问题更多是针对通过各种协议或不同格式序列化的类，并且需要对过程进行一些思考/优化，而不仅仅是盲目地序列化修饰的属性。

我经常觉得让所有代码在自己的类中使用一种格式会更干净。它还允许您通过添加新类来添加更多格式。例如。

然而，这通常意味着 MyClass 必须向外界公开更多的内部结构，以便其他类有效地序列化。这感觉是错误的，并且违背了封装。有办法解决它。例如，在 C++ 中，您可以让序列化程序成为朋友，或者在 C# 中，您可以将某些成员公开为显式接口，但仍然感觉不太好。

当然，另一种选择是让 MyClass 知道如何将自己序列化为各种格式：

这感觉更加封装和正确，但它将格式与对象结合在一起。如果某些外部类由于 MyClass 不知道的某些上下文而知道如何更有效地序列化怎么办？（也许一大堆 MyClass 对象正在引用同一个内部对象，因此外部序列化程序可以通过只序列化一次来优化）。此外，如果您想要一种新格式，则必须在所有对象中添加支持，而不仅仅是编写一个新类。

有什么想法吗？我个人根据项目的确切需求使用了这两种方法，但我只是想知道是否有人有强烈的理由支持或反对特定方法？

如果我一直遵循解耦，看起来 DataAccess 层应该与模型解耦。但是随后将信息传递给数据访问层变得很麻烦......而不是：

我会做

这不会破坏简单的目的吗？

我认为将模型传递给我的数据访问层是非常干净的代码，但它并没有解耦。

我正在编写一个小的 javascript 脚本来编辑 CSS 代码，我发现与其他浏览器相比，Internet Explorer 有很多……特殊性，如果我可以这么说的话。例如，document.stylesheet 对象的规则对象在大多数浏览器中称为 cssRule，在 IE 中称为规则。

我想在这里做的是分配包含窗口大小（window.innerWidth & document.body.clientWidth）的对象的属性的引用，以避免每次检查是否应该使用 IE 对象名称或“正常”的一个。

这是一个好/坏主意吗？

在发布问题之前，我想了更多关于它并想出了一个解决方案..

有没有另一种/更好的方法来做到这一点？

谢谢

（是的，我知道这样做真的没有必要，特别是因为我正在制作一个小脚本并且性能并不是一个真正的问题，但我主要是好奇。）

我正在使用 Microsoft XNA 框架开发一个游戏项目，尽管这个问题是一个涉及类/系统解耦的通用问题。

假设我有一个类（已简化以适合此示例），如下所示：

我想在使用 C# 的多个平台之间尽可能多地重用代码。

直接引用Color结构的问题在于，这种类型是在 XNA 程序集中定义的，在我的代码和 XNA 之间创建了强耦合（或依赖）。

我将使用的另一个框架可能（也可能没有）有自己的Color对象，有自己的一组属性和 API。

我希望有相同的源文件“知道”以自动使用 XNA 或其他框架的实现。

我知道其他类型的解耦方法，例如 IoC，但这意味着我将插入不同版本的系统/类，而不是在不同的上下文中重用同一个类。

这甚至可能吗？你会如何建议保持这样的系统便携？

我见过一些情况（在本机 C++ 开发中），您将定义一组类来反映您正在使用的框架所具有的类（例如这里 - 再次定义 Color），因此可以“重新- map" 稍后根据需要使用不同的类。

另一种选择是使用#IFDEF 来处理类标题中的 using 语句（从 XNA 切换到其他平台）。在这种情况下，最好的选择是什么？

我在主干中有一个集合......在初始化方法中我正在这样做......当这个集合添加了一个项目时，我想重新渲染一个视图。

这个解决方案非常有效，但是我的同事说我完全违背了骨干的设计初衷。有没有更好的方法来做到这一点，或者这是一个好的做法？这些问题有点主观，我真的想知道我应该如何正确地做这样的事情。感谢您的任何反馈或建议。

回应答案......好吧，对象模型更深。讨论视图有一个讨论模型，它有一个主题属性，它是主题模型的骨干集合。每个主题都有一个回复模型的回复集合。将回复添加到主题时，我需要再次呈现讨论视图。如何正确设置该链？

在54:53 分钟的演讲中，Rich Hickey 谈到了使用队列作为解耦依赖程序部分的一种手段。你能给我举个例子，说明如何将以下 Java 伪代码解耦以改进其设计和/或灵活性：

saveObjectToDatabaseandsaveObjectToDatabase可以看作是一种有副作用的方法，而computeB's 和computeC' 的输出只依赖于a.

我知道这个问题相当模糊/广泛。我想了解如何利用排队机制而不会使我的程序变得非常复杂，并且仍然确保它以正确的顺序做正确的事情。任何指向正确方向的指针都值得赞赏。

想象一组代表一些 API 的库。通过使用控制机制的反转，具体的实现将被注入到一个消费项目中。

这是一种情况。我有一些 API 库依赖于某些功能的其他 API 库 - 因此 API 库本身在某些时候是耦合的。这种耦合以后可能会成为一个问题，因为改变一个API会导致依赖的API发生变化，相应的实现也需要改变，所以最坏的情况是我们最终需要相当多的项目修改以反映仅其中一个的变化形式。

现在我想到了两种可能的解决方案：

• 创建一个统一相关 API 库的单体 API 项目。

• 通过使每个库为依赖于其他 API 的所有功能提供接口来进一步解耦 API ，从而消除直接依赖关系。这可能会导致两个库中的代码相似，但可以自由选择通过 IoC 机制选择的实现，还允许 API 彼此独立改进（当 API 发生更改时，更改将仅影响其实现库，而不影响其他 API 或其实现）。

第二种方法的问题是代码重复，结果可能是需要引用的 api 库过多（例如，在 .NET 应用程序中，每个 API 将是一个单独的 DLL。在某些情况下，例如 Silverlight应用程序，这可能是应用程序大小的问题 - 下载时间和客户端整体性能）。

有没有更好的解决方案。什么时候将一些 API 库合并成一个更大的库更好，什么时候不合并？我知道这是我要问的一个非常普遍的问题，但是让我们暂时忽略到期日期、估计、客户要求和技术，我希望能够基于实现最大可扩展性和最短维护时间来确定正确的方法。那么，选择这两种方法或您可能建议我的另一种方法的充分理由是什么？

编辑：

我觉得我必须澄清一下这个问题。我考虑将 API 彼此分离，而不是将 API 与其实现分离。因此，例如，如果我有用于验证访问权限的安全 API，以及使用（引用）安全 API 的用户帐户 API，则更改安全 API 将需要更改用户帐户 API 以及它们的实现。以这种方式耦合的 API 越多，必须应用的更改就越多。这是我想要避免的。