Newsgroup: it.comp.java
Titolo: [META-DOMANDA]Design Patterns

Salve, come da oggetto vorrei fare una meta domanda, cioè qual'è
secondo voi il miglior newsgroup dove fare domande sui design
patterns?
Io sviluppo in Java e quindi sarei tentato di farle in questo
newsgroup, però i design patterns non si usano solo con Java sono un
concetto più astratto.
Che mi dite?
Ciao

 Ciao
In effetti dovrebbe esistere un gruppo apposito.. ma non credo che
avrebbe molto successo in una giungla di programmatori in cerca di
soluzioni rapide e afflitti per lo più dal - come scherzosamente lo
definisce un mio professore - "rush to code"!
Come gruppo più generico, in italiano, vedo solo questo:
http://groups.google.com/group/it.comp.programmare
.
In questo gruppo troverai comunque molta gente interessata, secondo
me.. e poi Java si presta bene, in quanto Object-Oriented e quindi
affammato di patterns!  :D
Ciao,
Francesco
___________________________
http://just-share-it.blogspot.com/

Massimo S. wrote:

penso che i design pattern sono legati a doppio filo al linguaggio di
programmazione: pensa a come si "riducono" in python i pattern strategy,
iterator o factory method, per dirne un paio, o come java
offra "gratuitamente" le classi, che, volendo lavorare in c, dovrebbero
essere ottenute tramite quello che si puo' chiamare "object-oriented
pattern"
-- 
By ZeD

 programmazione: [...]
L'implementazione è sicuramente legata al linguaggio ma i design 
patterns sono, per definizione, generali (ossia soluzioni a problemi 
frequenti, indipendentemente dall'implementazione).

visto che it.comp.programmare ha un'attività bassa, mentre questo
gruppo l'ha media proverò a porre le domande qui.
Ciao e grazie :-)

 Ciao e grazie :-)
Aspettati delle risposte in Java, però :)
-- 
bye
DKano

Pablo Xon wrote:

dimmi in quale caso ha *senso* applicare il pattern "There and back again"
in java (
http://www.brics.dk/RS/02/12/BRICS-RS-02-12.pdf
)
comunque penso che abbiamo una definizione di DP diversa :)
per me i DP possono essere visti come una "generalizzazione" di soluzioni
che si scopre usare spesso per risolvere problemi diversi. Ma linguaggi
diversi sono *strumenti* diversi, ognuno con i suoi punti di forza e le sue
idiosincrasie. A parte alcuni pattern abbastanza generici, molti dipendono
dal linguaggio per cui sono pensati.
-- 
By ZeD

 dal linguaggio per cui sono pensati.
Qui però rientriamo nelle diverse implementazioni, negli algoritmi più 
che nei patterns.
Io non contestavo la maggiore o minore utilità dell'uso di un pattern in 
un determinato linguaggio ma solo il presunto "legame" pattern <-> 
linguaggio.
Vero (ed ovvio) che diversi linguaggi implementano in modo diverso 
determinati DP ma alla fin fine gli algoritmi di fondo sono gli stessi 
(vedi teorema di Bohm-Jacopini) quindi per ottenere un certo risultato 
/in qualche punto/ sarà implementato un determinato pattern (o, 
purtroppo, una sua "riedizione").
Poi che questa implementazione sia già disponibile allo sviluppatore o 
che sia da realizzare ex-novo, certamente dipende dal linguaggio.
Detto più chiaramente: un DP è una generica soluzione progettuale, _non_ 
implementativa, che va ovviamente confrontato con l'architettura a cui 
si intende applicarlo (ove vantaggioso).
Ciao.

Mi intrometto nella discussione, sperando di aver fatto bene, in
quanto ho un problema da risolvere e penso proprio che debba far
ricorso ad un design pattern.
Vi spiego...in pratica sto creando un'applicazione che fa uso di
hibernate per la persistenza....e quindi per ogni metodo ogni volta
che devo
accedere al db devo prima aprire la Sessione, fare tutte le
operazioni, ed infine committare e chiudere la sessione.
Beh vorrei evitare di scrivere ogni volta il codice ripetitivo che
apre e poi alla fine committa e chiude la seesione quindi non so
magari estendendo una classe
astratta che effettua proprio quelle operazioni e poi nella classe
figlia non faccio altro che scrivere i vari metodi che mi servono.
Non so se mi sono spiegato bene ed ho reso chiaro il mio problema.
Grazie di tutto in anticipo.
Rocco.


 Non so se mi sono spiegato bene ed ho reso chiaro il mio problema.
