Cos'è la programmazione basata su schemi?

Qualcuno può spiegare l'ossessione per gli schemi e gli anti-schemi nella programmazione? Lo chiedo perché non ho assolutamente idea di cosa significhino gli schemi. Di fronte a un compito di programmazione, penso al problema per un po ', scrivo alcune strutture di dati che ritengo rilevanti, prototipa una soluzione, separa alcuni moduli e ripeti. In nessun punto del processo penso "Oh, ho bisogno del modello FunkyLookyTastic qui".

Un modello è un approccio comune per risolvere un tipo comune di problema; niente di più e niente di meno. Conoscendoli e capendoli, puoi fare uso delle esperienze di altre persone per guidarti verso il tipo di soluzione che ha dimostrato di funzionare bene, evitare insidie ​​che sono state incontrate in passato e discutere la soluzione usando una terminologia familiare ad altri che conoscere quel modello.

Ovviamente, puoi trovare una buona soluzione senza usare esplicitamente un modello e ugualmente bene trovare una soluzione sbagliata provando ad applicare un modello che non si adatta davvero al tuo particolare problema. Penso che l '"ossessione" che osservi generalmente provenga da persone che hanno appena scoperto il concetto e penso che sia piuttosto più potente di quanto non sia in realtà. Molte persone li riconosceranno rapidamente per quello che sono: uno strumento utile, non un proiettile magico.

Gli anti-pattern, d'altra parte, sono comportamenti comunemente osservati che tendono a ridurre la qualità del codice. Ancora una volta, è utile conoscere e comprendere alcuni di questi in modo da poter evitare tale comportamento e provare a correggerlo (con argomenti ragionati) quando lo si osserva in altri. Alcuni descrivono l'uso eccessivo di modelli come anti-modello.

I pattern sono sia la conoscenza distillata dei programmatori di 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 è possibile ottenere soluzioni migliori utilizzando uno schema esistente o scoprire probabili insidie ​​prima di iniziare a scrivere codice.

L'altro vantaggio è quando parli con qualcuno del tuo codice. I pattern sono un altro tipo di gergo che condensano 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 si arrabbierà con qualsiasi nuovo paradigma o metodologia che arriva. L'ho fatto quando ho sentito parlare per la prima volta dei modelli di progettazione. I modelli di design sono proprio ciò che suggerisce il nome: un design o modello per la creazione di classi e la modellazione del loro comportamento e interazione in modo prevedibile

Dai un'occhiata alle case. Hanno alcune somiglianze. Ogni casa ha un soggiorno, cucina, camera da letto, bagno, toilette per un minimo. Nessuno costruirà una casa senza bagno, giusto? Gli appartamenti hanno uno schema diverso dai bunglows. I castelli hanno un modello completamente diverso. Anche i vestiti hanno motivi. Una giacca e una camicia formale hanno entrambe 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à schemi di progettazione per le classi.

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

Dai un'occhiata ad alcuni tutorial online sugli schemi. Wikipedia ha una buona serie di articoli. Anche questo sito è buono: http://sourcemaking.com/ . Se sei un programmatore esperto, scoprirai di esserti imbattuto in alcuni schemi, magari anche implementando qualcosa di simile te stesso senza saperlo con un nome particolare.

Non ignorarli del tutto! Potresti trovarli utili in futuro, se non ora. La chiave per avvicinarsi ai modelli di progettazione con una mente aperta è chiedere: "Cosa accadrà se non uso schemi di progettazione?" I pattern non sono intesi come "cure" (anche se puoi usarli come cura per un problema); piuttosto, incarnano il detto "prevenire è meglio che curare".

Tuttavia, vorrei mettere in guardia contro l'ossessione di implementare schemi 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 hanno sottolineato che molti modelli che lui ha raccomandato non avrebbero avuto alcun vantaggio se non quello di mostrare "wow guarda i bellissimi modelli". Ci sono voluti molti convincenti e un po 'di contrattazione per ridurre il numero di luoghi in cui i modelli sono stati usati solo per necessità.

Le persone che hanno risposto hanno ragione in termini di "programmazione basata su schemi" come normalmente viene pensata. Ho una definizione leggermente diversa che trovo più pertinente a ciò che sto facendo e tendo ad usare la "programmazione basata su schemi" per descrivere un approccio plug-in piuttosto che un approccio di pianificazione.

Da quando programma i plug-in jQuery, un plug-in cloud CMS e plug-in eCommerce, "programmazione basata su schemi" da quella prospettiva significa esaminare la tecnologia di base e quali casi d'uso esistono e colpire quelli più statisticamente rilevanti. I plug-in, in particolare, devono essere molto basati su schemi in modo da adattarsi bene al contesto di programmazione.

Tuttavia, è meglio applicare un modello DOPO che vedi casi d'uso validi su più progetti, quindi è statisticamente valido per il riutilizzo.