Newsgroup: it.lavoro.informatica
Titolo: Design Patterns

Sono curioso di sapere quanto sono usati nella pratica quotidiana i 
Design Patterns della Gang of Four in generale.
Qualcuno di voi li usa regolarmente nella progettazione di software ??
O qualcuno va ancora 'a lume di naso' ???

 Qualcuno di voi li usa regolarmente nella progettazione di software ??
Se serve qualcosa si usa, specie i più comuni (singleton, decorator, varie 
interfacce ecc). Se invece se ne abusa poi i risultati non sono ottimali...
 
-- 
_____________________________
Luc (36, CO)
Software developer since 1985
_____________________________

 Qualcuno di voi li usa regolarmente nella progettazione di software ??
Io. :-)
Ciao,
Giulio
--

 Qualcuno di voi li usa regolarmente nella progettazione di software ??
Eccomi :)



Beh'...usare qualche pattern non esclude andare anche "a lume di naso"
e neppure progettare aculatamente senza rifarsi ai pattern
(che forse e' meglio del lume di naso, tanto per poi non
riscrivere tutto...) :-) .
Nel software per telecomunicazioni ci sono varianti specifiche
dei patter GoF per risolvere problemi tipici.
Comunque quando il caso calza a pennello, sempre che uno se ne
accorga :-) si usano eccome.


spero tutti! E come dice Luc, senza esagerare..sono famosi i danni da
"patternitis"...:)
Tra l'altro i DS hanno ancora una falsa reputazione di "essere un
argomento avanzato astratto e difficile" ( anche per colpa dello stile
un po'  "altisonante" del libro della GoF..) mentre in realta' sono un
argomento veramente semplice..per la maggior parte si possono definire
come variazioni sull'uso di composizione tramite interfacce al posto
dell'estensione..

 O qualcuno va ancora 'a lume di naso' ???
Ultimamente faccio l'analista funzionale. Per me lo sviluppatore pu�
usare quello che vuole, basta che i requisiti siano soddisfatti (e nessun
cliente mi ha mai chiesto esplicitamente come requisito di usare
Singleton, Abstract Factory o altre cose simili)
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


I pattern sono stati formalizzati basandosi su anni di esperienze 
comuni, in pratica venivano quindi giï¿œ largamente utilizzati ben prima 
della loro esistenza e tutt'ora sono presenti in quasi ogni pezzo di 
codice scritto decentemente.
-- 
Soprano

 Singleton, Abstract Factory o altre cose simili)
Per fortuna lo sviluppatore deve dare retta anche a altri, oltre che 
all'analista funzionale.
-- 
Soprano

 dell'estensione..
Sono d'accordo. Tra l'altro i problemi sono vecchi (ecco perch� si sono 
'inventati' i DP) e molta gente, anche prima dell'avvento dell OOD usava 
i patterns 'senza accorgersene'.
Ad esempio la tecnica del Wrapper, cio� quella di costruire un 
'involucro' di livello pi� alto per far s� di 'adattare' una interfaccia
esistente ad un'altra esistente, senza dover riscrivere una delle le due 
interfacce, l'ho usato un centinaio di volte ai tempi del FORTRAN IV.

 Di altri pattern non ho notizie...
Ma LOL :))
In realtà ne avrai usati a bizzeffe, soltanto non te ne sei accorto.
Nulla di male, capita a tutti.
--
ale
http://ale.riolo.co.uk

 In realtà ne avrai usati a bizzeffe, soltanto non te ne sei accorto.
Altrimenti avremmo scritto noi il librozzo relativo... :) 


Programmo in java dal 2000, ne ho utilizzati alcuni piu' spesso.
(singleton,facade,factory,observer/observable,wrapper o architetturali
come dao ,mvc)
altri meno spesso (state, strategy,decorator,composite, command)
Alcune volte applico leggere varianti per ottimizzare.....
L'utilizzo piu' ricorrente e'  il  singleton per il caricamento di
dati statico....

 codice scritto decentemente.
