Quote Originariamente inviata da Ansharja Visualizza il messaggio
Qui sorge qualche dubbio: come faccio a essere sicuro di leggere valori "corretti", senza che il file sia stato "sporcato"?
La serializzazione degli oggetti non fornisce di per sé alcun controllo sulla "integrità" dello stream. A parte header, prefissi, codici speciali ecc.. tutto il resto sono esattamente i dati in binario come sono. Cioè es. int in Java ha 32 bit e sullo stream sono appunto quei 32 bit, 4 byte in sequenza né più né meno. Le stringhe sono invece in un modified UTF-8 (una forma di UTF-8 con due varianti rispetto allo standard) quindi intelleggibili anche solo con un editor esadecimale.

Quindi se qualcuno va a smanettare (maliziosamente o no) sui byte del file, se cambia le parti dei dati ... beh, li può cambiare esattamente come li scriverebbe la applicazione. Se tocca header, prefissi ecc.. chiaramente sballa l'intero stream.

Se vuoi una qualche forma di signature e/o cifratura, chiaramente puoi farla, tu ovviamente (la serializzazione non ne dovrebbe sapere nulla).

Quote Originariamente inviata da Ansharja Visualizza il messaggio
In pratica stavolta alla prima chiamata l'oggetto Preferences viene letto da file, e poi controllo la validità dei campi utilizzando i metodi getter sulla istanza restituita da readObject().
Se ci sono logiche particolari, per cui certi valori sono ristretti in un certo range oppure più valori sono correlati tra di loro, allora un controllo di validità di queste logiche è chiaramente saggio e ottimale. Nulla da eccepire.

Quote Originariamente inviata da Ansharja Visualizza il messaggio
In caso di errori sostituisco quindi l'istanza con una creata dal costruttore che setta solo i valori di default.
Potrebbe avere anche senso lanciare una eccezione (errori di I/O, errori logici ecc...) e NON toccare instance che resta a null e quindi il getInstance potrebbe essere rieseguito.
Ma è questione di scelte ...

Quote Originariamente inviata da Ansharja Visualizza il messaggio
Infine un altro consiglio di design: voglio aggiungere per l'utente la possibilità di scegliere tra diversi "stili".
Cambiando stile verrebbero modificate impostazioni come il colore di sfondo dell'interfaccia, il colore del testo, dei bordi delle tabelle e molto altro.
Per queste carattaristiche volevo gestire una classe a parte, ColorSet, con vari campi che memorizzano i colori scelti.


Ha senso incapsulare l'oggetto ColorSet all'interno di Preferences ? E come salvare il set di colori scelto ?
Ad esempio è meglio memorizzare l'indice di un ipotetico array o mantenere un reference al ColorSet scelto, cioè va bene scrivere/leggere su file il reference a un campo della classe ?
Sì, chiaramente dovrai aggiungere tutti i campi necessari in Preferences. Non è di per sé un design sbagliato se la Preferences si ingrandisce un po' tenendo strutture dati più complesse o oggetti più annidati.

Sul fatto di tenere un indice vs tenere il reference dell'elemento scelto, così su due piedi, io opterei per l'indice.
Però sarebbe meglio incapsulare la logica di gestione dell'elemento scelto, mi spiego meglio: io farei una classe es. ColorTheme (che è un singolo tema) e poi es. un ColorThemes (che è un insieme di temi con uno selezionato logicamente). E in Preferences metterei ColorThemes.