Newsgroup: it.comp.java
Titolo: Design Patterns ?

Buongiorno a tutti,
sono Analista Programmatore, lavoro da circa 20 anni, conosco 
vari linguaggi, dal cobol al c, da VB a Java.
Soprattutto in Java sviluppo da circa 1 anno e spesso sento
dire che per realizzare un prodotto o un'applicazione in Java 
programmando ad Oggetti e' di qualita' scadente non utilizzare
Pattern.....
Che ne pensate ?
Scrivere un'applicazione in Java senza Patterns e' cosi' orrendo ????
Grazie a che desidera esprimere la propria opinione e/o esperienza
Lucilla.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Scrivere un'applicazione in Java senza Patterns e' cosi' orrendo ????
Ciao,
i pattern sono, per definizione, soluzioni che nella pratica si sono
dimostrate buone (ok, in determinati contesti, con determinati limiti,
controindicazioni, ecc. ecc..).
Quindi scrivere software senza conoscere i pattern non significa
necessariamente scrivere software orrendo, ma significa sicuramente
doversi reinventare le buone soluzioni, spendendo quindi più tempo e
fatica. Inoltre tipicamente è difficile rendersi conto subito dei limiti e
delle problematiche della soluzione ottenuta.
Poi, per pigrizia, miopia, non capacità...tipicamente la soluzione
risultate sarà peggiore di quella che si sarebbe ottenuta applicando dei
pattern noti...ma, ripeto, non necessariamente.
...è un po' come provare a mettere assieme un puzzle, senza averne
sott'occhio il risultato finale.
Non voglio essere frainteso. Io non credo che si debbano usare i pattern,
cioè passare il tempo a scrivere il software provando bovinamente ad
applicare i pattern. I pattern spesso "emergono" scrivendo bene il
software, cioè cercando di seguire dei buoni principi di design. Però la
loro conoscenza ci aiuta a riconoscerli e a non prendere strade (troppo)
sbagliate.
-- 
Lucio Benfante
JUG Padova
www.jugpadova.it

 Scrivere un'applicazione in Java senza Patterns e' cosi' orrendo ????
I pattern esistono in praticamente tutti i mestieri, e spesso perfino 
nell'arte, solo che non sempre c'è chi si è preso la briga di 
catalogarli per iscritto. IMHO la loro conoscenza dovrebbe far parte del 
bagaglio minimo di ogni buon designer. Tu che penseresti di un muratore 
che usa un modo tutto suo di costruire il ponteggio? Ti fideresti di un 
elettricista che predispone un impianto senza seguire schemi convenzionali?
Nel nostro caso specifico un software che utilizza correttamente i 
pattern è spesso più semplice da leggere e modificare, più stabile e più 
sicuro, proprio perché non incorre nelle problematiche che i pattern 
affrontano e risolvono.
Ovviamente come per tutte le cose anche il loro utilizzo va valutato 
caso per caso a seconda degli scopi del progetto, dimensioni etc.
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://ammentos.biobytes.it
Flash tutorial: 
http://ammentos.biobytes.it/quickstart/quickstart.htm

