design patterns - software - Modelli di design usati male




singleton (10)

Ci sono, nella lista canonica di Gang of Four, tutti gli schemi di progettazione che spesso si trovano abusati, fraintesi o sovrautilizzati (oltre al Singleton molto discusso)? In altre parole, c'è un modello di progettazione che consiglieresti di pensarci due volte prima di usarlo? (E perché?)


Il modello singleton .. lo stato globale spesso causa problemi durante il test

Qualsiasi codice a seconda del singleton diventa sempre più difficile da testare perché quella dipendenza non viene facilmente derisa ..


Il pattern di osservatore è piuttosto inutile in C # perché ha eventi.


Quello che vedo è il pattern singleton in cui non viene applicata abbastanza attenzione e dilligence su come e quando chiamare il distruttore di un singleton.

Per un modello così onnipresente non c'è quasi nessuna discussione sul processo corretto per decidere quando un singleton deve morire.

Solo il mio 0.02.

Saluti,

rapinare


In realtà, direi che i modelli di design in generale sono abusati quando un KISS ( Keep It Simple, Stupid Mantenerlo breve e semplice) la soluzione è tutto ciò che è necessario.

I modelli di progettazione sono ottimi per rendere flessibile un sistema, ma a costo di rendere l'implementazione più complessa. Questo è solo un utile compromesso quando la flessibilità fornirà un vantaggio pratico.


TUTTI.

Non prendermi in errore qui, trovo che siano un'ottima base e, se ben compresi, sono molto utili. Ci vuole così tanto per acquisire le capacità progettuali per sapere bene quando e come applicarle nel codice. In realtà, questo è il caso generale per le competenze per creare codice pulito.

Non si tratta di non usare quindi, è esattamente quello che hai detto nella domanda "pensaci due volte prima di usare". Comprendi bene cosa stai facendo e perché. Se non lo fai, parla con qualcuno che ti può insegnare su questo - oltre a leggere molto. Fai attenzione a quelli che conoscono tutti gli schemi, ma non riescono a spiegarti chiaramente il / i perché / ciascuno di essi, specialmente di quello in questione.


Volevo solo aggiungere un altro commento dopo aver visto alcune delle risposte "Tutti i modelli sono cattivi".

Se sei un programmatore mezzo decente che lavora su problemi moderatamente impegnativi, quasi tutti i motivi dovrebbero essersi presentati a te in un punto o in un altro come la soluzione "ovvia" a un problema.

L'unico vero punto del libro Design Patterns era quello di mettere i nomi su ciò che tutti noi facciamo ogni giorno in modo da poter comunicare meglio.

Suppongo che se sei un programmatore nuovo, sarebbe molto utile leggerle, in modo che il giorno in cui ne hai bisogno non devi capirlo da solo, è già nella tua cassetta degli attrezzi, ma in generale - qualsiasi di questi potrebbe essere capito da una Gang of One (anyOne!).

Se ce n'è qualcuno che non conoscevi già, probabilmente non ne hai mai avuto bisogno.

È piuttosto utile mettere i nomi ai disegni e formalizzarli un po ', però, non mi lamento affatto del libro. Se non vedi il bisogno occasionale di quasi tutti i modelli qui, non stai lavorando su un codice molto difficile (o dupli molto il codice, qualcosa che considero il peccato principale).


Usa solo un modello quando è richiesto. Non è possibile prevedere il futuro, quindi mentre si potrebbe inserire uno schema per rendere flessibile il design, cosa succede quando il prodotto prende una direzione diversa e il modello diventa la cosa che ti impedisce di implementare ciò che vogliono gli utenti?

Mantieni i progetti il ​​più semplice possibile per iniziare. Quando sai di più su come il tuo progetto deve cambiare, usa il modello appropriato e non prima.


MODELLO DI RIPOSO

La maggior parte delle persone inizia a utilizzare questo modello subito dopo aver letto il libro Domain Driven Design di Eric Evans.

Quante persone hanno visto i repository costruiti come oggetti di accesso ai dati?


In realtà, quello che vedo più spesso è la mancanza di uso di un modello appropriato. Scenario tipico: io: "Ehi, il modulo A ha già un pezzo di codice che scorre attraverso una serie di oggetti ed esegue l'operazione del database X su di essi, perché non hai riutilizzato quel codice?" programmatore: "bene, ma dovevo fare l'operazione Y su quegli oggetti". io: "che ne dici di usare il refactoring per usare il pattern Command per eseguire X o Y come appropriato?"

Una volta ho visto che l'uso del modello Soggetto-Osservatore sfuggiva di mano. È stato implementato tra i processi che utilizzano il database per archiviare in modo persistente l'oggetto. A causa dell'enorme numero di aggiornamenti sull'argomento e del numero di osservatori, il carico sul database è stato eccezionale e ha provocato un rallentamento imprevisto a livello di sistema.


Il modello di Mediatore ha sicuramente il potenziale per essere usato impropriamente se tutti i tipi di logica vengono inglobati in una grande classe.





anti-patterns