Se un pattern come il "singleton" (tradotto: acqua calda) è il punto
di arrivo del software engineering stiamo proprio freschi :-)


sembra banale, ma nasconde un po' di tranelli
Andrei Alexander ne dedica un capiotolo intero su  "Modern C++ Design"

 Andrei Alexander ne dedica un capiotolo intero su  "Modern C++ Design"
� tutt'altro che banale e si pu� scrivere in vari modi diversi ognuno 
coi suoi pro e contro.
Il punto casomai � che il Singleton � una soluzione "sporca" che 
tradisce la filosofia della programmazione a oggetti, e va usato con 
cautela.
-- 
Soprano

 
era proprio quello che sospettavo.  Anche la riutilizzazione del codice 
era una prassi abbastanza diffusa, sotto forma di 'librerie personali'
(pieni di .obj files che si creavano col 'Lib' del  IBM linker).
Chiaramente c'era da modificare minime parti, ma se il disegno era stato 
fatto bene, si poteva riutilizzare il tutto.
Vabbe', scusate queste divagazioni sulla 'preistoria' del software.

 Andrei Alexander ne dedica un capiotolo intero su  "Modern C++ Design"
Ahem... "Alexandrescu" :)


 (pieni di .obj files che si creavano col 'Lib' del  IBM linker).
Il concetto di libreria � presente ancora oggi. Molti compilatori (che
oggi incorporano il linker nel 99% dei casi) portano ancora dietro le
librerie contenenti il codice oggetto delle funzioni, da linkare al codice
oggetto compilato, all'occorrenza, per produrre l'eseguibile (a meno,
ovviamente, di linkare dinamicamente). Non � cambiato niente da questo
punto di vista rispetto alla "preistoria". Per� i pattern sono qualcosa di
pi�: pattern, appunto, modelli di progettazione. Sono divisi per categorie
ed offrono linee guida generali. Nella OOP � di solito molto utile seguire
strade gi� segnate. Per esempio, il gi� citato "Modern C++ Design" di
Alexandrescu � un gioiellino da questo punto di vista.


 di arrivo del software engineering stiamo proprio freschi :-)
...� l'object oriented e la mania dell'encapsulation che ha causato la 
'riscoperta' dell'acqua calda e di chiamarla 'singleton'...:-)

Soprano ha scritto:


Io direi che *per fortuna* (e a differenza di quanto molti credono) 
spesso lo sviluppatore (il quale, sempre a differenza di quanto molti
credono, e' l'unico ruolo assolutamente indispensabile nella produzione
del software. E spesso conosce anche l'ingegneria del software meglio di
tutti quelli che gli stanno intorno e pensano di essere piu' "ganzi" di
lui [magari perche' guadagnano di piu']) sa dar retta a se stesso senza
stare a sentire le troppe s***e mentali di chi gli sta intorno (e quindi
lo sviluppatore sa perfettamente se e quando e' il caso di usare i Pattern
o meno, quali usare, ecc.).
E' vero che allo sviluppatore spesso mancano un po' di nozioni di
"economia e organizzazione aziendale" che si acquisiscono meglio in altri
ruoli, ma per il resto...
Ciao,
Marco (che ha fatto quasi esclusivamente lo sviluppatore per una decina di
anni).


 Nulla di male, capita a tutti.
Appunto.
Anche il Facade penso di averlo usato. Solo che quando lo usavo
non so nemmeno se ancora lo avevano inventato :-)
Ciao,
Marco.


 applicazione.
Io java (inteso come j2ee) l'ho usato cone sviluppatore solo
nel 2006.
E anche j2se negli anni precendenti non e' stato
il linguaggio che ho usato di piu' (direi che ho usato
al 90% C/C++).
Dal 2007 poi non faccio piu' lo sviluppatore
Ciao,
Marco.


 Perché reinventarsi l'acqua calda è un punto di arrivo che preferisci?
