eh eh non ho bisogno di un esempio, grazie :), la tua osservazione e'
corretta ovviamente, e va tenuta in conto anche usando lombok o i getter, e
come sicuramente sai, in tutti i casi di logica concorrente. Pero',
appunto, i miei oggetti da "trasporto" sono molto stupidi e, nel caso sia
richiesto, mi proteggo nel costruttore creando versioni immutabili. Se ti
trovi a fare cose complicate, lo stai facendo sbagliato :)

In generale, comunque, devo ammettere che che raramente la mutabilita di
questo tipo di oggetti è per me rilevante: appena uno di essi mi entra
nella zona "OO" viene immediatamente assimilato e dimenticato.

A riguardo della tua osservazione sui tipi ricorda che questi oggetti
"tristi" (o quelli "ignoranti" di Fede) si usano solo quando hai un
paradigm shift, raramente i tipi hanno rilevanza. Caso classico un API REST
che riceve una chiamata in formato misto json/xml/whatever: il massimo
dell'astrazione sono mappe/array/stringhe.

Direi che siamo pienamente in topic comunque :)

Ciao,

    Bruno

On 23 Jan 2018 19:07, "Ramon Flamia ramon.fla...@gmail.com
[it-torino-java-jug]" <it-torino-java-jug@yahoogroups.com> wrote:

>
>
> *"*
>>
>> *[...] se mi consenti una considerazione.... public final nei campi va
>> bene fino ad un certo punto,*
>
>
>> *con oggetti mutabili credo che si lasci la porta aperta a disastri*
> *Scusa, c'e' uno "static" di troppo. Sono public final e, pertanto, non
> mutabili. L'unico modo per "caricarli" e' con il costruttore*
>
>
> *Ciao,*
>
> *    Bruno"*
>
>
> La sostanza non cambia: se uno dei field esposto come public final è
> mutabile (es. java.util.Date o una qualsiasi Collection) allora la classe
> che crei non è immutabile ed è possibile che un client che la usa possa
> invalidare gli invarianti che sono stati definiti; molto meglio proteggere
> l'informazione a mio avviso (se vuoi ti faccio un esempio).
>
> Siamo andati un po' OT comunque... :-)
>
> Ho visto le mappe che ha indicato Federico e non fanno al caso mio:
> dall'esempio che ho visto su GitHub mi sembra che si perdano tutti i
> benefici di avere un compilatore e un linguaggio tipizzato solo per evitare
> di scrivere setter e getter; ci sono altri modi IMHO.
>
> Ciao,
> Ramon
> 
>
            • ... Andrea Cerisara andreaceris...@gmail.com [it-torino-java-jug]
  • Re: [Jug-T... Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]
    • Re: [... Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]
      • R... Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]
  • Re: [Jug-T... Ramon Flamia ramon.fla...@gmail.com [it-torino-java-jug]
    • Re: [... Federico Tomassetti f.tomasse...@gmail.com [it-torino-java-jug]
  • Re: [Jug-T... Ramon Flamia ramon.fla...@gmail.com [it-torino-java-jug]
  • Re: [Jug-T... Ramon Flamia ramon.fla...@gmail.com [it-torino-java-jug]
    • Re: [... bruno bossola bboss...@gmail.com [it-torino-java-jug]
  • Re: [Jug-T... Ramon Flamia ramon.fla...@gmail.com [it-torino-java-jug]
    • Re: [... bruno bossola bboss...@gmail.com [it-torino-java-jug]
  • Re: [Jug-T... Ramon Flamia ramon.fla...@gmail.com [it-torino-java-jug]

Reply via email to