保持低速同时坚持干燥

“保持高凝聚力和低耦合度”（或某些变体）的口号经常被丢弃。但是，我发现它经常与“不要重复自己”相冲突。例如，我认为我们都可以同意重新实现std::string或使用C字符串，但不包括std::string创建另一个依赖关系并因此增加耦合是一件坏事吗？保持低速同时坚持干燥

再例如，采取std::stringstream。它继承自iostream，其继承自istream和ostream，其继承自ios，其继承自ios_base。在所有这些推导中，它继承了功能的，足以使手工重新实现一个非常糟糕的主意。它也拉动<ios>和<istream>标题，即使只包含<sstream>，从而增加了耦合。

如何在不重新为每个模块重新开发车轮的情况下保持低耦合？

编辑：如果两个概念不能共存，哪一个应该受青睐？

来源

2011-07-03 Maxpm

一个特定的实例可能会导致更好的答案，并减少理论。 – tenfour

有人可以解释近距离投票吗？这个问题非常清楚。 – Maxpm

它符合__not constructive__描述：“这个问题不适合我们的问答格式，我们希望答案通常涉及事实，参考资料或具体的专业知识;这个问题可能会征求意见，辩论，争论，投票或延长讨论“。 –

请通过http://www.artima.com/intv/dry.html去干，
特别“大多数人都干意味着你不应该重复的代码。这不是它的本意。干背后的想法是远远超过了宏大的”。

除此之外，在你讨论的例子中，std :: string和你的系统没有紧密耦合，因为你不依赖/使用std :: string的任何内部信息。任何（内部）对std :: string的更改都不会影响您的系统。

来源

2011-07-03 22:32:36 Tatvamasi

良好的联系。我发现关于正交性的部分尤其是启发性的，因为它阐明了*无关的东西不应该彼此了解。在我的''的例子中，知道其他头文件是有意义的。如果它需要一些荒谬的话，比如''，*那么*这将是不好的耦合。 – Maxpm

@Maxpm你说话，如果std ::字符串没有正确设计，松耦合？或使用std :: string？如果是用法，我相信不需要担心std :: string的实现细节。 std :: string可能依赖于许多其他功能来实现其所有的API。（它可能甚至取决于火箭发射功能...有正当理由）。 – Tatvamasi

我在说'std :: stringstream'，而不是'std :: string'。（我改变了原来的问题来举一个更好的例子。）无论如何，我并不是说它设计得不好，而是将它用作我正在谈论的真实案例。 – Maxpm

保持低速同时坚持干燥

回答

相关问题