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).
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.
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 ...
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.


Rispondi quotando