Io ho fatto cosě:
http://docs.parancoe.org/reference/html/persistence.html
Un presentazione su questo argomento:
http://www.slideshare.net/benfante/using-daos-without-implementing-them
Ciao
   Lucio
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org

 JUG Padova          
http://www.parancoe.org.
..have a look at it!
www.jugpadova.it
   
http://www.jugevents.org
Ottimo sicuramente approfondirò l'argomento ma non è proprio quelle
che volevo io.
Io vorrei scrivere il tutto da me senza far ricorso a framework
esterni anche perchè la parte di persistenza
con factory, dao e quant'altro l'ho già fatta.
Quello che ora mi serviva è proprio la possibilità di non dover ogni
volta scrivere codice per aprire la sessione, poi committare ed infine
chiudere
per ogni volta che uso i metodi da me implementati.
Vorrei che tutto questo si possa gestire magari usando un design
pattern proprio per questo problema...sempre se c'è ne sono.
Grazie cmq della tua risposta...molto utile...infatti la prossima
volta eviterò di scrivere il tutto da me...mi vado immediatamente a
vedere e studiare i link che mi hai passato.

 vedere e studiare i link che mi hai passato.
Dimenticavo di dire che quello che io ho scritto mi serve per un
programma standalone.

 si intende applicarlo (ove vantaggioso).
Il fatto e' che in un determinato linguaggio potrebbe non esistere il
"problema" di cui il DP e' la soluzione.
Pensa al celebre papero di Norvig su DP e Lisp.
-- 
-riko

 "problema" di cui il DP e' la soluzione.
Sinceramente non vedo differenze con quanto scrivevo quando "contestavo" 
il legame pattern <-> linguaggio :)
Mi pare stiamo dicendo la stessa cosa, forse sbaglio.

 Mi pare stiamo dicendo la stessa cosa, forse sbaglio.
Io sono convinto che i dp dipendano fortissimamente dal linguaggio,
tanto che alcuni pattern di fatto in un dato linguaggio non sono nemmeno
"design pattern" ma sono uso banale di funzioni del linguaggio oppure
sono innaturali in quanto il linguaggio stesso risolve in altro modo il
problema risolto dal pattern. 
-- 
-riko

 programma standalone.
Metti la sessione in un ThreadLocal. Chiudila manualmente in un oggetto 
a monte della chiamata, oppure puoi sempre usare un proxy:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Proxy.html



Non credo. Un factory pattern è sempre un factory pattern. 
L'idea che ne sta alla base e pure la sua utilità nel codice in cui verrà utilizzato 
non dipendono dall'implementazione e tanto meno dal linguaggio specifico.

 Non credo. Un factory pattern è sempre un factory pattern. 
Certo. Ma uno strategy in un linguaggio funzionale potrebbe essere
semplicemente un "uso una funzione di ordine superiore". Il primo
esempio che mi viene in mente. 
Ribadisco, il papero di Norvig e' estremamente interessante.
-- 
-riko

 non dipendono dall'implementazione e tanto meno dal linguaggio specifico.
Quoto.
Pattern != algoritmo, anche se spesso si tende a (con)"fondere" le due cose.
L'"uso banale di funzioni del linguaggio" di cui parla Enrico è, IMHO, 
l'implementazione "a monte" di un certo pattern (o di un suo sostituto), 
ovvero lo spostamento dell'uso del DP dallo sviluppatore finale a chi ha 
implementato l'ambiente da lui utilizzato.
Ottimo l'esempio di cicap che illustra pienamente questo concetto: 
l'abstract factory è destinato a linguaggio OOP, quindi lo si potrebbe 
pensare legato esclusivamente a linguaggi di questo tipo.
In realtà sappiamo bene che anche i linguaggi non-OOP possono essere, 
tramite appositi pattern, estesi in modo da poter gestire oggetti per 
cui la componente generale ed astratta del pattern lo rende _sempre_ 
applicabile.
Che poi sia più o meno vantaggioso e/o utile è un altro discorso ;)