> ????
LB> Non voglio essere frainteso. Io non credo che si debbano usare i
LB> pattern, cioè passare il tempo a scrivere il software provando
LB> bovinamente ad applicare i pattern. I pattern spesso "emergono"
LB> scrivendo bene il software, cioè cercando di seguire dei buoni
LB> principi di design. Però la loro conoscenza ci aiuta a
LB> riconoscerli e a non prendere strade (troppo) sbagliate.
Aggiungo un paio di cose a quanto detto da Lucio (e che sottoscrivo).
La prima  è che  bene o  male tutti usiamo  "pattern" per  risolvere i
problemi che  troviamo, i pattern  non sono soluzioni precotte  ma vie
note per progettare e realizzare.
A volte  si eccede  e si forza  il problema  a rientrare nel  range di
soluzioni  fornite da  una  tecnica nota.   Studiarsi  i patterni  può
aiutare a comprendere che certe soluzioni solo "locali" ad un problema
e  non  necessariamente  esportabili  (problema  de  "per  l'uomo  col
martello ogni  problema è  un chiodo" o  della "soluzione in  cerca di
problemi").  D'altro  canto  conoscere  un ventaglio  di  soluzioni  e
sopratutto i problemi cui si adattano permette di individuare analogie
coi problemi noti ed elaborare soluzioni derivate.
Un esempio (quasi completamente sorpassato con l'uscita della versione
1.5 del linguaggio): partendo dalla conoscenza del pattern Singleton è
possibile elaborare una soluzione al  problema di definire un tipo che
può assumere  valori in un insieme  finito e solo  in quello (qualcosa
come gli scalari utente del Pascal).
Occhio alle trappole. Un pattern è  un buon modo di progettare, non un
progetto  pronto.  I dettagli  vanno  pensati  perché  si adattino  al
problema.
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

 Scrivere un'applicazione in Java senza Patterns e' cosi' orrendo ????
Ma no, detta in questi termini pare una questione di gusto estetico o 
addirittura di moda, quando è sostanziale.
Partiamo dall'inizio.
I pattern rappresentano soluzioni "collaudate" a problemi standard. Il 
programmatore però ha di fronte il problema reale: quindi, se il 
programmatore vuole applicare un pattern deve, per prima cosa, 
ricondurre il problema reale a uno o più problemi standard. Cioè, il 
programmatore deve "vedere" nel suo problema la necessità di un 
singleton, di un factory, di un listener e così via.
In questa fase, se il problema non è riconducibile ad un pattern o si 
individua una soluzione migliore, ben venga! E' sbagliato quando si 
applicano i pattern per forzatura, come è sbagliato inventare una 
soluzione ad un problema per cui esiste già un design pattern.

Scrivere un'applicazione in Java senza Patterns e' cosi' orrendo ????
In Java, specie con una piattaforma come J2EE (ora JavaEE) l'uso dei
pattern è molto più formalizzato e sostanziale rispetto ad altri
linguaggi.  In un contesto "enterprise" non si prescinde facilmente
dalla buona suddivisione di responsabilità del codice e i pattern
diventano una reale necessità.  Sarebbe più che altro lecito chiedersi
perché mai si vuole "sfuggire" ai pattern! :-)

OK, grazie delle Vs. opinioni...
Lucilla!


 Scrivere un'applicazione in Java senza Patterns e' cosi' orrendo ????
Secondo me in parte è vero, in parte fa molto figo dire che si usano i 
"pattern". D'altra parte se programmi da tempo avrai certamente librerie 
tue di codice già fatto per vari casi, o comunque quando ti trovi 
davanti ad un problema pensi "potrei usare il codice che ho usato 
l'altra volta, quando ho fatto il sw per un concorso felino" (esperienza 
personale :-) ). Quindi cosa hai fatto se non riutilizzare del codice 
usato per un problema simile? Certo non sarà formalizzato come un 
"pattern java" però il concetto è lo stesso.
Per riassumere: è utile riusare il codice, è bello e rende più veloce e 
a prova di errori l'analisi che ci siano degli schemi predefiniti usati 
da tutti in modo che siano stati analizzati e provati da molti (lo 
stesso concetto del sw open source, in pratica), ma che se uno non 
infila la parola "pattern" ogni 3 frasi non sa programmare mi sembra un 
pò eccessivo.
Purtroppo nell'informatica c'è un pò questa 'cosa' per cui ad un certo 
punto fa figo usare qualcosa (che magari con un'altro nome si faceva 
già) e improvviamente tutti ne parlano come se fosse la scoperta del 
secolo (sopratutto quelli che di informatica non ne sanno una beata m..)
bye
DKano

 writes:
D> il codice che ho usato l'altra volta, quando ho fatto il sw per un
D> concorso felino" (esperienza personale :-) ). Quindi cosa hai fatto
D> se non riutilizzare del codice usato per un problema simile? Certo
D> non sarà formalizzato come un "pattern java" però il concetto è lo
D> stesso. 
Il pattern  ha poco a  che vedere  col riuso. Ha  a che vedere  con la
strutturazione.
La cosa può permettere il riuso ma non è garantito.


 strutturazione.
Strutturo il programma B in un certo modo perché ho strutturato il 
programma A, che è simile, nello stesso modo e andava bene... riuso di 
schemi invece che di codice, o no?
Forse non mi sono espresso bene, volevo dire che comunque non è che ogni 
volta si progettava tutto ex-novo anche quando non c'erano pattern 
formalizzati. Certo che adesso è tutto molto più rapido, anche per il 
fatto che molti usano gli stessi schemi e quindi se ne può discutere, 
cosa che prima non avveniva, se non localmente.
Rimango però dell'idea che alcune parole informatiche, lasciando da 
parte la loro effettiva utilità, fanno molto figo in certi momenti...
bye
DKano

 parte la loro effettiva utilità, fanno molto figo in certi momenti...
