Newsgroup: it.comp.java
Titolo: Inizio con Java

Ciao a tutti,
provengo da anni di programmazione in php e all'inizio con C. Ora vorrei finalmente iniziare a vedere java per poi arrivare alle app android.
Mi sono cercato qualche libro, anche per affrontare l'argomento UML che credo sia molto utile e ho acquistato questi:
 
Dall'idea al codice con UML 2
Programmazione con Java
UML distilled: guida rapida al linguaggio di modellazione standard
 
Che ne pensate?
Avete consigli su come iniziare senza perdersi?
Per ora sto leggendo un librettino che avevo già preso tempo fa su uml ma è davvero incasinato. mi sono perso alle implementazioni delle associazioni, aggregazioni e composizioni con java... 
Anzi, potete farmi qualche esempio?
 
Grazie!


i miei 2 cent:
l'uml è utilissimo in ambiente condiviso, ma se fai tutto da te e non 
devi documentare non è che sia tutta sta utilità. Senz'altro progettare 
con formalismo da risultati buoni, ma io forse mi concentrerei ad essere 
operativo prima (tanto se già lavoravi con altro cmq immagino progettavi 
in qualche modo).
 
-- 
Z.


A dire il vero non molto, o almeno non con strumenti standard. Nei progetti php lavoro massimo in 2, quindi come hai ben detto, non abbiamo mai investito molto tempo nella progettazione grafica.
Il libro che ho preso lo conosci? Cosa ne pensi?
Per le implementazioni di quelle cose che ho scritto sopra?

 Avete consigli su come iniziare senza perdersi?
 
Secondo me, UML, in particolare diagramma delle classi, di sequenza e 
use case, sono fondamentali. Inoltre aggiungerei la conoscenza dei 
pattern, almeno i principali. E questo serve per la programmazione in 
qualunque linguaggio.
 
Tutto cio' va poi tarato sul tipo di software che dovrai scrivere. 
Applicazioni gestionali, realtime, di rete o webapps, utilizzano piu' 
frequententemente un pattern invece di un altro.
 
Ti consiglio, parallalamente allo studio sui libri, una volta 
individuato il tuo target di tipo di software che devi sviluppare di 
trovare sulla rete (in ambito universitario facile che si trova) un 
esempio di documentazione completa di un progetto (analisi requisiti, 
casi d'uso, diagrammi uml, ...) per vedere casi reali completi.
 
Ciao.

 qualunque linguaggio.
 
LOL
 
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 Anzi, potete farmi qualche esempio?
 
dimenticati UML.
Inizia ad imparare solo Java, poi se ti va impari solo l'UML e poi se ti
va cerchi di capire come usarli insieme.
 
Evita gli IDE, scaricati l'SDK e usa un semplice editor di testi (ad
esempio c'e' Textpad che mi piace molto).
 
Fatti un bookmark di questo link:
http://docs.oracle.com/javase/7/docs/api/
 
e' la tua bibbia.


 esempio c'e' Textpad che mi piace molto).
 
L'unico motivo per cui avvallerei la tua affermazione e` perche` si rischia 
di diventare IDE dipendenti. Peccato pero` che facendo tutto a mano rischi 
invece di buttare tutto in quanto diventa un'attivita` tediosa e prolissa 
(hint: usare un'IDE e` una cosa buona se usata con criterio, ovvero prima 
capire, poi fare)
 
Enrico


non intendevo per sempre. Intendevo per imparare.
 
A proposito: conosci un plugin per Eclipse che permette di creare
graficamente le GUI (finestre, bottoni, textfield, ecc.)


 graficamente le GUI (finestre, bottoni, textfield, ecc.)
 
con quale libreria? ricordavo che c'era il bindind delle Qt per java che 
offriva anche il designer come plugin per eclipse...
 


Swing.


 graficamente le GUI (finestre, bottoni, textfield, ecc.)
 
