Discussione:Design Patterns

Affermazioni dubbie

Movimento pattern

« ha dato inizio ad un'intera corrente filosofica della programmazione, non solo ad oggetti: il movimento pattern. »

Non so se si può parlare in questsi termini. Addirittura filosofia? "Movimento" non è un'organizzazione o comunque uno sforzo collettivo organizzato? Riformulare?

Si definiscono così gli stessi iniziatori del movimento, i GoF. è una filosofia di programmazione. vedere sul loro sito. --BW Insultami BWB 14:42, 1 feb 2006 (CET)

Giudizio di merito non neutro

«La conoscenza del concetto di pattern è fortemente raccomandata a chiunque voglia progettare software a livello professionale, [...]»

Esprime un giudizio di merito secondo me eccessivo. Propongo rimozione o sostituzione con qualcosa di più generale e neutro, tipo: «I design pattern sono ormai stabilmente affermati come strumento per la progettazione di software a livello professionale [...]»

...E sono raccomandati dai migliori programmatori del mondo, tra cui gli autori di exceptional c++ e di c++ guru of the week, Bruce Eckel, Bjarne Stroustrup, Alan Cox, Herb Sutter, Linus Torvalds, Carlo Pescio, Alex Martelli... Quindi la forte raccomandazione c'è, ok per la riformulazione, a patto che si dica che sono usati dai migliori--BW Insultami BWB 14:46, 1 feb 2006 (CET)

Estensione all'ambito non OO

«[...] non solamente tramite il paradigma ad oggetti.»

Non sono del tutto convinto di questa affermazione. In informatica i design pattern sono soprattutto, se non esclusivamente, un concetto legato agli oggetti.

È scritto chiaro e tondo anche nel libro: i pattern sono la soluzione ad un problema in un contesto, svincolati da qualsiasi linguaggio. Se puoi/vuoi usare gli oggetti li usi, altrimenti nulla impedisce la programmazione procedurale: infatti le GTK sono implementatae in C, pur obbedendo a molti paradigmi, in primis Observer. Sono d'accordo a dire che tuttavia di solito sono implementati ad oggetti. --BW Insultami BWB 14:52, 1 feb 2006 (CET)

PS: Nella versione inglese, pag 4 ultime righe del §1.1, si dice:

"Abbiamo usato esempi in C++ e Smalltalk [...] se avessimo usato un linguaggio procedurale, avremmo incluso anche i design pattern "Ereditarietà", "Incapsulazione", "Polimorfismo" [...] Alcuni dei pattern spiegati sono implementati nativamente da alcuni linguaggi ad oggetti: ad esempio il MultiMethod del CLOS rende poco necessaio il "Visitor" "

Mi pare evidente il concetto: anche perchè, ad esempio, il pattern LeakyBucket non ha niente a che vedere con gli oggetti. E ancor meno ne hanno i Pattern Language of Design Pattern: pensa al MakeitRunMakeitRightMakeitFast... --BW Insultami BWB 07:52, 3 feb 2006 (CET)

Dettagli mancanti - diagrammi

«[...] anche se nel libro gli esempi sono in C++ e Smalltalk, con alcuni diagrammi di classe.»

Si tratta di diversi tipi di diagrammi, i più comuni di classe, ma anche diagrammi di collaborazione. Si potrebbe specificare che sono ispirati all'UML. Comunque, cosa c'entrano con i linguaggi di esempio?

Commento azzardato?

«Tuttavia il concetto stesso di pattern ne permette facilmente la traduzione in qualunque linguaggio, anche in assembly, volendo.»

(corsivo aggiunto da me) Credo che non sia molto agevole né sempre possibile tradurre un pattern in linguaggi non orientati agli oggetti. E quanto a tradurlo in assembly, ho forti dubbi.

Smallpox 16:05, ott 28, 2005 (CEST)

Vedi sopra: se sai programmare in Assembly, pattern come Iterator, Visitor, LeakyBuckets sono molto semplici. Il meccanismo di Interrupt Chain altro non è che un Observer: gli int sono i Notify, la catena sono gli Observer registrati. --BW Insultami BWB 14:53, 1 feb 2006 (CET)

Modifico, tolgo template

e attendo commenti. --BW Insultami BWB 07:35, 6 feb 2006 (CET)

Svincolare la voce dal libro

Non sarebbe il caso di svincolare la voce dal libro in questione (e quindi togliere il template)? Che ne pensate?

Esiste già design pattern, quindi non capisco il senso della tua proposta