他们矛盾吗？
解耦是一件很棒的事情，而且很难实现。然而在大多数应用程序中我们并不真正需要它，所以我可以设计高度耦合的应用程序，它几乎不会改变任何东西，除了明显的副作用，例如“你不能分离组件”，“单元测试是痛苦的屁股”等。
你怎么看？您是否总是尝试解耦并处理开销？
Slough
问问题
1226 次
9 回答
7
在我看来，脱钩和 YAGNI 是非常互补的美德。（我刚刚注意到 Rob 的回答，似乎我们在同一页上。）问题是你应该做多少解耦，YAGNI 是帮助确定答案的好原则。（对于那些谈到单元测试的人——如果你需要解耦来进行单元测试，那么 YAGNI 显然不适用。）
我真的很怀疑那些说他们“总是”脱钩的人。也许他们每次想到都会这样做。但我从未见过无法在某处添加额外抽象层的程序，我真诚地怀疑是否存在这样一个程序的重要示例。每个人都在某处画一条线。
根据我的经验，我已经对代码进行了解耦，然后从来没有利用额外的灵活性，因为我经常将代码耦合在一起，然后不得不返回并稍后更改它。我不确定这是否意味着我在两个方向上都很平衡或同样破碎。
于 2009-03-02T17:59:04.827 回答
4
YAGNI 是一个经验法则（不是宗教）。脱钩或多或少是一种技术（也不是宗教）。所以它们并不真正相关，也不相互矛盾。
YAGNI 是关于实用主义的。假设您不需要某些东西，直到您需要为止。
通常假设 YAGNI 会导致解耦。如果您根本不使用那把刀，那么您最终会假设您需要拥有了解彼此行为的所有类，然后才能证明这是真的。
“解耦”（或“松散耦合”）是一个动词，所以它需要工作。YAGNI 是一个假设，当你发现它不再正确时，你会调整它。
于 2009-05-05T01:35:13.157 回答
2
我（几乎）总是解耦。每次我这样做时，我都发现它很有用，而且（几乎）每次我不需要以后都必须这样做。我还发现这是减少错误数量的好方法。
于 2009-03-02T09:19:43.293 回答
2
为了去耦而去耦可能是不好的。不过，构建可测试的组件非常重要。
故事的难点在于知道何时以及需要多少去耦。
于 2009-03-02T09:21:42.213 回答
2
我会说他们没有。解耦是关于减少代码中不必要的依赖关系，并通过干净、定义良好的接口加强访问。“你不需要它”是一个有用的原则，它通常建议不要在没有明显和当前用例的情况下解决解决方案的过度可扩展性和过于宽泛的架构。
这些的实际结果是，您拥有一个系统，可以更轻松地重构和维护单个组件，而不会无意中在整个应用程序中造成连锁反应，并且设计没有不必要的复杂方面 - 它就像需要的一样简单以满足当前的要求。
于 2009-03-02T09:22:52.430 回答
1
如果“单元测试很麻烦”，那么我会说您确实需要它。大多数情况下，解耦也可以以几乎零成本实现，那么您为什么不想这样做呢？
此外，在处理新代码库时，我最大的问题之一是在开始编写单元测试之前必须解耦代码，而在某处引入接口或使用依赖注入可以节省大量时间
于 2009-03-02T10:02:38.760 回答
0
好吧，YAGNI 只不过是人们到处乱扔的一个虚假的简单化短语。然而，去耦是一个很好理解的概念。YAGNI 似乎暗示一个人是某种通灵者。这只是陈词滥调的编程，这绝不是一个好主意。老实说，有一个案例可以证明 YAGNI 可能根本与解耦无关。耦合通常“更快”并且“谁知道您是否需要解耦解决方案；无论如何您都不会更改 X 组件！”
于 2009-03-02T09:21:31.137 回答
0
正如您的标签所说，这是非常主观的。这完全取决于你自己的工程智慧来决定你“不需要”什么。在一种情况下您可能需要耦合，但在另一种情况下则不需要。谁来告诉？你，当然。
因此，对于如此主观的决定，不可能有一个指导方针来规定。
于 2009-03-02T09:22:17.563 回答
0
YAGNI 乱七八糟 :) ...真的，我们不需要混合所有代码来“更快”。
单元测试在耦合时确实有助于感觉（假设一个人很好地理解什么是单元测试与其他类型的测试）。如果你用“你不能分离组件”的心态来做，你可以很容易地添加你不需要的东西:)
我会说 YAGNI 是在你开始扭曲和改变当前实现所要求的实际使用场景之外的逻辑时出现的。假设您有一些代码使用了几个外部支付提供商，它们都可以重定向到外部站点。可以有一个保持一切干净的设计，但我认为开始考虑我们不知道是否会得到支持的提供者是可以的，这些提供者有很多不同的方式来处理集成和相关工作流程。
于 2009-03-02T10:02:09.183 回答