Il punto secondo me e' diverso.
Secondo te che differenza c'e' tra te che "implementi un singleton" e uno
che "prima che inventassero il singleton" implementava una banalissima
classe c++ con costruttore privato e un unico membro dati costituito da un
puntatore ad un oggetto della classe suddetta con un metodo get_instance o
create o simile ?
E' "piu' figo" chiamarlo "singleton"?


 E' "piu' figo" chiamarlo "singleton"?
C'� qualcuno che si � preso la briga di formalizzare dei pattern di 
programmazione e di creare un linguaggio comune per cui oggi se parli di 
"Singleton" tutti sanno cosa si intende. Cos'� che ti disturba tanto di 
tutto questo ?
-- 
Soprano


ops.. colpa loro ->
http://www.ibs.it/book/9780201704310/alexander-andrei/modern-c-design.html

 tutto questo ?
Il fatto che qualcuno pensi che le buone "linee guida"  (come le ha
definite Andrea Laforgia in altro post) non esisterebbero se qualcuno non
avesse inventato i pattern.
Se mi dici che i pattern sono un buon metodo per esprimere sinteticamente
ed efficacemente alcune buone linee guida (alcune delle quali esistenti
gia' prima dell'introduzione dei pattern) sono d'accordo. Se mi dici che
uno invece non puo' scrivere buon codice anche senza aver mai sentito
parlare dei pattern non sono d'accordo.
Che l'interfaccia vada separata dall'implementazione e che sostituire n
chiamate ad interfacce di moduli n diversi con un'unica chiamata di un'
unica interfaccia possano essere delle "buone cose" era risaputo da tempo
(se non sbaglio io questi concetti cercavo di metterli in pratica gia' nel
1994 quando il libro di Gamma e altri non era stato pubblicato).
Per questo mi urta un po' chi oggi ti dice che se tu non usassi il pattern
Facade il tuo codice farebbe schifo o che il software sviluppato prima di
conoscere i pattern doveva necessariamente fare schifo.


 Perché reinventarsi l'acqua calda è un punto di arrivo che preferisci?
Ah, quindi il "singleton" è qualcosa che deve essere insegnata , non è
una cosa che viene naturale ad uno che vuole fare il programmatore
professionista. Namo bene :-)

 professionista. Namo bene :-)
Posso essere sincero?
Io so perfettamente di che si tratta; tuttavia, devo ancora incontrare
un ambio in cui mi sia assolutamente indispensabile.
-- 
Ciao!
Luca

 Non per niente, è ritenuto un "antipattern".
Ed allora perchè sta dentro "il libro" dei pattern? Perchè comunque è
uno schema che molto spesso funziona, oo o no .
I conti tornano, le banalità restano banalità anche se gli appiccichi
una presunta teoria.

 E' "piu' figo" chiamarlo "singleton"?
Oppure è più figo chiamare "singleton" l'acqua calda :-)

 un ambio in cui mi sia assolutamente indispensabile.
Appunto. Perchè conta programmare con efficacia e chiarezza. Magari il
singleton può essere sostituito da tutt'altra struttura. Se questa è
efficace e chiaramente documentata/scritta, non vedo proprio il
problema.

 o meno, quali usare, ecc.
assolutamente! senno' e' una scimmia schiacciatasti non certo uno
sviluppatore.

 Luca
quasi nulla e' assolutamente indispensabile. Molte cose pero' possono
essere utili e migliorare un design senza essere "indispensabili".

 Design Patterns della Gang of Four in generale.
presente...cmq consiglio i libri della "head first" sull'argomento.
-- 
Cordiali saluti
Davide
Consulenza Informatica
 a Monza e Brianza 
www.cleosolutions.com

