2010-01-12 6 views
25

Recentemente ho trovato un termine 'God object' che è stato descritto come un 'anti-pattern'. Avevo sentito parlare di cattive pratiche di programmazione, ma non le avevo mai sentite descritte così.Codice ravioli - perché un anti-pattern?

Così ho diretti a Wikipedia per saperne di più, e ho trovato che ci sia un anti-modello chiamato 'Ravioli code' che viene descritta come "caratterizzata da una serie di piccoli e (idealmente) componenti software loosely-coupled."

Sono perplesso - perché questa è una brutta cosa?

+3

chi ha detto che era una cattiva pratica? Loose-coupling è una buona cosa. – jldupont

+35

Il mio codice non è fragile, è "al dente" :) – RedFilter

+0

@jldupont, non penso che sia una brutta cosa. Tuttavia, nell'articolo di wikipedia su "God Object" è elencato come opposto * anti-pattern * –

risposta

25

Spaghhetti:

codice spaghetti è un termine peggiorativo codice sorgente

ravioli:

codice ravioli è un tipo di computer struttura del programma, caratterizzato da un numero di piccolo e (idealmente) componenti software allentati. Il termine è confrontato con con codice spaghetti, confronto con il programma struttura per pasta;

Sono loro a confronto. Non sta dicendo che è un anti-modello.

Ma sono d'accordo. L'articolo è confuso. Il problema non è con l'analogia dei ravioli ma con la struttura dell'articolo di wikipedia stessa. Comincia a chiamare Spaghetti come una cattiva pratica, quindi dice alcuni esempi e dopo di che dire qualcosa sul codice Ravioli.

EDIT: hanno migliorato l'articolo. È un anti-modello perché

Mentre generalmente desiderabile dal punto di vista di accoppiamento e coesione, separazione overzealous e l'incapsulamento del codice può gonfiare gli stack di chiamate e rendere la navigazione attraverso il codice per scopi di manutenzione più difficili.

+3

Hmm, se "codice dei ravioli" non è un anti-pattern, allora qual è il termine _pejorativo_ per un codebase che è suddiviso in così tante classi individuali che nessuno può capire cosa fa il sistema? Perché stavo usando "codice ravioli" per quello. – Trejkaz

+3

@Trejkaz Ho letto l'articolo dopo 5 anni di questa risposta ed è molto meglio. "Sebbene generalmente desiderabile da una prospettiva di accoppiamento e coesione, ** la separazione eccessivamente solerte ** e l'incapsulamento del codice possono gonfiare gli stack e rendere più difficile la navigazione attraverso il codice per scopi di manutenzione". – GmonC

+1

Raccomando questo post di Zed Shaw, offre un'ottima prospettiva sul problema del disaccoppiamento eccessivo: http://zedshaw.com/archive/indirection-is-not-abstraction/ .. Forse potremmo dire che non dovresti t riempirti fino all'orlo di ravioli o ti sentirai male dopo. –

3

Non è necessariamente, vero? L'articolo di Wikipedia non lo descrive come male. Un certo numero di componenti software liberamente accoppiati, in cui la dimensione e il numero di questi componenti è ragionevole in relazione al dominio del problema, mi sembra piuttosto ideale.

Infatti, se si cercano altre definizioni di codice ravioli, lo si troverà descritto come il modello di progettazione software ideale: preferisco ancora l'avvertenza che le dimensioni e il numero devono essere appropriati.

2

Leggere l'articolo, Spaghetti è un anti-pattern; ma i ravioli e le lasagne non sono anti-pattern.

+1

Grazie. Stavo bene leggendo solo Spaghetti e Ravioli, ma ora che hai elencato tre di fila, ho fame. Mi chiedo se il codice Penne sia così da poter vedere. – OregonGhost

+1

@OregonGhost - Il pattern "penne" potrebbe essere codice "pipe": http://www.eaipatterns.com/PipesAndFilters.html – ChrisW

13

È elencato nella pagina del codice Spaghetti ma ciò non significa che sia una brutta cosa. È lì perché questo è un termine rilevante e non abbastanza importante da avere una sua pagina.

Per quanto riguarda il lato cattivo di esso, usare Google dà un commento in http://developers.slashdot.org/comments.pl?sid=236721&cid=19330355:

