Newsgroup: it.comp.java
Titolo: i pattern non servono se hai esperienza?

Salve a tutti,
questa è l'affermazione di un programmatore che conosco. Che ne
pensate? è cosi o ....? a voi la parola



Se hai esperienza applichi i pattern senza accorgertene, quindi  
tecnicamente la frase è corretta
-- 
http://www.hostingjava.it/-SaThot/mail/me


I Design Pattern? Quelli di J2EE o quelli di Gamma et al.
Secondo me fanno parte delle conoscenze che un progettista deve avere.
Con questo intendo che deve anche sapere non solo quando è il caso di 
applicare un certo pattern ma anche quando non lo è.
Ho visto progetti software infarciti di pattern non solo inutili ma 
anche dannosi perché complicavano inutilmente il codice.
-- 
Andrea Francia
http://www.andreafrancia.it/

 
http://www.hostingjava.it/-SaThot/mail/me


E' come nel Jazz: devi imparare tutte le scale e gli accordi possibili
e poi dimenticarli. Solo così suonerà "naturale"...
Poi c'è molta gente che pensa che i pattern siano come delle care
vecchie "librerie di funzioni", invece sono solo un modo per
documentare delle "best practice", specificando bene come e quando
sono utili.
Poi se uno è bravo li utilizza anche senza esplicitare la cosa.
Come nel jazz, appunto :)
--
www.megadix.it


Falso. Secondo me ha un po' travisato il concetto della Xp in base al
quale i design pattern devono emergere dal codice a posteriori e non
il contrario.

 gioco la combinazione di più pattern
Appunto, non ce l'hai a mente, ma ti viene spontaneo farlo così, senza  
pensarci, poi se vai a guardare è il pattern xyz.
Un mio prof parlava di memoria precompilata, non sai perché fare così ma  
sai che va.
-- 
http://www.hostingjava.it/-SaThot/mail/me

On 18 Mar, 16:20, "Manny Calavera" <leggi_n...@fir.ma.invalid> wrote:

mah guarda che alcuni pattern non sono cosi intuitivi da venirti
spontaneo pensarli,
quello di cui parli tu è un'altra cosa ovvero la forma mentis
algoritmica che è ben diverso.
Un discorso è pensare ad un metodo, ad una classe, ad un algoritmo che
fa una certa cosa;
pensare un grosso progetto dalla A alla Z con tutte le sue
complicazioni è un'altra cosa credimi



Concordo... spesso ho applicato delle soluzioni è poi ho scoperto essere 
codificate in pattern...
"Se ti indicano la luna e la luna che devi guardare non il dito".
bene i pattern sono un metodo per indicare la soluzione, non la 
soluzione...

pensate? è cosi o ....? a voi la parola
Beh, lo studio dei pattern secondo me dovrebbe fare parte ad esempio del 
piano di studi nelle facoltà informatiche... ai miei tempi ad ingegneria del 
software non si insegnavano. Però è anche vero che non sono "soluzioni 
pronte all'uso",  bensì "best practices" ben documentate, universalmente (o 
quasi) riconosciute... spunti di riflessione e di progettazione, ecco :-)
Saluti,
    Scorpio 

 
Beh, a scuola rischierebbero di diventare fuorvianti: programmatori che 
ad ogni riga si domandano quale pattern dovrebbero applicare in quel 
momento. Non va bene. Deve assolutamente andare di pari passo con 
l'esperienza.
Anzi, oserei dire che l'esperienza deve precedere i pattern in qualche 
modo ;)



Infatti gli insegnano.
Ho passato due corsi di "Pattern" e alla fine di questi ho deciso che non  
servono a nulla.
O meglio nessuno dei due prof mi ha dato un valido motivo per usarli e  
quando ci provavo il risultato era pessimo.
In un terzo corso ci insegnarono il visitor, senza dire che fosse un  
pattern, solo "si fa così", ancora oggi lo uso con successo.
-- 
http://www.hostingjava.it/-SaThot/mail/me


il risultato era pessimo probabilmente perchè non andavano usati in
quel contesto
o perchè gli usavi male!