Uhmm IMHO dire pattern non fa poi così figo. A fare figo generalmente 
sono le tecnologie, più moderne (e spesso strane) sono e meglio è: che 
so, tipo Ajax, REST, SOA etc., come se a sfoggiarne l'uso si garantisse 
in qualche modo la qualità del prodotto finale.
Anzi, è soggettivo, ma spesso ho l'impressione che più si trovano nomi 
come questi, più scompaiono altri meno aggressivi come appunto pattern, 
OOP, design etc.


 OOP, design etc.
Hai ragione, adesso ad esempio SOA fa fichissimo... i poveri pattern 
sono andati un pň fuori moda! Tanto meglio, cosě li possiamo usare senza 
sentirne parlare a sproposito e magari ci saranno anche piů simpatici 
(personalmente ho una forma di rigetto per chi si atteggia a 
superesperto fighetto, immagino di non esser il solo :-) )
bye
DKano

DKano ha scritto:

Aggiungo: io ho iniziato ad usare seriamente i pattern quando ho smesso 
di lavorare con uno che li metteva anche nell'insalata, ma credo di 
esser un caso un tantino patologico ;-)
ri-bye
DKano

> strutturazione.
D> Strutturo il programma B in un certo modo perché ho strutturato il
D> programma A, che è simile, nello stesso modo e andava bene... riuso
D> di schemi invece che di codice, o no?  Forse non mi sono espresso
D> bene, volevo dire che comunque non è che ogni volta si progettava
D> tutto ex-novo anche quando non c'erano pattern formalizzati.
O.K. messa in  questo modo torna.  I pattern  non sono una invenzione,
sono solo  un mettere nero su  bianco dei buoni modi  di operare (così
come accade in  architettura, da cui viene l'idea  di Design Pattern -
Schema di Progettazione)



Uso Jboss Seam scritto da Gavin king, probabilmente il nr. 1 al mondo oggi.
Se leggi i suoi libri o i suoi articoli lui oggi sta facendo una sorta di
crociata contro i pattern.
la parola d'ordine e' "deingegnerizzare" "deingegnerizzare"
"deingegnerizzare"
Questo chiaramente non vuole dire che si torra al java sdk elementare, anzi,
lo stesso seam integra EJB3 JSF facelets e volendo anche portlet remoting
ajax localization eccetera, che in gran parte sono appunto pattern.
Pero' , rispetto alla vecchia applicazione jsp-form
bean-action-validation-ejb2-validation-DAO-pojo-database, il tutto condito
con un centinaio di xml , magari per fare una paginetta banale sul web,
direi che siamo in una situazione diversa a un paio di livelli:
Pagina HTML con dentro entity nella pagina che modificano direttamente il DB
e poi back bean vari che si scambiano tutto.
Ciao Nicola
Pero'
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 pole
Nicola


 Uso Jboss Seam scritto da Gavin king, probabilmente il nr. 1 al mondo oggi.
A proposito di mode...

 writes:
nn> Scusa la precisazione ma Ajax non c'entra nulla, e' uno stile
nn> diprogrammazione per potenziare i client web.
AJAX e i  Design Pattern sono tutti e  due tecniche di programmazione,
il  primo più  "concreto",  ovvero si  è  già fatta  una scelta  delle
tecnologie  da  usare  e   sulla  base  di  questa  verrà  organizzata
l'architettura di  parte dell'applicazione. Il secondo  è più astratto
perché non fa alcuna assunzione sul linguaggio addottato.
Il  famoso  libro  della  "Banda  dei  4" che  ha  dato  origine  alla
"consapevolezza" dei pattern, va benissimo  per Java ma non mi ricordo
presenti codice Java :)


 presenti codice Java :)
Vero, anche se esistono "traduzioni" e anche raccolte specifiche per 
Java; ma l'idea di base č che i pattern vadano bene per qualunque 
linguaggio ad oggetti.
A questo punto non posso non aggiungere che per lo stile di codifica il 
mio maestro č stato Carlo Pescio col suo "C++ Manuale di stile"... 
appunto rivolto al C++ ma con un'ampia "portabilitą" verso Java (e altri 
linguaggi).


 presenti codice Java :)