Il problema è che si tende a portare a funzioni (metodi, ecc) senza vera coerenza, e spesso lascia il codice implementare anche qualcosa di abbastanza semplice sparpagliato su un numero molto grande di funzioni. Chiunque debba mantenere il codice deve capire come tutte le chiamate tra tutti i bit funzionano, ricreando quasi tutta la cattiveria di Spaghetti Code tranne che con le chiamate di funzione al posto di GOTO. ...

Devi giudicare se è ragionevole :).

4

Se si applica una regola dogmatica che tutte le classi in tutti i progetti devono essere accoppiate liberamente indipendentemente da qualsiasi motivo, allora posso vedere che ci sono molti potenziali problemi.

Si potrebbe girare le ruote cercando di realizzare un'applicazione perfettamente sottile sempre più accoppiata senza mai aggiungere alcun valore.

Mi affretto ad aggiungere, però, che penso che tutti noi dovremmo puntare classi loosely coupled, componenti, ecc

6

Praticamente il "codice di ravioli" unica ragione è sopravvissuto come una frase è perché i programmatori hanno un innato senso dell'umorismo. Prova come potrei - e credimi, ci ho provato - è davvero difficile trovare un esempio di codice orientato agli oggetti che sia stato (a) impacchettato in modo tale che fosse davvero difficile navigare nello stesso senso-meta che " codice spaghetti "è difficile da navigare e (b) riflette un frequente anti-pattern nella pratica del codice.

Il miglior esempio di "codice ravioli" che posso inventare è una moltitudine di classi, ciascuna strettamente impacchettata, ma dove è davvero difficile scavare dove è il flusso principale dell'esecuzione. Le applicazioni di rete neurale potrebbero esibire questo, ma questo è un po 'il punto. Un esempio più banale sarebbe il codice dell'interfaccia utente che è molto fortemente orientato agli eventi, ma, ancora una volta, è difficile esagerare con questo - semmai, la maggior parte del codice UI non è guidata dagli eventi sufficiente.

8

Direi che è abbastanza ovvio che il codice Ravioli e il codice di Lasagna sono entrambi termini peggiorativi - essendo messi intenzionalmente accanto al loro simile "spaghetti code" della pasta - ed entrambi i termini descrivono gli anti-modelli del mondo reale. Alcuni codici richiedono molto tempo per essere mantenuti e molto inclini al fallimento semplicemente perché sono suddivisi in così tanti sottoprocessi separati, ovvero il codice dei ravioli. Alcuni codici hanno così tanti livelli di astrazione che diventa molto difficile implementare una modifica ad esso e/o capire a quale livello si verifica un errore - questo è il codice lasagna. L'unico modo pratico per apportare una modifica al codice lasagna è spesso quello di bypassare semplicemente gli strati e scrivere il codice semplice che fa il lavoro. Devo mantenere qualche codice per i ravioli, ma in generale tale codice soffre della sua convoluzione e non riesce a trovare un uso diffuso, quindi ci sono alcuni esempi di ciò che avremmo tutti avuto familiarità con. Al contrario, il codice lasagna è ovunque in questo momento. Mi piace pensare di non scrivere alcun codice pasta, ma almeno puoi seguire una serie di spaghetti ...

+1

più uno per "ma puoi almeno seguire una stringa di spaghetti". – fhogberg

3

Il problema è che persone diverse usano il termine "codice dei ravioli" per indicare cose diverse.

Un numero ragionevole di componenti ragionevolmente piccoli è buono. Un mucchio enorme di minuscoli componenti senza una struttura complessiva apparente non è così buono.

I componenti con accoppiamento lento sono buoni. I componenti che nascondono le loro interdipendenze per apparire vagamente accoppiati non sono così buoni.

Essere in grado di vedere la relazione tra diversi componenti è in realtà una buona cosa.

La maggior parte delle basi di codice presenta il problema opposto, quindi spostarsi verso una maggiore modularità di solito è una buona cosa. Mi aspetto che la maggior parte della gente non abbia mai visto "codice dei ravioli" in senso negativo. In pratica, tende ad assomigliare più a ravioli tritati (dove quello che dovrebbe essere un modulo è diviso in più "moduli" - nessuno dei quali ha senso da solo, ma solo in combinazione con le corrispondenti altre parti), o come i ravioli cucinato senza abbastanza acqua (così si finisce con un gigantesco blob di "moduli" tutti incollati insieme).

TODO: Scrivere un programma "Hello world" come ~ 100 moduli per dimostrare la sovramodularità.

TODO2: Tentativo di costruire un ponte con camion carichi di ravioli per dimostrare caratteristiche strutturali subottimali.

Problemi correlati