I modelli di progettazione sono generalmente una forza per il bene o il male? [chiuso]

Ho sentito dire che i motivi di design sono la cosa migliore dopo il pane a fette. Ho anche sentito dire che i modelli di progettazione tendono ad esacerbare la "Sindrome del secondo sistema", che sono ampiamente abusati e che fanno pensare ai loro utenti di essere designer migliori di quanto non siano in realtà.

Tendo ad avvicinarmi all'ex campo, ma recentemente ho visto progetti in cui quasi ogni singola interazione è sostituita da una relazione di osservatore e tutto è un singleton.

Quindi, considerando i vantaggi e i problemi, i modelli di progettazione sono generalmente buoni o cattivi, e perché?

I modelli di progettazione sono una lingua , non un consiglio per scrivere un programma o un contratto. Il loro uso principale è una spiegazione a posteriori di come un componente o un sistema è stato (o sta per essere) implementato. Invece di entrare in troppi dettagli, puoi solo dire un paio di parole che possono descrivere l'implementazione abbastanza bene da consentire all'ascoltatore di capire come funziona e cosa era importante in essa.

Alex: Ehi, come vengono creati i file di configurazione?

Bob: Sono generati da una fabbrica, che risiede in config.h.

Ora Alex sa che la creazione di file di configurazione comporta preparazioni non banali, perché altrimenti la loro creazione non sarebbe racchiusa in una fabbrica.

Tuttavia, se Bob era un falso testardo e usava solo schemi qua e là, Alex non poteva dire nulla sulla creazione della configurazione, perché Bob usava la fabbrica ovunque. Ciò porterebbe anche a un'eccessiva complessità nel programma.

Quindi, programmare prima, quindi individuare i pattern nel codice, non viceversa. Ecco come vengono effettivamente utilizzati.

I modelli di design sono fantastici . Se usati correttamente, rendono il codice più gestibile, più facile da leggere e utilizzare. Parte dell'essere un buon programmatore è sapere quando fermarsi e vedere che qualsiasi ulteriore refactoring supererà i benefici. Usare i modelli di progettazione da soli non rende qualcuno un buon programmatore, ma sapere quando e dove usarli lo fa. Proprio come qualsiasi altra cosa in questo mondo, i modelli di design possono essere portati all'estremo e abusati. So che sto ancora cercando (e lo vorrò per molto tempo) il perfetto equilibrio nel mio codice in cui ogni modello di disegno ha uno scopo e si adatta perfettamente come un pezzo di puzzle.

I motivi di design sono fantastici, se usati correttamente.

È utile ricordare che l'idea di modelli di design è nata nell'architettura. L'architettura può variare selvaggiamente. Tuttavia, ci sono molte idee fondamentali che sono presenti in qualsiasi edificio. In questo modo, pensa ai modelli come elementi costitutivi del design. È importante notare che non tutti gli edifici includono tutti i possibili modelli architettonici.

Di 'che stai progettando una casa. Piuttosto che avere la porta aperta sulla strada, si desidera un'area protetta prima di entrare nella casa, cioè un'anticamera. Questa area si adatterà a un determinato modello. Vale a dire, avrà due ingressi, alcuni muri e probabilmente un tetto. Nota, il modello non specifica porte, finestre o quante pareti. Nella maggior parte delle implementazioni, ci saranno due porte, quattro pareti e forse finestre. Tuttavia, il modello descrive un'area chiusa con due ingressi. Uno conduce nella stessa anticamera dall'esterno della casa e l'altro conduce nel resto della casa. La chiave qui, è che se si desidera un'anticamera è necessario racchiudere un'area e fornire due ingressi in quell'area.

I problemi tipici con i modelli di progettazione nella programmazione sono l'uso eccessivo e la convinzione che si tratti di proiettili d'argento per risolvere qualsiasi problema. Non sono. Sono modi di comunicare e pensare a idee di programmazione utili. Se i bit di sintassi di un particolare linguaggio sono i mattoni e il mortaio, i modelli descrivono modi utili per disporli per soddisfare determinate esigenze.

Considero gli schemi di progettazione più " consigli " che un contratto immutabile che deve assolutamente essere seguito. Perché? Proprio per il motivo che hai citato. Seguire un modello di progettazione in ogni cosa porta a un grande casino di codice che sconfigge lo scopo di utilizzare un modello in primo luogo.