Concordo appieno che un pattern puro e' cross-language.
Se prendiamo l'intero JEE5, ad esempio, per rimanere IT col NG, e' un
pattern o meglio un insieme di pattern, che vengono implementati tramite
librerie Java, ma rimane un pattern, cioe' uno stile e delle regole di
programmazione che, se seguite bene, permettono di avere un codice piu'
elegante e che potra' funzionare correttamente in ambienti distribuiti e
scalabili.
Per un gioco intelletuale si potrebbe scrivere una applicazione che segue le
specifiche(pattern) JEE5 usando solo sdk puro. Chiaramente non ha senso
perche ci si impiegherebbe un tempo spropositato e avremmo meno sicurezza
che il tutto sia conforme alle specifiche che usando librerie gia' testate.
Nel caso di Ajax, che secondo la definizione originale e':
Javascript + CSS + xhtml + xslt + xml + DOM + xmlhttprequest
pattern ne vedo pochi ma vedo linguaggi e tecnologie.
ciao Nicola


> ricordo presenti codice Java :)
nn> Concordo appieno che un pattern puro e' cross-language.
Mi  sono  reso conto  che  avrei  dovuto rispondere  non  a  te ma  al
messaggio cui tu rispondevi :).
nn> Nel caso di Ajax, che secondo la definizione originale e':
nn> Javascript + CSS + xhtml + xslt + xml + DOM + xmlhttprequest
nn> pattern ne vedo pochi ma vedo linguaggi e tecnologie.
Appunto,  è una  tecnica di  programmazione che  include la  scelta di
alcune tecnologie. Decisamente non era al tuo post che dovevo rispondere :).
Mi scuso per la svista.


 e poi back bean vari che si scambiano tutto.
io qui ci vedo invece una semplificazione di quello che si faceva una 
volta..ma nessuna rivoluzione...forse va bene cosi'. 


no, un insieme di tecnologie da utilizzare...e quando le utilizzi non sei 
forzato a seguire alcun pattern, tecnica di programmazione. 

> 
t> no, un insieme di tecnologie da utilizzare...e quando le utilizzi
t> non sei forzato a seguire alcun pattern, tecnica di programmazione.
Il discorso in realtà è più grigio che bianco o nero.
AJAX  è più  la scelta  di come  utilizzare quelle  tecnologie  che la
scelta delle tecnologie stesse.
Posso usare (quasi tutte) le stesse tecnologie in altro modo.
D'altro canto ce ne sono altre che ti portano forzatamente a AJAX o quasi.



Aggiungiamo per una comunicazione asincrona tra client e server...non mi 
dirai che una comunicazione asincrona e' un pattern adesso?!

tonino ha scritto:

No, ma una comunicazione asincrona usando Javascript e Xml si, ed ha un nome, 
Ajax. C'e' gente che ancora si chiede da dove diavoli si scarichi Ajax... o_0
E' che in questo contesto, "pattern" e "tecnica di programmazione" sono quasi 
sinonimi... E' una tecnica di programmazione che e' quasi un pattern, ed un 
pattern che richiede una certa tecnica di programmazione. Ad ogni modo, 
inizialmente ero scettico ora lo considero un buon "prodotto"

 writes:
CA> E' che in questo contesto, "pattern" e "tecnica di programmazione"
CA> sono quasi sinonimi... E' una tecnica di programmazione che e'
CA> quasi un pattern, ed un pattern che richiede una certa tecnica di
CA> programmazione. Ad ogni modo, inizialmente ero scettico ora lo
CA> considero un buon "prodotto"
Ha un solo grande difetto. Non è conforme alla regolamentazione sulla
accessibilità...
(per non parlare della fantasia nell'implementare i motori JS :> )



Il problema neppure si pone, quindi non e' un difetto a mio modo di vedere.
Ajax va usato per applicazioni web che sono cosa ben differente da un sito 
web. 

> 
tonino> Il problema  neppure si pone, quindi  non e' un  difetto a mio
tonino> modo di vedere.   Ajax va usato per applicazioni  web che sono
tonino> cosa ben differente da un sito web.
Perfetto, un concorrente in meno per le applicazioni per le  P.A. :)



Ti diro'...dopo aver dato un'occhiata al suo Seam, bisogna dire che
smentisce se stesso.
Se secondo lui deingegnerizzare significa fornire annotations per
qualsiasi cosa, dove se per caso te ne dimentichi una per strada non va
piu' niente e non si sa perche'...beh allora viva la
sovra-ingegnereizzazione del codice!
Insomma, imparare bene Seam equivale a studiare gli ideogrammi cinesi.
Tra l'altro prova a farlo funzionare con Glassfish...che ti dico
funziona benissimo con EJB3 senza Seam, scoprirai che devi perdere
giornate per la configurazione...evidetemente c'e' qualcosa che non va.
Oppure si dica chiaramente che e' un prodotto solo per JBoss.

 Hai ragione, adesso ad esempio SOA fa fichissimo... 
