Cos'è la programmazione basata su pattern?

Un modello è un approccio comune per risolvere un tipo comune di problema; niente di più e niente di meno. Conoscendoli e comprendendoli, puoi utilizzare le esperienze di altre persone per guidarti verso il tipo di soluzione che ha dimostrato di funzionare bene, evitare le insidie che sono state incontrate in passato e discutere la soluzione utilizzando una terminologia familiare agli altri che conosci quel modello.

Ovviamente, puoi trovare una soluzione soddisfacente senza utilizzare esplicitamente un pattern, e ugualmente bene trovare una soluzione sbagliata provando ad applicare un pattern che non si adatta veramente al tuo particolare problema. Penso che l'ossessione che osservi provenga generalmente da persone che hanno appena scoperto il concetto e pensano che sia piuttosto più potente di quanto sia in realtà. La maggior parte delle persone li riconoscerà rapidamente per quello che sono: uno strumento utile, non una bacchetta magica.

Gli anti-pattern, d'altra parte, sono comportamenti comunemente osservati che tendono a ridurre la qualità del codice. Ancora una volta, è utile conoscerli e comprenderne alcuni in modo da evitare questo comportamento e provare a correggerlo (con argomenti ragionati) quando lo osservi in altri. Alcuni descrivono l'uso eccessivo dei pattern come anti-pattern.

I pattern sono sia la conoscenza distillata dei programmatori in un libro di cucina, sia un modo utile per comunicare con i programmatori.

Come suggeriscono altre risposte, i modelli sono in realtà soluzioni comuni a problemi comuni. Il vantaggio è che spesso puoi ottenere soluzioni migliori utilizzando uno schema esistente o scoprire probabili insidie prima di iniziare la codifica.

L'altro vantaggio è quando parli con qualcuno del tuo codice. I pattern sono un altro tipo di gergo che condensa lunghe descrizioni in poche parole. Prova a spiegare "allora abbiamo un osservatore aggiunto dalla fabbrica" senza fare riferimento ai modelli. Puoi farlo, ma ci vuole molto tempo.

La maggior parte degli sviluppatori rabbrividisce a qualsiasi nuovo paradigma o metodologia che viene in. Ho fatto quando ho sentito parlare dei modelli di progettazione. I design pattern sono proprio ciò che suggerisce il nome: un design o un modello per creare classi e modellarne il comportamento e l'interazione in modo prevedibile

Dai un'occhiata alle case. Hanno alcune somiglianze. Ogni casa ha un soggiorno, cucina, camera da letto, bagno, servizi igienici per un minimo. Nessuno costruirà una casa senza un bagno, giusto? Gli appartamenti hanno uno schema diverso da quello dei bunglows. I castelli hanno un modello completamente diverso. Anche gli abiti hanno motivi. Una giacca e una camicia formale hanno entrambi lo stesso design di base, ma hanno comportamenti diversi: non indosserai una giacca da cowboy per un'intervista. Allo stesso modo le classi e le loro azioni possono essere raggruppate in base al loro comportamento e design. Guardare gli elementi comuni nei loro comportamenti ti dà modelli di progettazione per le classi.

I modelli di progettazione a mio avviso sono importanti solo se la riusabilità e l'espandibilità sono problemi primari. Se crei piccole app (diciamo meno di 10 classi), potresti non averne affatto bisogno. Ma i progetti di grandi dimensioni, in particolare quelli che hanno grandi team che lavorano su di essi e che richiedono lunghi cicli di manutenzione e aggiunta, avranno sicuramente bisogno di schemi. Non è nemmeno un'opzione in grandi progetti.

Dai un'occhiata ad alcuni tutorial online sui pattern. Wikipedia ha una buona serie di articoli. Anche questo sito è buono: link . Se sei un programmatore esperto, scoprirai che hai trovato alcuni modelli, forse hai implementato anche qualcosa di simile senza saperlo con un nome particolare.

Non ignorarli del tutto! Potresti trovarli utili in futuro se non ora. La chiave per affrontare i modelli di progettazione con una mente aperta è chiedere: "Che cosa accadrà se non utilizzo i pattern di progettazione?" I modelli non sono intesi come "cure" (sebbene tu possa usarli come cura per un problema); piuttosto, incarnano il detto "prevenire è meglio che curare".

Comunque, vorrei mettere in guardia contro l'ossessione di implementare i pattern ovunque e ogni volta che vedi un piccolo pretesto per usarlo. Ho affrontato questo problema in un progetto in cui l'architetto era convinto che senza DP il progetto sarebbe stato un disastro completo. Abbiamo avuto una riunione di gruppo in cui gli ingegneri hanno spostato il progetto e indicato che molti modelli che ha raccomandato non avrebbero avuto alcun senso se non mostrare "wow guarda i bellissimi modelli". Ci sono volute molte convincenti e alcune contrattazioni per ridurre il numero di luoghi in cui i modelli sono stati utilizzati in base al bisogno.

Le persone che hanno risposto sono corrette in termini di "programmazione basata su pattern" come normalmente si pensa. Ho una definizione leggermente diversa che trovo più rilevante per ciò che sto facendo e tendo ad usare "programmazione basata su pattern" per descrivere un approccio plugin piuttosto che un approccio di pianificazione.

Poiché programma i plug-in jQuery, un plug-in per il cloud CMS e i plug-in di eCommerce, la "programmazione basata su pattern" da tale prospettiva significa esaminare la tecnologia di base e quali casi d'uso esistono e colpire quelli più rilevanti dal punto di vista statistico. I plug-in, in particolare, devono essere molto basati su pattern, quindi si adattano bene al contesto di programmazione.

Tuttavia, è meglio applicare un pattern dopo aver visto casi d'uso validi su più progetti, quindi è statisticamente valido per il riutilizzo.