wrote:

GLI usavi male?
Saprai usare i pattern, ma con l'italiano proprio non va :)

 o perchè gli usavi male!
Non basta conoscere i design pattern, bisogna anche imparare a 
riconoscere quando si applicano. Non a caso nel libro di Gamma et al. 
per ogni Pattern del catalogo è presente il paragrafo Applicabilità e 
Conseguenze che ti aiutano a valutare se il pattern è adeguato al tuo 
problema.
Un corso fatto bene sui design pattern dovrebbe contenere anche queste 
considerazioni.


 wrote:

scusa per l'errore ma scrivevo di fretta,ogni tanto lavoro anch'io :)

 scusa per l'errore ma scrivevo di fretta,ogni tanto lavoro anch'io :)
Ma fai proprio tutto di fretta! Stavolta hai sbagliato post a cui 
rispondere! :)


 
http://www.andreafrancia.it/
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 wrote:

Non sono un programmatore esperto, anche se cerco sempre di fare del
mio meglio.
Per l'esperienza che ho avuto sono abbastanza d'accordo con
l'affermazione di cui sopra, anche se questo non significa che lo
studio dei patterns non sia utile anzi, penso sia essenziale.
Personalmente ho letto "Design Patterns: Elements of Reusable Object-
Oriented Software" della  Addison-Wesley. Ho provato molte volte ad
applicare i patterns a progetti su cui lavoro e, a parte per i
patterns Composite e Singleton che mi vengono naturali da applicare,
non ne ho usati. Per quanto riguarda il libro ritengo che la parte
introduttiva generale sia quella più interessante. In tale parte
infatti, si spiega la filosofia e le tecniche che stanno dietro ai
patterns e che li rendono così buoni (ad esempio: favorire
composizione all'ereditarietà...). Penso che quando una persona ha
propri questi concetti generali possa tranquillamente fare bene senza
sapere a memoria i patterns.

 sapere a memoria i patterns.
Secondo me studiare i patterns e' un ottimo modo per migliorarsi sia come
javisti che come allnamento alla logica pura.
Poi usarli o meno e' un dettaglio poco importante, verra' normale o comuqnue
anche non seguendoli alla perfezione il proprio modo di programmare e
arechitetturale sara' piu' profondo.
Quindi io consiglio a tutti di leggerne e studiarne il piu' possibile
L'unica cosa che raccomando, per esperienza e' di non farsi prendere da una
forma di maniacalita'. Mi successe di essere ingaggiato a risolvere uno
strano caso.
Un buon Architect aveva in mano un progettone di 7-8 mesi molto importante e
aveva la mania dei pattern. Poiche nel gruppo aveva anche persone poco
esperte successe che gli inesperti non entrarono mai in produzione e
comuqnue il progetto accumulo' un ritardo mostruoso perche' per dire "ba" ci
si faceva il giro del mondo.
Io arrivai e una volta capito che il problema era la over-patternizzazione
ebbi l'autorizzazione a infrangerli. Cosi' per la prima volta andai a
maciullare una architettura ( di solito mi piacciono le architetture
ordinate, anche se negli ultimi anni un po' meno, e tutto il team ci
sentivamo come dei bambini a cui vanno via i genitori e devastano la casa
:-)))
Alla fine riuscimmo a salvare il progetto, e comunque lasciammo i pattern
principali.
Ricordiamo infatti che i framwork attuali gia' incanalano verso i pattern.
Struts ad esempio e' piu' un pattern che un framework, solo per citarne uno
che conosciamo quasi tutti.
Per quanto riguarda l'Universita' si concordo che un corso di Pattern
secondo me e' un'ottima idea, per chi fa il piano di studi orientato allo
sviluppo sw. Infatti sono multilinguaggio e iperformativi per la mente.
Ciao a tutti
Nicola


 Struts ad esempio e' piu' un pattern che un framework [...]
Non sono d'accordo con questa affermazione. Struts è framework. Design 
pattern e framework sono due cose differenti.
Al massimo si può dire che in un framework si utilizzano alcuni design 
pattern.