uno schema che molto spesso funziona, oo o no .
No. Singleton per molti non � un disegno progettuale corretto.
Esistono scuole di pensiero, in programmazione. Esiste il Borg di Alex
Martelli (
http://code.activestate.com/recipes/66531/
), cos� come
esiste chi crede nella Dependency Injection. A me, per esempio, i
singleton non piacciono neanche un po', perch� ho visto quanto
ingestibile diventa il codice, se se ne fa un uso anche solo moderato.
Oltretutto rendono pi� difficile il TDD. Se ti affacci su Google e
cerchi "Singleton antipattern" troverai molti risultati.

un ambio in cui mi sia assolutamente indispensabile.
Il singleton non � indispensabile. Se ne pu� fare benissimo a meno. E
da par mio aggiungo: si dovrebbe farne a meno ;)

essere utili e migliorare un design senza essere "indispensabili".
Hai ragione, ma dubito sia il caso del singleton.

 cerchi "Singleton antipattern" troverai molti risultati.
Se non è un (anti)"pattern" consigliabile, nel "Libro" non ci deve
stare.
Se invece la questione è controversa, probabilmente via via potremmo
scoprire che non è controversa solo per il singleton.
Ed addio "necessità" ed utilità dei pattern....

Ed addio "necessit�" ed utilit� dei pattern....
Infatti, del Singleton si � gi� dimostrata la non necessit�. Non �
cos� per molti altri. Ora, per�, se mi fai la cortesia di andarti a
informare sul perch� il singleton non � consigliato... :)

 informare sul perché il singleton non è consigliato... :)
Se non è consigliato, meglio così,  non ho problemi.
Non sono un sostenitore accanito dei pattern, come punto di
riferimento obbligato degli sviluppatori.
Ma forse si era capito :-)

 E' "piu' figo" chiamarlo "singleton"?
E' lo stesso solo che tutti sappiamo cos'ï¿œ un singleton e ne possiamo 
parlare usando un nome comune ed universalmente riconosciuto.
Ricordati che non tutti hanno cominciato ad interessarsi di informatica 
negli anni 80, ergo non tutti hanno visto quello che i 40enni sanno 
oggi...ergo qualcuno lo deve insegnare.


 conoscere i pattern doveva necessariamente fare schifo.
I pattern non si inventano si scoprono!
Sono piï¿œ o meno come le leggi della Fisica, mica le inventi le scopri.
Un pattern ï¿œ frutto di una esperienza di altri, a te lo spiegano e parti 
con una marcia in piï¿œ.
Un pï¿œ come quelli che studiano informatica all'universitï¿œ, ti spiegano 
le cose che hanno giï¿œ fatto altri, parti meglio rispetto a uno che 
quelle cose non le ha studiate; Nessuno vieta a quello che non le ha 
studiate di diventare egualmente bravo in un tempo piï¿œ lungo.


 con una marcia in pi�.
E' vero, ma secondo me, proseguendo con la tua analogia con le leggi
fisiche, si puo' dire che cio' che e' frutto dell'esperienza di altri 
porta all'introduzione della "linea guida" (corrispondente alla legge
fisica). Il pattern e' poi il "modello" che attualmente ha molto successo
per "spiegare" queste linee guida in modo piu' o meno formalizzato (e
presumo che continuera' ad avere successo anche per i prossimi 200 anni,
visto che ormai da 5-6 anni la teoria informatica pare ferma inchiodata e
non da' segno di schiodarsi, anzi a me pare che ultimamente sembra quasi
regredire)
Cio' che e' importante conoscere come frutto dell'esperienza degli altri
e' la "linea guida" piu' che il "modello" che usi per spiegarla. 
Non solo: ti dico anche che ad esempio quando io mi sono laureato (1998)
di pattern non se ne parlava molto. Ma ad esempio di separazione di
interfaccia dall' implementazione ed eventualmente usare un'interfaccia
unica anziche' chiamarne n-mila se ne parlava eccome. Poi lo hanno
chiamato "Facade", ma sempre quello e'. Ovvero quelli della mia
generazione, alcune di queste "linee guida" (cioe' quelle cose
corrispondenti alle "leggi fisiche" nella tua analogia) le hanno proprio
scoperte, visto che ci si e' scontrati con quei problemi. Poi magari non
tutti hanno avuto l'idea di formalizzarle in "pattern" o altro. Ma non per
questo non le si conoscono.
Direi che si e' contribuito alla loro definizione.
E' poi vero che magari da quando mi sono laureato io di "linee guida" ne
sono state introdotte molte altre (e quindi altri pattern). E sicuramente
ad oggi chi le studia gia' prima di iniziare a lavorare ha dei vantaggi
indubbi ad esempio su di me che nemmeno programmo piu'. Pero' se dici che
non conoscere i pattern = "software che fa schifo" e' come se tu dicessi
che ad esempio siccome Stallman (o Linus Torvald o quelli che hanno
inventato Sun Solaris o Oracle o anche Bill Gates se vuoi) hanno inventato
le loro cose quando nessuno aveva "formalizzato" i pattern, allora i loro
software fanno necessariamente schifo. Io direi che magari i pattern
esistono grazie al loro software che ha permesso di definirli come sono
oggi.
Ciao,
Marco


 riferimento obbligato degli sviluppatori.
