2010-01-12 17 views
25

Recientemente encontré un término 'God object' que se describió como 'antipatrón'. Había oído hablar de malas prácticas de codificación, pero nunca las había escuchado así.Código de ravioles: ¿por qué un antipatrón?

Así que me dirigí a Wikipedia para obtener más información, y encontré que hay un anti-patrón llamado 'Ravioli code' que se describe como "caracterizado por una serie de pequeños y (idealmente) componentes de software de acoplamiento débil".

Estoy desconcertado, ¿por qué es esto algo malo?

+3

¿quién dijo que esto era una mala práctica? El acoplamiento flojo es una buena cosa. – jldupont

+35

Mi código no es frágil, es "al dente" :) – RedFilter

+0

@jldupont, no creo que sea algo malo. Sin embargo, en el artículo de wikipedia sobre 'God Object' aparece como un opuesto * anti-pattern * –

Respuesta

25

Spaghhetti:

código espagueti es un término peyorativa para el código fuente

Ravioli:

código Ravioli es un tipo de ordenador estructura del programa, caracterizado por un número de de pequeño y (idealmente) componentes de software flojos. El término es en comparación con código de espagueti, que compara el programa estructura con la pasta;

Está comparándolos. No está diciendo que sea un antipatrón.

Pero estoy de acuerdo. El artículo es confuso El problema no está en la analogía de los raviolis, sino en la estructura del artículo de Wikipedia. Comienza a llamar Spaghetti como una mala práctica, luego dice algunos ejemplos y luego dice algo sobre el código Ravioli.

EDITAR: Mejoraron el artículo. Es un anti-patrón porque

Aunque generalmente deseable desde el punto de vista de acoplamiento y la cohesión, la separación exceso de celo y la encapsulación de código puede hinchar las pilas de llamadas y hacer la navegación a través del código para fines de mantenimiento más difíciles.

+3

Hmm, si "ravioli code" no es un antipatrón, entonces ¿cuál es el término _pejorative_ para una base de código que está dividida en tantas clases individuales que nadie puede entender lo que hace el sistema? Porque estaba usando el "código de raviolis" para eso. – Trejkaz

+3

@Trejkaz He leído el artículo después de 5 años de esta respuesta y es mucho mejor. "Aunque en general es deseable desde una perspectiva de acoplamiento y cohesión, la separación y el encapsulamiento ** excesivo de código puede engordar las pilas de llamadas y dificultar la navegación a través del código para fines de mantenimiento". – GmonC

+1

Recomiendo esta publicación de Zed Shaw, ofrece una muy buena perspectiva sobre el desacoplamiento excesivo: http://zedshaw.com/archive/indirection-is-not-abstraction/ .. Tal vez podríamos decir que no deberías Llénate de ravioles o te sentirás mal después. –

3

No es necesariamente, ¿verdad? El artículo de Wikipedia no lo describe como malo. Un número de componentes de software débilmente acoplados, donde el tamaño y el número de estos componentes es sensible en relación con el dominio del problema, me suena bastante ideal.

De hecho, si busca otras definiciones de código de ravioles, lo encontrará descrito como el patrón de diseño de software ideal. Aún prefiero la advertencia de que el tamaño y el número deben ser apropiados.

2

Al leer el artículo, Spaghetti es un anti-patrón; pero los raviolis y lasaña no son antipatrones.

+1

Gracias. Estaba bien con leer sobre Spaghetti y Ravioli, pero ahora que enumeró tres en una fila, tengo hambre. Me pregunto si el código de Penne es para que puedas ver a través de. – OregonGhost

+1

@OregonGhost - El patrón "penne" podría ser un código de "tubería": http://www.eaipatterns.com/PipesAndFilters.html – ChrisW

13

Aparece en la página del código Spaghetti, pero eso no significa que sea algo malo. Está ahí porque es un término relevante y no lo suficientemente importante como para tener su propia página.

En cuanto al lado malo de ella, buscando en Google da un comentario en http://developers.slashdot.org/comments.pl?sid=236721&cid=19330355:

El problema es que tiende a conducir a funciones (métodos, etc.) sin verdadera coherencia, y que a menudo deja el código implementar incluso algo bastante simple diseminado en un gran número de funciones. Cualquiera que tenga que mantener el código tiene que entender cómo funcionan todas las llamadas entre todos los bits, recreando casi toda la maldad del Código Spaghetti excepto con llamadas a función en lugar de GOTO. ...

Tienes que juzgar si es razonable :).

4

Si aplica una regla dogmática que todas las clases en todos los proyectos deben estar ligeramente acopladas independientemente de cualquier motivo, entonces puedo ver que hay muchos problemas potenciales.

Puede hacer girar sus ruedas tratando de hacer una aplicación perfectamente fina cada vez más acoplada libremente sin siquiera agregarle ningún valor.

Me apresuro a añadir, sin embargo, que creo que todos debemos apuntar hacia las clases débilmente acoplados, componentes, etc

6

Más o menos el "código raviolis" única razón por la que ha sobrevivido como una frase se debe a que los programadores tienen un sentido del humor innato Por mucho que lo intente, y créanme, lo he intentado, es realmente difícil encontrar un ejemplo de código orientado a objetos que haya sido (a) empaquetado de modo que sea realmente difícil navegar en el mismo meta-sentido que " el código de spaghetti "es difícil de navegar, y (b) refleja un anti-patrón frecuente en la práctica de codificación.

El mejor ejemplo de "código de ravioles" que se me ocurre es una multitud de clases, cada una de ellas bien empaquetada, pero en la que es realmente difícil averiguar dónde está el flujo principal de ejecución. Las aplicaciones de redes neuronales pueden exhibir esto, pero ese es el punto. Un ejemplo más mundano sería el código UI que está muy orientado a los eventos, pero de nuevo, es difícil ir por la borda con eso; en todo caso, la mayoría del código UI no está orientado al evento suficiente.

8

Diría que es bastante obvio que el código Ravioli y el código de Lasagna son términos peyorativos, colocados intencionalmente junto a su compañero pasta simile 'spaghetti code', y ambos términos describen antipatrones del mundo real. Cierto código requiere mucho tiempo para mantenerse y es muy propenso a fallas simplemente porque se divide en tantos subprocesos separados, es decir, código de raviolis. Algunos códigos tienen tantas capas de abstracción que se vuelve muy difícil implementar un cambio y/o comprender a qué nivel está ocurriendo una falla, es decir, el código de lasaña. La única forma práctica de hacer un cambio en el código de lasaña es simplemente omitir las capas y escribir el código directo que hace el trabajo. Tengo que mantener algún código de ravioles, pero en general tal código sufre de su convolución y no puede encontrar un uso generalizado, por lo que hay algunos ejemplos de que todos estaríamos familiarizados. Por el contrario, el código de lasaña está en todas partes en este momento. Me gusta pensar que no escribo ningún código de pasta, pero al menos puedes seguir una cadena de espaguetis ...

+1

más uno para "pero al menos puedes seguir una cadena de espagueti". – fhogberg

3

El problema es que diferentes personas usan el término "código de ravioles" para significar cosas diferentes.

Un número razonable de componentes razonablemente pequeños es bueno. Una enorme pila de pequeños componentes sin una estructura general aparente no es tan buena.

Los componentes ligeramente acoplados son buenos. Los componentes que ocultan sus interdependencias para parecer vagamente combinados no son tan buenos.

Ser capaz de ver la relación entre los diferentes componentes es realmente una buena cosa.

La mayoría de las bases de código tienen el problema opuesto, por lo que moverse hacia una mayor modularidad suele ser algo bueno. Espero que la mayoría de la gente nunca haya visto el "código de ravioles" en el mal sentido. En la práctica, tiende a parecerse más a ravioles picados (donde lo que debería ser un módulo se divide en múltiples "módulos", ninguno de los cuales tiene sentido por sí solo, pero solo en combinación con sus otras partes correspondientes), o como raviolis cocinado sin suficiente agua (por lo que terminas con una gran cantidad de "módulos").

TODO: Escriba un programa "Hello world" como ~ 100 módulos para demostrar la sobremodularidad.

TODO2: Intento construir un puente con cargas de camión de ravioles para demostrar características estructurales subóptimas.

Cuestiones relacionadas