Questo è il motivo per cui odio i siti come Java Practices . Certo alcune delle idee sono buone, ma poi l'autore ha deciso di scrivere un intero programma (più un framework) seguendo ogni singolo modello di design che ha menzionato. L'autore ha anche scritto ogni articolo con grandi citazioni spaventose facendo pensare al lettore che le pratiche java attuali siano orribili e che dovrebbero essere evitate come la peste.

TL; DR: usa schemi di design. Basta non abusarli

Seet anche questo thread su SO. Da un altro POV i modelli di progettazione sono il codice del boilerplate per compensare le carenze della metodologia utilizzata. Non sono un fan di celebrare troppo quelle soluzioni alternative.

Preferirò quelli nel mezzo. Come ha giustamente sottolineato il poster, la comprensione dei modelli non ti rende un buon sviluppatore. D'altra parte, una comprensione del modello ti aiuterà a diventare un buon sviluppatore.

Comprendere la relazione tra i modelli e vedere un modello in un progetto (durante la fase di concepimento) è ciò che ti renderà un buon sviluppatore.

Si dice spesso che i modelli di progettazione forniscono una soluzione pronta per i problemi di programmazione. Che tipo di problemi sono? "Come posso cambiare il comportamento degli oggetti, ma isolare le modifiche dal resto del sistema?"

I modelli GoF sono riconosciuti per aver fornito quell'isolamento (incapsulamento) dal resto del sistema, ma spesso è difficile sapere a quale parte del sistema viene data la variabilità attraverso l'uso dei loro modelli di progettazione. Invece di seguire lo schema di classificazione che hanno proposto (creazionale, comportamentale e strutturale), ho tracciato le differenze dei modelli e ho escogitato altri due schemi per classificarne i modelli: ciclo di vita e gerarchia di incapsulamento dei componenti.

Come puoi vedere da questa tabella per la gerarchia dell'incapsulamento, i modelli di progettazione possono essere applicati ad ogni livello di un componente. Ma avrebbe senso? Il componente dovrà fornire una variazione comportamentale al livello di incapsulamento proposto e verrà utilizzato lo schema adeguato per quel livello? Se queste domande non ricevono una risposta adeguata, è molto probabile che i modelli di progettazione vengano applicati erroneamente. Solo perché un perno verticale potrebbe essere incorporato nella cabina di un'auto non lo rende un'idea intelligente.

Utilizzando un'analogia con il denaro, un modello di progettazione dovrebbe essere considerato come una soluzione con costi di capitale elevati ma costi operativi bassi. I modelli di progettazione costano una fortuna in anticipo in termini di codifica aggiuntiva, verbosità e peso concettuale a causa dell'ulteriore riferimento indiretto che creano. Hanno anche la tendenza a bloccare altri aspetti del tuo design. Ad esempio, l'uso del metodo template ti costringe a programmare in uno stile OO pesante.

Tuttavia, se è necessario risolvere molti problemi strettamente correlati che variano in alcuni piccoli modi o in futuro sarà sicuramente necessario modificare pesantemente un pezzo di codice in alcuni modi specifici, i costi iniziali possono valerne la pena perché il design i pattern aggiungono flessibilità al tuo codice. Le modifiche o la soluzione alla seconda serie di problemi strettamente correlati saranno molto più semplici con i modelli che senza.

Entrambi i campi sono corretti: sono una forza per il bene se usati correttamente, una forza per il male se sono schizzati dappertutto.

I modelli di progettazione possono avere un talento nel trascinarti, ma lo stesso vale per la codifica in generale. È facile lasciarsi sedurre scrivendo la cassetta degli attrezzi definitiva: devi solo tenere a mente YAGNI per impedirti di essere trascinato fuori rotta, avere un'idea della struttura richiesta dall'applicazione. IMO questo dipende solo dall'individuo e dal segno della loro esperienza / giudizio.

Penso ai dati di progettazione non a qualcosa che stai costantemente cercando di applicare al tuo codice. Per me si tratta principalmente di un linguaggio comune per gli sviluppatori. È più facile dire "seguiamo un modello di costruttore" piuttosto che spiegare il tutto ancora e ancora.

Attualmente sto rileggendo Patterns Of Enterprise Application Architecture in questo momento, perché mi imbatto in un sacco di codice che segue uno dei pattern di quel libro. Non penso che sia stato scelto intenzionalmente di seguire uno dei modelli, ma aiuta sicuramente se si può dire " è uno script di transazione " e tutti hanno una chiara comprensione di ciò che significa.

Ma mi piace l'idea che puoi scegliere da un catalogo preparato di modelli, quando progetti una nuova funzionalità o un'applicazione nuova di zecca. Perché reinventare tutto se esistono soluzioni comprovate per determinati problemi?