Ai tempi usavo Jigloo, poi sono passato a NetBeans e non mi sono piu` 
interessato
 
Enrico

 credo sia molto utile e ho acquistato questi:
 
ma lascia perdere uml, avrai tutto il tempo di capire se ti servirà o no 
(vedrai sarà più no che si).
 
prenditi un libro fra quelli consigliati su amazon per preparare la 
certificazione scjp (es. 
http://goo.gl/hiRzd
) e anche se non fai l'esame 
studia su quello. è importante apprendere il linguaggio a partire dai 
formalismi corretti per non incappare nei classici difetti dei 
"praticoni" che usano (e male) solo una piccola frazione del linguaggio. 

 (vedrai sarà più no che si).
 
Dissento totalmente qui.
 
Per mia esperienza da progetto piccolo a grande (~100.000 righe di 
codice) la differenza l'ha sempre fatta la progettazione che viene PRIMA 
di scrivere la prima riga di codice.
 
(da analista) ho visto super-programmatori che dopo 5 minuti che gli hai 
spiegato cosa fare cominciano a scrivere il codice e magari a fine 
giornata hanno gia' finito ma scrivendo classi-duplicato, sbagliando 
ereditarieta' e incapsulazione, non usando un singleton dove sarebbe 
necessario.
 
Altri invece perdono i primi due giorni a farti diagrammi di classe e di 
sequenza ma poi anche se non ti scrivono un codice sintatticamente 
perfetto e' 1000 volte piu' estendibile e mantenibile.
E quando lo riprendo in mano a distanza di mesi mi e' ancora tutto 
chiaro. A differenza dei super-programmatori del caso 1 che fanno tutto 
in fretta e senza pensare prima di scrivere.

 non usando un singleton dove sarebbe necessario.
 
tra i tanti pattern, proprio quello che non andrebbe mai usato?
E ci credo che son bravi programmatori :P

 tra i tanti pattern, proprio quello che non andrebbe mai usato?
 
Esagerato...
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/juli/logging/LogFactory.java
 

 tra i tanti pattern, proprio quello che non andrebbe mai usato?
 
Perche`?
 
Enrico

 e senza pensare prima di scrivere.
 
quando io dico che di uml se ne può fare benissimo a meno non sto dicendo 
di scrivere il codice senza pensare. semplicemente non credo nell'utilità 
di uml nel progettare correttamente il codice, tutto qua. le ragioni sono 
insite nello stesso linguaggio che non avendo una notazione formale non 
può in alcun modo garantire che tu segua una metodologia di sviluppo 
corretta. in altre parole se sbagli l'ereditarietà scrivendo le classi 
direttamente in java non c'è motivo di pensare che non commetteresti gli 
stessi errori scrivendo le stesse su un diagramma di classe visto che uml 
non ha nessuna pretesa di guidarti in questo senso, lo stesso dicasi 
della manutenibilità del codice e della sua estensibilità. 
 
 
 
 

 della manutenibilità del codice e della sua estensibilità.
 
Ehm, sarebbe come dire: non c'e' motivo di pensare che non commetteresti 
gli stessi errori scrivendo un progetto di una casa, tanto vale 
cominciare a costruirla.
 
Si chiama modellazione.
 
Comunque lasciamo perdere, tonnellate di libri sull'ingegneria del 
software per fortuna sono stati gia' scritti e studiati, e io non voglio 
certo stare qui a difenderli.
 
Ciao, ciao.

 certo stare qui a difenderli.
 
Se è per quello su tale argomento sono anche stati scritti e studiati 
tonnellate di libri che francamente sarebbe meglio non cercare di 
difendere. Credo nessuno metta in dubbio che i buoni principi di 
progettazione del software siano utili, ma non sono certo un requisito 
fondamentale per essere un buon programmatore.
 
Soprattutto non mi sembra un buon consiglio da dare a chi probabilmente 
vuole principalmente imparare a programmare bene in un linguaggio, 
quello di passare settimane, se non mesi a studiarsi una cosa 
probabilmente per lui attualmente inutile come l'UML. Ok, ha cominciato 
lui dicendo che libri aveva comprato...proprio per questo probabilmente 
andrebbe un guidato su un percorso un po' più semplice e progressivo (e 
probabilmente più produttivo), visto che si è "perso alle 
implementazioni delle associazioni, aggregazioni e composizioni".
 
