饺子密码-为什么是反模式?[关闭]

Spaghhetti:

意大利面代码是 贬义的 学期 对于源代码

Ravioli:

饺子密码是一种计算机 程序结构,以 小数量和(理想情况下) 松散耦合的软件组件。 术语 在比较中 具有 意大利面代码,比较程序 结构到意大利面;

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

但我同意。这篇文章令人困惑。问题不在于水饺的类比,而在于维基百科的文章结构本身。它开始称意大利面为一种不好的做法,然后说了一些例子,然后说了一些关于饺子代码的东西。

编辑:他们改进了文章。是反模式,因为

虽然从耦合和内聚的角度来看通常是可取的,但是过分狂热的代码分离和封装会使调用堆栈膨胀,并使出于维护目的的代码导航变得更加困难。

它列在意大利面代码的页面上,但这并不意味着这是件坏事。它之所以存在是因为这是一个相关的术语,而且还不足以拥有自己的页面。

关于它的坏处,谷歌在 http://developers.slashdot.org/comments.pl?sid=236721&cid=19330355 :

问题是,它往往会导致函数(方法等)没有真正的一致性,而且它经常让代码实现一些非常简单的东西,这些东西分散在非常多的函数上。任何需要维护代码的人都必须理解所有位之间的调用是如何工作的,重新创建几乎所有意大利面条代码的坏处,除了函数调用而不是goto。…

你得判断是否合理。

我想说的是,很明显,饺子代码和千层面代码都是贬义词——故意放在他们的意大利面同人的旁边,类似于“意大利面代码”,这两个术语都描述了现实世界中的反模式。有些代码维护起来非常耗时,而且很容易失败,因为它被分解成许多独立的子流程——即饺子代码。有些代码具有如此多的抽象层,因此很难实现对它的更改和/或理解故障发生在什么级别——即宽面条代码。更改宽面条代码的唯一实际方法通常是简单地绕过这些层并编写完成工作的简单代码。我必须维护一些馄饨代码,但一般来说,这种代码是复杂的,无法广泛使用,所以我们几乎没有熟悉的例子。相比之下,宽面条代码现在无处不在。 我想我自己不会写任何意大利面代码,但你至少可以按照一系列意大利面……

“水饺代码”作为一个短语幸存下来的唯一原因,几乎是因为程序员有一种天生的幽默感。尽我所能去尝试——相信我,我已经尝试过了——很难想出一个面向对象的代码的例子,(a)打包成这样,很难用“意大利面代码”很难导航的元意义来导航,(b)反映了编码实践中频繁出现的反模式。

我能想到的“饺子代码”最好的例子是大量的类,每个类都被紧紧地打包在一起,但是很难找出执行的主要流程在哪里。神经网络应用程序可能会展示这一点,但这正是关键所在。一个更普通的例子是非常注重事件导向的UI代码,但同样,很难过度使用它——如果有的话,大多数UI代码都不是事件驱动的。 足够地 .

如果您应用一个教条主义的规则,即所有项目中的所有类都必须松散耦合,不管什么原因,那么我可以看到有很多潜在的问题。

你可以旋转你的轮子,试图使一个完美的应用程序越来越松散地耦合,而从来没有真正增加任何价值。

不过,让我赶快补充一点,我认为我们都应该瞄准松散耦合的类、组件等。

不一定,是吗?维基百科的文章并没有把它描述成坏的。一些松散耦合的软件组件,其中这些组件的大小和数量相对于问题域是合理的,对我来说,听起来非常理想。

事实上,如果你查一下其他关于馄饨代码的定义,你会发现它被描述成理想的软件设计模式——我仍然倾向于警告,尺寸和数量必须是适当的。

问题是不同的人用“饺子密码”这个词来表示不同的东西。

合理数量的小部件是好的。一大堆没有明显整体结构的微小部件就不是那么好了。

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

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

不过,大多数代码基都有相反的问题,因此朝着模块化方向发展通常是件好事。我想大多数人从来没有见过“饺子密码”的错误含义。实际上,它看起来更像切碎的意大利饺子(应该是一个模组的东西被分割成多个“模组”——没有一个模组本身有意义,但只与它们相应的其他部分结合在一起),或者像煮的意大利饺子没有足够的水(所以最后你会发现一个巨大的“模组”都粘在一起)。

TODO:编写一个“hello world”程序作为~100个模块来演示过度模块化。

TODO2:尝试用一卡车的意大利饺子建造一座桥,以展示其次优的结构特征。

阅读这篇文章,意大利面是一种反模式,但意大利饺和千层面不是反模式。