IMHO i termini che oggi fanno più "fico" sono 'AJAX', 'WebServices' e 
'SOA', almeno per la mia esperienza. Sarebbe interessante fare una 
statistica... ;-)
Ciao,
Giulio


Non credo di essere un concorrente in meno per nulla...
AJAX va utilizzato quando realmente puo' offrire benfici...se poi certa
gente vuole ficcarcelo ovunque anche dove non centra niente, solo
perche' fa figo, beh allora probabilmente andra' incontro ad un sacco
di problemi, e con il solo risultato di fornire agli utenti qualcosa
che non va come dovrebbe...
...contenti loro.

 Ajax. C'e' gente che ancora si chiede da dove diavoli si scarichi Ajax... o_0
Infatti neppure dovrebbe esistere quello stupido acronimo. Ora il fatto
solo che qualcuno abbia inventato il termine fico una bella mattina fa
di se un pattern?
Inoltre..tu hai Javascript, hai un oggetto XHR che gestisce la
comunicazione...hai il DOM..li usi per comunicare e aggiornare lo stato
della tua applicazione (residente su browser).
Questo signori non e' un pattern. Altrimenti diciamo pure che RMI +
Swing e' un pattern..ma per favore! Ho deciso di chiamare questa fica e
nuovissima accoppiata "Leonardo"...ora si che e' un pattern..
Ora analizziamo JavaScript + XHR + DOM. Per fare quello che vogliamo
fare si possono seguire decine di strade diverse.
Possiamo ricevere dal server un dato e generare l'html tramite
javascript, hardcodandolo nelle istruzioni del linguaggio stesso.
Oppure possiamo ottenere un bel XML e trasformare in HTML con un XSL  e
una opportuna libreria javascript.
Oppure possiamo ottere l'HTML gia' pronto dal server e innestarlo nella
pagina senza dover scrivere alcuna logica di presetanzione in
JavaScript (questa tecnica ahime' ha pure un altro acronimo...AHAH, e
non e' una presa in giro.)
ecc..
Insomma ci sono svariate strade e modi di implementarlo...ragion per
cui non puo' essere un pattern.
Invece secondo me gia' AHAH potrebbe essere piu' vicino ad un pattern
visto che e' un modo di fare AJAX.

 accessibilità...
Non è la tecnica ad dover essere conforme alle norme di
accessibilità, ma il sito.
Se il sito funziona correttamente anche con il javascript disattivato
allora è a posto.
Niente vieta di utilizzare tecniche javascript di indubbia utilità per
l'utente (come il caricamento parziale delle pagine o i controlli
formali lato client) a patto che l'applicazione non perda di
funzionalità se queste tecniche non sono disponibili sul browser.

 writes:
cicap> Non credo di essere un concorrente in meno per nulla...
Dubito che una applicazione che _fonda_ il suo funzionamento su JavaScript
sia accessibile secondo la definizione data dalla direttiva Stanca...
Questo senza nulla togliere ad  Ajax che permette di fare applicazioni
veramente veramente carine.


> sulla accessibilitą...
emmeesse> Non č la tecnica ad dover essere conforme alle norme di
emmeesse> accessibilitą, ma il sito.  Se il sito funziona
emmeesse> correttamente anche con il javascript disattivato allora č a
emmeesse> posto.  Niente vieta di utilizzare tecniche javascript di
emmeesse> indubbia utilitą per l'utente (come il caricamento parziale
emmeesse> delle pagine o i controlli formali lato client) a patto che
emmeesse> l'applicazione non perda di funzionalitą se queste tecniche
emmeesse> non sono disponibili sul browser.
Perfettamente vero. Ma fai tu una applicazione Ajax _e_ accessibile, lo
vedo un lavoraccio enorme...


 Oppure si dica chiaramente che e' un prodotto solo per JBoss.
Mah, sinceramente non mi pongo il problema del Glassfish che e' una
reference implementation.
Per gli altri , leggasi Bea e Websphere, si sa che sono ancora indietro col
Jee5, quindi si, di fatto seam oggi gira in pratica solo su Jboss.
Nicola


 Una volta capiti quelli vai come l'olio.
A proposito, si sembra essere molto potente. Ma c'e' una cosa che mi
suona strana rispetto a quanto ho sempre visto: i session bean che
dovrebbero occuparsi della business logic, contengono anche codice e
annotationi riguardanti il front-end...ho qualche dubbio che su grosse
applicazioni questo sia un vantaggio..cosa ne pensi?
Comunque e' una palese rottura con quanto e' sempre stato detto...