Meglio per lui prima diventare fluent nel linguaggio che ha deciso di 
imparare, per poi approfondire le buone pratiche di progettazione 
software. Se per ragionare su ciò che deve sviluppare poi sentirà il 
bisogno di strumenti come l'UML, ben venga, se lo imparerà...ma credo 
che quasi sempre la "carta del salumiere" probabilmente gli sarà 
sufficiente. Molto meglio forse se prima (sempre dopo aver imparato bene 
il linguaggio) si dedica ad imparare tecniche come il refactoring e il 
testing, no? Già con queste poi le buone pratiche di sviluppo emergono 
un po' da sole.
 
So che mi ripeto, ma secondo me è fondamentale diventare "fluent" nel 
linguaggio che si utilizza. Uno sviluppatore non può concentrarsi su ciò 
che deve realizzare se non ha la padronanza del linguaggio che userà, 
esattamente come facciamo fatica ad esprimere concetti complessi in una 
lingua che non conosciamo bene (possiamo anche averli in qualche forma 
nella testa, ma non riusciremo a comunicarli completamente). La faccenda 
che basta progettare bene, che poi la realizzazione in un linguaggio 
qualunque è una cosa da scimmie programmatrici, si è rivelata troppe 
volte una favola, per considerarla ancora vera.
 
Ciao
   Lucio
 
 
-- 
Lucio Benfante       
http://www.lambico.org
 
JUG Padova           
http://www.parancoe.org
 
www.jugpadova.it
 
http://www.jugevents.org
 

 vanno più che bene
 
:) Purtroppo non mi convinci assolutamente. Per mia (lunga) esperienza 
e' cosi', tu avrai avuto altre esperienze.
Io poi non sono uno che estremizza, in questo ng mi pare ci che sia il 
gioco del tirare tutto all'estremo.
Ma quando mai ho detto che bisogna passare il tempo a scrivere documenti 
di progettazione e mettere in secondo piano la conoscenza del 
linguaggio? Ritengo invece che le due cose siano parimenti importanti. 
All'inizio porrei sicuramente maggiormente l'attenzione sul linguaggio e 
col tempo aumenterei il tempo alla progettazione.
 
Ma dire invece che la progettazione sia inutile, se non dannosa, come la 
maggior parte hanno detto qui, mi sembra assurdo.
 
Non e' cosi' in nessun campo tecnico, non vedo perche' il software 
dovrebbe fare differenza... Ciao.


Grazie Lucio e grazie Coder, comunque ho capito cosa volete dire entrambi e trovo corretto identificare un punto intermedio.
In effetti non ha molto senso passare 3 mesi a studiare uml senza leggere una riga di java, d'altro canto un po' di uml fa comodo visto che, sfogliando l'indice, ho visto che il libro di java che ho preso, ha un capito dedicato a uml.
Quindi credo sia logico pensare che uml sia uno strumento che arrivi conseguenzialmente :) poi Io spesso mi incarto perchè mi impunto e questo mi fa perdere tempo :(

 maggior parte hanno detto qui, mi sembra assurdo.
 
La progettazione non e' dannosa, UML, e in generale tutto quello che e'
ingegneria del sw, si.
Ho visto fin troppo spesso "programmatori/analisti" che sono bravissimi
ad inondarti di carta con su diagrammi vari, ma poi quando c'e' da
scrivere codice hanno probliemi a capire la differenza tra un for() un
while() e un do...while().
 
In genere preferisco lavorare con gente che abbia il cervello
funzionante e acceso, piuttosto che con gente che mi racconta a memoria
i nomi dei pattern o dei diagrammi UML...


 costo zero
 
Quoto.
 
http://chrisaitchison.com/2011/05/03/you-are-not-a-software-engineer
 
 
Non siamo ingegneri, ma giardinieri ;)

 certo stare qui a difenderli.
 
