Newsgroup: it.comp.java
Titolo: stile di programmazione

Ciao a tutti!
Vorrei farvi 2 domande riguardo allo stile di programmazione.
Il mio professore diceva che è assolutamente sbagliato usare le istruzioni 
break o continue all'interno dei cicli, o usare + di un return in un 
metodo. Ora io mi chiedo, perchè? Cosa c'è di male a usare queste tecniche, 
che, secondo me, se ben usate rendono + leggibile il codice.
La domanda n°2 riguarda la progettazione delle classi. Se non mi sbaglio è 
considerato un cattivo stile di programmazione il seguente:
public class Classe {
 public String attr;
 public Classe(String a) {
  attr=a;
 }
}
perchè si dovrebbe dichiarare attr private e definire i metodi pubblici 
getAttr e setAttr. Faccio questa domanda perchè devo costruire una classe 
con parecchi attributi, e mi sembra noioso e alquanto poco elegante stare a 
scrivere per ogni attributo
public String getAttr() {
 return attr;
}
e l'equivalente metodo setAttr. Quali problemi comporta dichiarare gli 
attributi pubblici rispetto all'altra soluzione. (tanto qualsiasi altra 
classe potrebbe comunque modificarne il valore anche se fossero dichiarati 
private tramite i metodi set.. e get..)
Grazie per l'attenzione.
Ciao :-)

 private tramite i metodi set.. e get..)
L'effetto è lo stesso però con get/set ti tieni la possibilità di
intervenire + comodamente qualora ad esempio di servisse azzerare una
variabile al richiamo di una certa set oppure contare le chiamate ad una
certa set (sono solo esempi banali)
Ciao

 e l'equivalente metodo setAttr.
IMHO č poco elegante non farlo.
Poi dipende dal fatto che tu voglia o meno che tutti gli attributi di una
classe siano visibili dall'esterno. Sempre IMHO.

 dichiarati private tramite i metodi set.. e get..)
I tuoi metodi set possono contenere validazione, localizzata appunto nel 
body di quel metodo. Se invece lasci pubblico l'accesso, ogni volta che per 
manutenzione devi modificare la validazione, devi trovare ed alterare ogni 
punto del codice in cui la variabile e' scritta.
Cio' detto, non e' che *devi* avere set/get per ogni attributo. Alcuni 
attributi sono esclusivamente privati; altri, sono in sola lettura, per cui 
_non_ hai metodi set. Quasi sempre, dal punto di vista della modellazione e 
della facilita' di manutenzione, e' meglio modellare classi carrier, ovvero 
le cui istanze incapsulano un valore ben preciso del dominio della classe. 
Il che significa che se ti serve un altro valore, crei un altro oggetto. Ad 
esempio, in java, prendi String.
Ovviamente la cosa ha un impatto sulle performance, specie per oggetti 
complessi che tendono ad avere overhead di costruzione piuttosto alti (per 
cui cioe' la differenza in tempo/spazio tra modificare un'istanza esistente 
e ricrearne una nuova non e' trascurabile).
Un pattern tipico consiste nel fornire oggetti "Xbuilder" (per inciso, non 
factory, che e' un'altra cosa) che producono istanze della classe X, che 
espongono setters e possono essere ottimizzati in modo da velocizzare 
l'operazione di costruzione di X. 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 con parecchi attributi, e mi sembra noioso e alquanto poco elegante stare
a
Poco elegante?
Conosci l'OOP?

 }
Perché uno degli scopi di un OOP è quello dell'incapsulamento dei dati.
Ogni oggetto deve essere responsabile di ciò che fa.
Quando tu usi un oggetto non ti importa e non dovrebbe importati di come
salva i dati al suo interno e di come lavora, ti deve importare la sua
interfaccia verso l'esterno.
Nel modo che dici tu sarebbe come dichiarare delle variabili globali.
Esempio CLASSICO: il contatore.
Tu progetti una classe che realizzi l'astrazione contatore in cui non ci
sono numeri negativi.
Partendo dal tuo presupposto potresti assegnare al campo INDICE per esempio
un numero negativo con brutte conseguenze forse per le classi che usano
l'interfaccia della classe e si aspettano come è lecito fare solo numeri
positivi.
Non so se ti ho reso l'idea cmq raramente il grado di complessità è così
basso e incapsulare i singoli dati all'interno di oggetti ti sarà
sicuramente di aiuto.
CybWLK