Non credo che nessuno abbia mai parlato di "riferimento obbligato".
Sarebbe per� bene, prima di imbarcarsi in certe discussioni, sapere di che
cosa si sta parlando. Tu critichi i pattern, ma non li conosci. E' questo
quel che si deduce da questo thread. Non � molto onesto, ammetterai ;)


 non conoscere i pattern = "software che fa schifo" e' come se tu dicessi
E quando mai? anzi ti dirï¿œ che sono anche contrario a quelli che ti 
fanno le domandine accademiche ai colloqui.
Mi ï¿œ capitato di stare da entrambe le parti e ho selezionato gente molto 
tosta senza chiedere " ma la n permutazione di k rispetto alla 
supercazzola prematurata come si chiama?".
Tornando ai Pattern, sono come la conoscenza del capo operaio 
formalizzata e scritta.
CErto non puoi passare l'esperienza e chi come noi c'ï¿œ passato l'ha 
vista sulla pelle ed ha sicuramente un piccolo vantaggio.


 quel che si deduce da questo thread. Non è molto onesto, ammetterai ;)
E' un argomento dialettico debole. Se devo essere io in prima persona
a scoprire che i pattern indicati nei testi (meglio sarebbe dire
strombazzati) hanno certi pregi e certi difetti, mi dovresti spiegare
a cosa servono i testi stessi.
Sono sempre a favore della lettura e dell'informazione. Ma questo
genere di testi di solito è pure estremamente prolisso e noioso. Un
vero caffè all'americana :-)

 vero caff� all'americana :-)
Mi dispiace, ma non continuer� a dibattere con chi non sa nemmeno di cosa
stiamo parlando e si ostina a usare un tono saccente e provocatorio come
il tuo. Se non vuoi studiare, sono problemi tuoi, ma non ti arrogare il
diritto di discutere degli argomenti che non hai voluto approfondire.
Definisci argomenti "strombazzati" da libri che non ti sei neanche preso
la briga di sfogliare. Parli a vanvera, questa � la verit�. Tu s� che
finisci, in questo modo, per avere argomenti dialettici deboli. Sono molto
deboli i tuoi, non i miei. Io ho scritto cose che tu non ti sei neanche
sforzato di leggere e comprendere. Con tutto il rispetto ti lascio
perdere, perch� non credo che tu sia incapace di capire, � solo che non ne
hai voglia, e allora � davvero inutile "sprecare acqua e sapone per lavar
la testa al ciuccio" :))


 diritto di discutere degli argomenti che non hai voluto approfondire.
............
Mi sbagliavo. Sei uno di quelli che sostanzialmente ritiene
irrinunciabili i patterns, o la lettura dei relativi testi.
Non c'è niente di male, basta essere chiari sin dall'inizio ;-)
Penso comunque che la discussione con qualcuno non allineato alle
proprie idee faccia sempre bene a tutti.