Gli schemi di progettazione sono generalmente una forza positiva o negativa? [chiuso]

I pattern di progettazione sono una lingua , non consigli per scrivere un programma o un contratto. Il loro uso principale è una spiegazione a posteriori su come un componente o un sistema era (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 permettere all'ascoltatore di capire come funziona e cosa è importante in esso.

Alex: Hey, how are the config files created?

Bob: They're generated by a factory, which resides in config.h.

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

Tuttavia, se Bob era un fasullo dai capelli truccati, e ha semplicemente usato i disegni qua e là, Alex non poteva dire nulla sulla creazione della configurazione, perché Bob usava la fabbrica ovunque. Ciò comporterebbe anche un'eccessiva complessità del programma.

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

I modelli di design sono fantastici . Se utilizzati correttamente, rendono il codice più gestibile, più facile da leggere e con cui lavorare. Parte dell'essere un buon programmatore è sapere quando fermarsi e vedere che ogni ulteriore refactoring supererà i benefici. Utilizzare solo schemi di progettazione non rende qualcuno un buon programmatore, ma sapere quando e dove utilizzarli. Proprio come con qualsiasi altra cosa in questo mondo, i modelli di design possono essere portati all'estremo e subire abusi. So che sto ancora guardando (e lo sarà per molto tempo) per quel perfetto equilibrio nel mio codice in cui ogni schema di progettazione ha uno scopo e si adatta perfettamente come un pezzo di puzzle.

I modelli di design sono grandi, se usati correttamente.

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

Dì che stai progettando una casa. Piuttosto che avere la porta d'ingresso aperta sulla strada, vuoi una zona riparata prima di entrare in casa, cioè un'anticamera. Questa area si adatterà a un determinato modello. Vale a dire, avrà due ingressi, alcune pareti e probabilmente un tetto. Nota, il modello non specifica porte, finestre o quanti muri. Nella maggior parte delle implementazioni, ci saranno due porte, quattro muri e forse finestre. Tuttavia, il modello descrive un'area chiusa con due ingressi. Uno conduce nell'anticamera stessa dall'esterno della casa e l'altro conduce nel resto della casa. La chiave qui è che se vuoi un'anticamera devi racchiudere un'area e fornire due ingressi in quella zona.

I tipici problemi con i modelli di progettazione nella programmazione sono sovrautilizzati e la convinzione che siano proiettili d'argento per risolvere qualsiasi problema. Non sono. Sono modi per comunicare e pensare a idee di programmazione utili. Se i bit di sintassi di una determinata lingua sono mattoni e malta, i modelli descrivono modi utili per organizzarli per soddisfare determinati requisiti.

Considero i design pattern più di " advice " di un contratto immodificabile che deve assolutamente essere seguito. Perché? Proprio per la ragione che hai menzionato. Seguire un modello di progettazione in tutto porta a un grande pasticcio di codice che sconfigge lo scopo di utilizzare un modello in primo luogo.

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

TL; DR: Usa schemi di progettazione. Basta non abusare di loro

Inoltre vedi questo thread su SO. Da un altro pattern di progettazione POV sono codice di codice per compensare le carenze della metodologia utilizzata. Non sono un fan di celebrare troppo quegli stratagemmi.

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

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

Penso a Design Patterns non a qualcosa che stai costantemente cercando di applicare al tuo codice. Per me riguarda principalmente un linguaggio comune per gli sviluppatori. È più facile dire "seguiamo un modello di build" piuttosto che spiegare l'intera cosa più e più volte.

Al momento 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 intenzionalmente scelto di seguire uno dei pattern, ma aiuta sicuramente se puoi dire " è uno script di transazione " e tutti hanno una chiara comprensione di cosa significhi.

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

Usando un'analogia con il denaro, un modello di progettazione dovrebbe essere pensato come una soluzione con alti costi di capitale ma bassi costi operativi. I modelli di progettazione costano una fortuna in anticipo in termini di codifica aggiuntiva, verbalità e il peso concettuale derivante dall'ulteriore indiretto che creano. Hanno anche la tendenza a bloccare altri aspetti del tuo design. Ad esempio, l'utilizzo del metodo template ti costringe a programmare in uno stile molto OO.

Tuttavia, se hai bisogno di risolvere molti problemi strettamente correlati che variano in alcuni modi, o hai sicuramente bisogno di modificare pesantemente un pezzo di codice in alcuni modi specifici in futuro, i costi iniziali possono valere perché i pattern di design aggiungono flessibilità al tuo codice. Le modifiche o la soluzione al secondo gruppo di problemi strettamente correlati saranno molto più semplici con i modelli che senza.

Entrambi i campi sono corretti - sono una forza positiva se usati correttamente, una forza negativa se sono schizzati dappertutto.

Gli schemi di progettazione possono avere l'abilità di attirarti, 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 sottratto al percorso, avere un'idea di quanta struttura richieda l'applicazione. IMO questo è solo per l'individuo e un segno della loro esperienza / giudizio.