attributi privati, è buona norma usare getCampo()???

[Caiodark]

Originariamente inviato da Kaamos
E se il valore passato non è corretto cosa fa il tuo metodo?

Io sto solo contestando l'astrazione, set non mi dice che è in corso una validazione. Di più, la validazione è un concetto diverso dal set di una variabile, per il principio della separation of concerns dovrebbero stare su metodi differenti.

P.e. un form su una pagina web viene prima compilato e successivamente validato.

Le eccezioni esistono apposta: il valore non viene impostato (quindi l'oggetto non si trova in uno stato indefinito) e il chiamante sa di avere commesso un errore.
Si può usare una banalissima IllegalArgumentException.

L'eccezione esiste per gestire gli errori, qui gli stai demandando un compito di validazione che è cosa diversa.
Si possono usare le eccezioni per gestire la validazione, ma è un metodo tra i tanti che si possono usare e non sempre è il migliore.

[Kaamos]

Originariamente inviato da Caiodark
Dovrebbe essere il tipo a garantire il controllo del range, mi spiego dopo...



Questo accade se il tipo usato per rappresentare il concetto di dominio è un generico tipo int o Integer in luogo (p.e.) di una classe Minutes. La classe Minutes dovrebbe essere una classe concreta che implementi il concetto di minuti così come il dominio del problema richiede (p.e. un range di interi da 0 a 59).

Solitamente invece si tende a dichiarare le proprietà di tipo primitivo, soprattutto per le variabili che incapsulino il concetto di quantità, perché usare classi concrete in Java è più scomodo che non usare i tipi predefiniti (occorre ridefinire i concetti p.e. di somma, non sarebbe possibile utilizzare gli operatori del linguaggio come +).

Ma facendo questo si rinuncia all'information hiding perché si espongono dettagli implementativi (p.e. che i minuti sono salvati in integer) e abbiamo un programma meno manutenibile.
Immagina se un domani ci venisse chiesto di cambiare il concetto di minuto gestendo anche i secondi come parte decimale, si sarebbe costretti ad utilizzare i float e a modificare tutti i metodi che chiedano dei minuti come parametri.
Invece gestendo una classe concreta sarebbe l'unica che dovrebbe essere modificata da una simile richiesta.



La classe, secondo il principio di information hiding, dovrebbe essere una sorta di black box.
Metodi e proprietà private dovrebbero rimanere tali affinché sia la classe stessa a gestire il proprio stato.
I metodi getter e setter invece fanno sì che la classe non abbia piena responsabilità del proprio stato e sia costretta a proteggersi da se stessa.

Non è un caso che le classi più ricche di metodi getter e setter siano le classi entità che non hanno praticamente alcuna intelligenza.

Siamo sempre lì: la classe "wrapper" avrà a sua volta dei metodi setter per impostare il valore, e questi hanno di nuovo il problema di prima.

[Kaamos]

Originariamente inviato da Caiodark
Io sto solo contestando l'astrazione, set non mi dice che è in corso una validazione. Di più, la validazione è un concetto diverso dal set di una variabile, per il principio della separation of concerns dovrebbero stare su metodi differenti.

P.e. un form su una pagina web viene prima compilato e successivamente validato.

L'eccezione esiste per gestire gli errori, qui gli stai demandando un compito di validazione che è cosa diversa.
Si possono usare le eccezioni per gestire la validazione, ma è un metodo tra i tanti che si possono usare e non sempre è il migliore.

Non capisco, cosa cambia fra errore e validazione non andata a buon fine?

Riguardo al significato del set, è indubbiamente vero, ma come ho detto nel post sopra, quando ti trovi nella classe che "concretizza" il range di valori validi, come li imposti? Il set ricevendo un tipo più generale, secondo il tuo ragionamento, non puoi farlo...

[Caiodark]

Originariamente inviato da Kaamos
Siamo sempre lì: la classe "wrapper" avrà a sua volta dei metodi setter per impostare il valore, e questi hanno di nuovo il problema di prima.

Nope, la classe avrà il costruttore opportuno per essere inizializzata e dei metodi pubblici per gestire le operazioni necessarie che non espongano direttamente la variabile che contiene materialmente il dato ne' il tipo con cui è stata dichiarata.

In questo modo incapsuli il concetto di Minuto e ne nascondi l'implementazione, inoltre è la classe che si gestisce il suo stato. Perché mai avresti bisogno di un setter di un oggetto Minuto già istanziato?

[Kaamos]

Originariamente inviato da Caiodark
Nope, la classe avrà il costruttore opportuno per essere inizializzata e dei metodi pubblici per gestire le operazioni necessarie che non espongano direttamente la variabile che contiene materialmente il dato ne' il tipo con cui è stata dichiarata.

In questo modo incapsuli il concetto di Minuto e ne nascondi l'implementazione, inoltre è la classe che si gestisce il suo stato. Perché mai avresti bisogno di un setter di un oggetto Minuto già istanziato?

Quindi il costruttore può fare i controlli ma i setter no?

[Caiodark]

Originariamente inviato da Kaamos
Non capisco, cosa cambia fra errore e validazione non andata a buon fine?

Non mi sono spiegato, anche l'errore lo puoi gestire con metodi diversi dall'eccezione. Per esempio ritornando un valore al di fuori da un range valido (p.e. una lista ti ritorna -1 se non trovi l'oggetto che cerchi, non solleva una eccezione).
Il sollevamento di una eccezione è una tecnica, tra le tante, per gestire gli errori.

Riguardo al significato del set, è indubbiamente vero, ma come ho detto nel post sopra, quando ti trovi nella classe che "concretizza" il range di valori validi, come li imposti? Il set ricevendo un tipo più generale, secondo il tuo ragionamento, non puoi farlo...

Il set si fa al momento della prima istanziazione. Ripeto, perché dovresti fare il set in un oggetto concreto già istanziato?

[Caiodark]

Originariamente inviato da Kaamos
Quindi il costruttore può fare i controlli ma i setter no?

Compito del costruttore è restituirti un oggetto, se gli passi una ciofeca non riesce a costruire l'oggetto e non ti trovi con una istanza "invalida".

Da quel momento in poi hai un oggetto valido che si conserva tale.

[Kaamos]

Originariamente inviato da Caiodark
Compito del costruttore è restituirti un oggetto, se gli passi una ciofeca non riesce a costruire l'oggetto e non ti trovi con una istanza "invalida".

Da quel momento in poi hai un oggetto valido che si conserva tale.

Io consideravo il costruttore come un insieme di setter, invece hai ragione, concettualmente è del tutto corretto come dici tu, anche se nella pratica può complicare le cose (ma resta possibile e quindi in una filosofia OO sarebbe un sacrificio giusto).
Grazie dei lunghi post, mi è stato utile ed è interessante.

Fra l'altro, le librerie del linguaggio non sono sempre così "raffinate".

(mi scuso per aver deviato il topic, visto che il titolo parlava di getter...)

[Who am I]

@caiodark: questo metodo di programmazione (quello che hai detto te) è efficate, soprattutto se la classe minuti è immutable (oppure si fa una classe contatore generica da cui poi eredita la classe minuti), però continuo a non vedere lo svantaggio dell' utilizzare un metodo setter che fa i controlli sui campi come ho detto nel caso di minuti.

[Caiodark]

Originariamente inviato da Who am I
@caiodark: questo metodo di programmazione (quello che hai detto te) è efficate, soprattutto se la classe minuti è immutable (oppure si fa una classe contatore generica da cui poi eredita la classe minuti),

Le classi concrete sono tipi, non ereditano (anche se comunque ereditano da Object per l'implementazione degli oggetti che ha Java) ne sono ereditati.
Devi pensare a Minuto come ad un omologo dei tipi Integer, Double o String. Come quelle classi Minuti fornirà metodi per essere creato in modo corretto, rappresentazioni adatte a seconda del contesto (per esempio uno specifico metodo toString()), e metodi attivi come l'incremento.
In questo modo incapsuli il concetto di Minuto in una classe e astrai l'applicazione dall'implementazione di Minuto.

però continuo a non vedere lo svantaggio dell' utilizzare un metodo setter che fa i controlli sui campi come ho detto nel caso di minuti.

Lo svantaggio è che ovunque ti serva il concetto di minuto tu dovrai duplicare il codice della validazione, qualora tu fossi costretto a cambiarne l'implementazione (o la rappresentazione) questo si rifletterà direttamente in tutte le parti dell'applicazione che ne ha a che fare.
Altro enorme svantaggio, il controllo di validità ce lo avresti solo a runtime mentre il controllo dei tipi è a compile time.
Immagina codice come questo:

//time in milliseconds
int time = 950;
//... qualche decina di righe dopo...
entity.setMinutes(time);

E' perfettamente compilabile, ma l'applicazione solleverebbe l'eccezione in runtime. Ora qui l'errore è perfettamente comprensibile, ma immagina la stessa situazione con nomi di variabili più ambigue e parecchie righe di codice nel mezzo.

Invece:

class entity {
 private Minute minutes;

 setMinutes(Minute minutes){
   ...
 }
}

Millisecond time= 950;
//... qualche decina di righe dopo...
entity.setMinutes(time);

Questo codice darebbe errore a compile time.
Come esempio ho usato una classe entità, perché è quella dove in java, soprattutto in java ee, è quasi inevitabile avere i getter / setter.