di certo non tutto quello che è stato scritto contempla l'uso di uml nel 
processo di realizzazione del software.   

 Non siamo ingegneri, ma giardinieri
 
A parte che non c'e' bisogno di essere ingegneri ma solo conoscere una 
simbologia (UML) per mettere su carta le proprie idee in modo razionale 
e non inventandosi ogni volta una nuova simbologia,
i commenti di quell'articolo non sono tutti entusiastici.
Non si puo' fare sempre di ogni erba un fascio, anche solo il programma 
di una macchina a controllo numerico, un sito di una banca, un sito di 
ecommerce utilizzato da centinaia di professionisti al giorno per il 
proprio lavoro, non e' un lavoro da giardiere.
 

 processo di realizzazione del software.
 
Mi sembra veramente che si sia stato fatto un caso per una cosa da 
nulla. Io non ho mica detto che prima di scrivere un progetto bisogna 
passare attraverso un processo di progettazione predefinito.
 
Ho solo detto che e' utile pensare alle classi e alle loro interazioni 
prima di scrivere del codice e che per farlo, invece di inventarsi una 
simbologia nuova ogni volta, esiste quella gia' offerta dall'UML.
 
Ciao.


In effetti ho dato vita a un bel casino eh? :P

 In effetti ho dato vita a un bel casino eh? :P
 
Ma no figurati, colpa mia che ho frainteso un po' il tuo incipit: 
"provengo da ANNI di programmazione in php e all'inizio con C.", "Mi 
sono cercato qualche libro, anche per affrontare l'argomento UML".
 
Avevo inteso che eri gia' molto pratico di programmazione e che ora, 
oltre a java ti interessasse soprattutto il lato "progettazione".
 
