馄饨代码 - 为啥是反模式？ [关闭]

Posted 2023-05-07

技术标签:

【中文标题】馄饨代码 - 为啥是反模式？ [关闭]【英文标题】：Ravioli code - why an anti-pattern? [closed]馄饨代码 - 为什么是反模式？ [关闭] 【发布时间】：2011-01-04 08:28:15 【问题描述】：

我最近遇到了一个术语“God object”，它被描述为“反模式”。我听说过不好的编码实践，但我从未听说过这样描述它们。

所以我前往 Wikipedia 了解更多信息，我发现有一个名为 'Ravioli code' 的反模式被描述为“以许多小型且（理想情况下）松散耦合的软件组件为特征。 "

我很困惑 - 为什么这是一件坏事？

【问题讨论】：

谁说这是不好的做法？松耦合是一件好事。我的代码并不脆弱，它是“al dente” :) @jldupont，我不认为这是一件坏事。然而，在关于“上帝对象”的***文章中，它被列为相反的反模式 “馄饨代码”作为一种反模式，将把所有东西都解耦到极致。假设您想要一个输出 html 的网页并创建一个 javascript 对象来输出每个单独的 HTML 标记（例如：objP、objBR、objHR），也许您还为常用词（objWordTHIS、objWordIS、 objA) 和可能不太常见的词 (objWordRidiculous, objWordIdea) 然后你编写一个程序，在每个词上调用 .displayMethod 来创建“

这是一个荒谬的想法”，它的耦合非常松散，但会是一个设计很差。

【参考方案1】：

意大利面：

意大利面条代码是一个贬义术语获取源代码

馄饨：

馄饨码是一种计算机程序结构，其特点是小和（理想情况下）的数量松耦合的软件组件。比较这个词意大利面条代码，比较程序意大利面的结构；

这是在比较它们。这并不是说它是一种反模式。

但我同意。这篇文章很混乱。问题不在于馄饨类比，而在于***文章结构本身。它开始称意大利面条是一种不好的做法，然后说一些例子，然后说一些关于馄饨代码的事情。

编辑：他们改进了这篇文章。是一种反模式，因为

虽然从耦合和内聚的角度来看通常是可取的，但过分热切地分离和封装代码会导致调用堆栈膨胀，并使得在代码中导航以进行维护变得更加困难。

【讨论】：

嗯，如果“馄饨代码”不是一种反模式，那么对于一个代码库的贬义术语是什么，它被分解成许多没人能理解的单独类系统做什么？因为我为此使用了“馄饨代码”。 @Trejkaz 我在这个答案 5 年后阅读了这篇文章，并且好多了。 “虽然从耦合和内聚的角度来看通常是可取的，但过分热心代码的分离和封装会使调用堆栈膨胀，并使代码导航变得更加困难以进行维护。” 我推荐 Zed Shaw 的这篇文章，它对过度热心的脱钩问题提供了一个很好的视角：zedshaw.com/archive/indirection-is-not-abstraction .. 也许我们可以说你不应该用馄饨填满自己否则你之后会感觉很糟糕。或者，如果您想真正简洁，就称它为坏馄饨，它的味道肯定不应该。【参考方案2】：

我想说很明显，馄饨代码和千层面代码都是贬义词——故意放在他们的意大利面比喻“意大利面条代码”旁边——这两个术语都描述了现实世界的反模式。有些代码维护起来非常耗时，而且很容易失败，因为它被分解成许多独立的子流程——那就是馄饨代码。某些代码具有如此多的抽象层，以至于很难对其进行更改和/或理解发生故障的级别 - 这就是千层面代码。更改千层面代码的唯一实用方法通常是简单地绕过这些层并编写完成这项工作的简单代码。我必须维护一些馄饨代码，但一般来说，这样的代码会受到卷积的影响，无法广泛使用，所以我们都熟悉的例子很少。相比之下，千层面代码目前无处不在。我喜欢认为我自己不写任何意大利面代码，但你至少可以跟着一串意大利面......

【讨论】：

加一个表示“但你至少可以跟随一串意大利面条。”【参考方案3】：

它在 Spaghetti 代码页面中列出，但这并不意味着它是一件坏事。之所以存在，是因为这是一个相关术语，并不足以拥有自己的页面。

关于它不好的一面，谷歌在http://developers.slashdot.org/comments.pl?sid=236721&cid=19330355给出了评论：

问题在于，它往往会导致函数（方法等）没有真正的连贯性，而且它经常让代码去实现一些相当简单的东西，分散在大量的函数中。任何必须维护代码的人都必须了解所有位之间的所有调用是如何工作的，除了使用函数调用而不是 GOTO 之外，几乎重现了 Spaghetti Code 的所有缺点。 ...

你必须判断它是否合理:)。

【讨论】：

【参考方案4】：

“馄饨代码”作为一个短语得以幸存的唯一原因几乎是因为程序员天生就有幽默感。尽我所能尝试——相信我，我已经尝试过了——真的很难想出一个面向对象代码的例子，它既（a）被打包，所以很难以相同的元意义导航“意大利面条代码”难以导航，并且 (b) 反映了编码实践中常见的反模式。

我能想到的“馄饨代码”的最佳示例是大量的类，每个类都紧密封装，但很难找出主要执行流程在哪里。神经网络应用程序可能会表现出这一点，但这就是重点。一个更普通的例子是非常面向事件的 UI 代码，但同样，这很难过火 - 如果有的话，大多数 UI 代码都不是事件驱动的足够。 p>

【讨论】：

【参考方案5】：

问题是不同的人使用“馄饨代码”这个词来表示不同的东西。

合理数量的相当小的组件是好的。一大堆没有明显整体结构的细小组件不太好。

松散耦合的组件是好的。为了看起来松散耦合而隐藏它们的相互依赖关系的组件并不是那么好。

能够看到不同组件之间的关系其实是一件好事。

尽管大多数代码库都有相反的问题，因此向更多模块化方向发展通常是一件好事。我希望大多数人甚至从未见过所谓的“馄饨代码”。在实践中，它看起来更像是切碎的馄饨（应该是一个模块被分成多个“模块”——这些模块本身没有任何意义，但只能与它们相应的其他部分结合使用），或者像馄饨没有足够的水煮熟（所以你最终会得到一大块“模块”全部粘在一起）。

TODO：将“Hello world”程序编写为大约 100 个模块来展示过度模块化。

TODO2：尝试用一卡车的馄饨搭建一座桥梁，以展示次优的结构特征。

【讨论】：

【参考方案6】：

如果您应用一个教条规则，即所有项目中的所有类都必须松散耦合，无论出于何种原因，那么我可以看到存在很多潜在问题。

你可以转动你的***，试图让一个完美的应用程序变得越来越松散耦合，而实际上却没有给它增加任何价值。

不过，让我赶紧补充一下，我认为我们都应该以松散耦合的类、组件等为目标

【讨论】：

【参考方案7】：

不一定，是吗？***的文章并没有将其描述为糟糕。许多松散耦合的软件组件，其中这些组件的大小和数量与问题域相关，对我来说听起来非常理想。

事实上，如果您查找馄饨代码的其他定义，您会发现它被描述为理想的软件设计模式 - 我仍然更喜欢注意大小和数量需要适当的警告。

【讨论】：