我最近遇到了一个术语" 上帝对象 ",被称为"反模式".我听说过不好的编码习惯,但我从来没有听说过它们.
因此,我前往维基百科了解更多信息,我发现有一种称为"馄饨代码"的反模式被描述为"以许多小型(理想情况下)松散耦合的软件组件为特征".
我很困惑 - 为什么这是一件坏事？
Gmo*_*onC 31
Spaghhetti:
Spaghetti代码是源代码的贬义词
馄饨:
馄饨代码是一种计算机程序结构,其特征在于许多小的(理想地)松散耦合的软件组件.术语是在比较与面条代码,程序结构进行比较来面食;
它正在比较它们.这并不是说它是一种反模式.
但我同意.这篇文章令人困惑.问题不在于馄饨类比,而在于wikipedia文章结构本身.它开始称Spaghetti为一种不好的做法,然后说了一些例子,然后说了一些关于Ravioli代码的东西.
编辑:他们改进了文章.是反模式因为
虽然从耦合和内聚角度来看通常是合乎需要的,但是过度分离和封装代码会使调用堆栈膨胀并且为了维护目的而使代码导航更加困难.
ken*_*ytm 14
它列在Spaghetti代码页面中,但这并不意味着它是一件坏事.它就在那里,因为这是一个相关的术语,并不足以拥有自己的页面.
关于它的不好的一面,谷歌搜索在http://developers.slashdot.org/comments.pl?sid=236721&cid=19330355发表评论:
问题在于它往往导致函数(方法等)没有真正的连贯性,并且它经常使代码实现甚至分散在大量函数上的相当简单的东西.任何必须维护代码的人必须了解所有位之间的所有调用是如何工作的,重新创建几乎所有Spaghetti Code的坏处,除了函数调用而不是GOTO....
你必须判断它是否合理:).
Geo*_*all 11
我会说很明显Ravioli代码和Lasagna代码都是贬义词 - 故意放在他们的意大利面条比喻'意大利面条代码'旁边 - 这两个术语都描述了现实世界的反模式.有些代码维护非常耗时,而且很容易出现故障,因为它被分解为许多单独的子流程 - 即馄饨代码.有些代码有很多抽象层,很难实现对它的更改和/或理解发生故障的级别 - 即宽幅代码.改变宽面条代码的唯一实用方法通常是简单地绕过层并编写完成工作的简单代码.我必须保留一些馄饨代码,但一般来说这样的代码会受到卷积的影响而无法找到广泛的用途,所以我们都很熟悉它的例子.相比之下,烤宽面条代码目前无处不在.我想我自己不会写任何面食代码,但你至少可以遵循一串意大利面...
"馄饨代码"作为一个短语幸存下来的唯一原因是因为程序员具有天生的幽默感.尽我所能 - 相信我,我已经尝试过 - 很难想出一个面向对象代码的例子,这些代码都是(a)打包的,因此很难在相同的元感觉中导航"意大利面条代码"难以导航,(b)反映了编码实践中经常出现的反模式.
我能提出的"馄饨代码"的最好例子是大量的类,每个类都紧密打包,但是很难找到主要执行流程的位置.神经网络应用程序可能会展示这一点,但这就是重点.一个更平凡的例子是UI代码,它非常注重事件,但同样,很难超越它 - 如果有的话,大多数UI代码都不是事件驱动的.
问题是不同的人使用术语“馄饨代码”来表示不同的东西。
合理数量的合理小组件是好的。一大堆没有明显整体结构的微小组件并不是那么好。
松散耦合的组件很好。为了看起来松散耦合而隐藏其相互依赖关系的组件并不是那么好。
能够看到不同组件之间的关系其实是一件好事。
但是，大多数代码库都存在相反的问题，因此转向更多模块化通常是一件好事。我希望大多数人甚至从未见过糟糕的“馄饨代码”。在实践中，它往往看起来更像是切碎的馄饨（其中应该是一个模块的东西被分成多个“模块”——这些模块本身没有意义，而只能与相应的其他部分结合起来），或者像馄饨没有足够的水煮熟（所以你最终会得到一大团“模块”粘在一起）。
待办事项：将“Hello world”程序编写为约 100 个模块以演示过度模块化。
TODO2：尝试用一卡车的馄饨建造一座桥梁，以展示次优的结构特征。