No problem, ciao e divertiti :)
 

 Perche`?
 
9/10 Monostate e' piu' efficace, per dire. Noi lo conosciamo come Borg,
ma sempre lui e'. Il fatto e' che, in Java, Singleton e' molto piu'
facile da implementare. Questo per stare sullo standard, senza andare
nel filosofico.
 
-- 
-riko
http://www.enrico-franchi.org/
 
http://rik0-techtemple.blogspot.com/
 

 maggior parte hanno detto qui, mi sembra assurdo.
 
Nel caso non si sta parlando del fatto che la progettazione sia inutile:
si sta parlando che non necessariamente questa debba passare per UML. 
 
Poi aggiungo, fra il BDUF e la non progettazione ne passa, eh.


 ingegneria del sw, si.
 
Il problema non e' la disciplina "ingegneria del software". Il problema
e' farla male. Tra l'altro l'informatica e' una disciplina giovanissima
e per lunghi anni non e' stato nemmeno tanto possibile fare le cose per
bene[0].
 
Il SE ha fatto errori. Buona parte dei quali sono stati prendere pattern
da altre discipline ingegneristiche con caratteristiche pesantemente
diverse (e.g., ingegneria meccanica o edilizia). D'altra parte veniva
naturale.
 
Ecco, oggi e' il caso di staccarsi. Ma non e' che dobbiamo abolire il
concetto di ingegnerizzare per bene il software.
 
 
 
 
----
[0] gran cosa, per dire, la garbage collection. pero' quando vai a 1 MHz
e il GC ti inchioda la macchina per 30 secondi *magari* non e' una buona
idea. 


 simbologia nuova ogni volta, esiste quella gia' offerta dall'UML.
 
Scusa, ma non e' detto che per pensare a classi e interazioni devi avere
una simbologia *diversa* da Java. Ora posso capire che per un activity
diagram Java (o qualunque altro linguaggio general purpose) sia
terribilmente inadeguato.
 
Per il resto fatte le storie (o gli activity diagram, se proprio ci
piace UML), progettata l'architettura, schizzato il design, puoi
ampiamente partire a fare TDD.
 
La verita' fondamentale e' che se uno e' cane e' cane. Se hai un cattivo
designer, il progetto fara' cagare. Quante volte arriva in sviluppo un
progetto che fa talmente acqua da dovere essere ignorato o quasi? Se hai
cattivi sviluppatori, anche se hai un eccellente progetto, il risultato
fara' cagare. Fara' cagare se hai usato UML. Fara' cagare se hai
scarabocchiato sulla carta del salumiere. 
 
Per ogni metodologia di sviluppo anche sensata avrai fallimenti
spettacolari dovuti a cattivi professionisti. Se invece hai buoni
professionisti, puoi anche rilassare vincoli formali e quello che
ottieni sta in piedi.
 
Poi cosa devi fare? Stai mettendo su un prodotto innovativo con un TTM
di 3 mesi oppure stai mettendo mano al sistema informativo di una
pubblica amministrazione che e' in giro da 10 anni e che deve essere
pronto (nella nuova versione) fra 3? 


 9/10 Monostate e' piu' efficace, per dire.
 
Sono due pattern differenti, e si usano in situazioni differenti.
Non ha senso affermare che uno sia meglio dell'altro, se non si conosce il problema da risolvere.
 
Sembra che qui si faccia a gara per essere i piu' /trendy/ mettendo da parte il buon senso; mica giochiamo a fare le modelle! neanche chi usa un mac dovrebbe arrivare a tanto!
 
-- 
SoulSpirit

 bene[0].
 
Il fatto e' che manca molto la cultura relativa alla progettazione, particolarmente in Italia (a parte in qualche ambito particolare).
In genere il cliente vuole il software funzionante, e non gliene frega niente di cosa ci sia sotto. E i furbacchiotti italiani ne approfittano tagliando sui costi di progettazione:
"Tanto con una botta qua e una martellata la' riusciamo a farlo funzionare.".
 
-- 
SoulSpirit

 Ciao Jack
Saluti Patrick
 

 mac dovrebbe arrivare a tanto!
 
Ora, capisco tutto, ma come si fa ad essere trendy citando roba di
almeno 10 anni fa, verosimilmente 15? Se avessi voluto essere trendy
avrei parlato di altro, no? 


 "Tanto con una botta qua e una martellata la' riusciamo a farlo funzionare.".
 
Si ma la botta qua e la martellata là non sono figli di una mancata 
formalizzazione su UML o altri formalismi del progetto software che si 
va ad affrontare.
 
Nella mia modesta esperienza sono figli di incapacità di programmazione, 
la non conoscenza del paradigma OO e mancanza di test automatici (e 
ambienti di CI).
Soprattutto l'ultimo punto, che solitamente non viene compreso a partire 
dalla testa per cui diventa impossibile renderlo una pratica effettiva 
all'interno del team di sviluppo, con risultati nefasti.


Hai una evidente difficoltà a scindere i concetti di "progettazione
del software" e "UML". Diverse persone hanno finora tentato di farti
capire che i due concetti, non vanno di pari passo. Tu piuttosto
affermi che non è possibile prescindere dall'uso di UML, pena il
raggiungimento dello stato di "non progettazione" del software a cui
si lavora. Hai anche affermato, sempre a proposito di UML:
 
"E questo serve per la programmazione in qualunque linguaggio."
 
Per convincerti che sbagli, ti basterebbe pensare che al mondo
esistono milioni e milioni di righe di codice non Object-Oriented
scritte nei linguaggi più disparati che dell'UML non è che non sanno
che farsene, _non sanno proprio cosa sia_. E già questo basterebbe e
avanzerebbe per confutare la tua posizione.
 
Sta a te decidere se continure a tenere la testa sotto la sabbia e
leggere Pressman/Sommerville/e compagnia ricavandone quello che ne
ricavi *tu*[0] o fare esperienze diverse e documentarti meglio in giro
per il mondo.
 
[0] Benchè quei libri li abbiano letti in tanti, parrebbe che non
tutti ne ricavino il messaggio "UML è vita". Tutt'altro, semmai.