AntFarm anti-pattern - strategie da evitare, antidoti per aiutare a guarire da

Question

Sto lavorando su un sito web di 10 pagine con un database back-end. Ci sono oltre 500 oggetti in uso, che cercano di implementare il pattern MVP in ASP.Net. Sto tracciando l'esecuzione del codice da una pagina singola, il mio dito è stato su F-11 in Visual Studio per circa 40 minuti, sembra non esserci nessuna fine, forse più di 1000 chiamate di metodo per una pagina web! Se fossero solo 50 oggetti che sarebbero una cosa, tuttavia, l'esecuzione di codice serpeggia attraverso tutti questi oggetti proprio come milioni di formiche che si aggirano freneticamente nella loro gigantesca casa di terrapieno, piena di tunnel di oggetti. Quindi, è nato un nuovo anti-modello: AntFarm.

AntFarm è anche noto come "OO-Madnes", "OO-Fever", OO-ADD, o semplicemente un drogato di design-pattern.

Questa non è la prima volta che ho visto questo, né i miei colleghi in altre società. Sembra che questo stile sia attivamente propagandato, o comunque sia un fraintendimento dei numerosi vangeli OO/DP che vanno in giro ...

Vorrei introdurre un anti-pattern all'anti-pattern: GST oppure "Get Stuff Done" AKA "Get Sh ** done" AKA GRD (GetRDone). Questo schema si concentrava su ciò che dice, facendo cose fatte, in un modo semplice. Potrei provare a delinearlo di più in un post successivo, o per favore condividi le tue idee su questo schema antidoto.

In ogni caso, sono nel mezzo di un grande esempio di anti-pattern AntFarm mentre scrivo (come bonus, non c'è documentazione o commenti). Per favore condividi i tuoi pensieri su come questo anti-pattern sia diventato così prevelente, come possiamo evitarlo e come puoi annullare o gestire questo schema in un sistema live con cui devi lavorare!

Answer 1

Penso che Parnas lo abbia praticamente inchiodato in On the Criteria to be used in Decomposing Systems into Modules. Ogni modulo dovrebbe nascondere una decisione di progettazione, che potrebbe cambiare in futuro. In generale, un modulo con nulla da nascondere è in genere solo un sovraccarico. Non stava parlando esattamente delle classi, ma penso che il ragionamento si applichi ancora.

Answer 2

Grazie Glomek l'articolo è per un interessante spazio-problema, andando al nocciolo di ciò che è OO, cioè come progettare i tuoi oggetti ... per il successo o il fallimento, grazie per il link.

Oh sì, il design anti-pattern potrebbe essere chiamato "Ant Hill", questa è una descrizione più chiara, credo. Credo che al momento sia abbastanza prevalente, e sembra che stia crescendo ... Mi sto ancora chiedendo come possiamo evitarlo in generale, e scrivere un codice più semplice e chiaro che porti a termine il lavoro con la minima complessità necessaria .

Answer 3

Se è è effettivamente dovuto a un eccesso di progettazione (e suona come esso) allora qui ci sono alcuni sinonimi per voi:

Gas Factory
Rube Goldberg macchina
Heath Robinson aggeggio

ma il mio nome personale per questo "provando anche F # $% 3n difficile". Le mie condoglianze.

Acclamazioni Adrian

Answer 4

molti file in cui si farebbe. Cattiva. 500 oggetti per 10 pagine web sembrano un pazzo rapporto. Hai considerato l'analisi del codice in esecuzione sulla soluzione? Potrebbe darti alcune statistiche interessanti con cui combattere.

Anche io chiamerei il KISS anti-anti-pattern.

Answer 5

Il problema qui è che il modello di progettazione è, di per sé, non OO. Inizia con un modello non OO, prova a implementarlo come "oggetti", finisci con un casino.

Solo perché il sistema è scritto in un OOPL non rende il sistema OO.

Answer 6

Se si considera che una formicaio è un modo efficace per esplorare uno spazio problematico complesso (la formica) attraverso l'uso di agenti semplici (le formiche), allora questo inizia ad apparire decisamente meno anti-patternish.

Le critiche di OOP basate sulla complessità di "adattarlo tutto nella tua testa" ignorano sempre che (a) è difficile adattarsi a qualsiasi cosa nella tua testa (indipendentemente dal fatto che sia OO o meno) e (b) che OO riduce attivamente la necessità di avere tutto nella tua testa comunque