Discussion :

[remotesolo]

Bonjour à tous les experts java qui passeraient par là car j'ai besoin de vos lumières !

Je m'explique : dans un projet perso j'ai une classe java (toto) qui est "serializable" et j'ai créé 2 fonctions toto.backup() et toto.restore() pour sauvegarder l'état des données de l'objet en mémoire (dans un byte[]) , puis restaurer cet état quand j'en ai besoin.

Pour sérialiser via toto.backup(), pas de soucis c'est automatique grâce au mécanisme java (je peux ajouter de nouveaux champs de données dans la classe et ils seront pris en compte sans écrire une ligne de code).

Par contre pour "désérialiser" via toto.restore() , vu que "this" est read only , je dois passer par un objet temporaire (tmp) puis affecter par code
this.x=tmp.x this.y=tmp.y etc... du coup si j'ajoute des champs de données je dois aussi ajouter des lignes de code dans la fonction restore() [d'où un risque d'oubli et de bugs]

Question: est-il possible d'automatiser le toto.restore() pour qu'il restaure tous les champs via un mécanisme de reflexion (que je n'ai jamais utilisé) ou autre ?

Si vous avez un petit exemple ça serait top

[remotesolo]

Je crois que j'ai trouvé on doit pouvoir s'en sortir avec l'objet "reflect.Field" en utilisant getModifiers().

Mais du coup j'ai une question subsidiaire: en plus de FINAL et TRANSIENT quels autres type de champs je ne dois pas tenter de restaurer ? (comme volatile par ex ?)
Pour l'instant je vais me contenter de ces 2 là, mais si quelqu'un peut completer la liste ça m'aiderait !

[millie]

En général, cela ne devrait pas être de la responsabilité de l'objet de soit-même se backuper/restorer (surtout avec de la serialization)
Cela devrait plutôt être la responsabilité d'une autre classe dédiée.

Maintenant, c'est à discuter/modérer en fonction du besoin.

Dans le cas d'une "auto-serialization", il vaut mieux tout de même passer par une classe interne privée.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
public class MonObjet {
 
   private MonObjetInterne intern = new MonObjectInterne();
   private byte[] backup;
 
   class MonObjetInterne implements Serializable {
         private String field;
         //getter setter
   }
 
   public String getField() {
      return intern.getField();
   } 
 
   public void backup() {
       //derialization de l'objet interne puis set dans backup
   }
}

Maintenant, je trouve ça assez goret et il faudrait vraiment voir ton besoin.


Si tu utilises du transient et du volatile, c'est que tu es déjà sur un truc assez tordu.
Sinon, comme ça, je ne vois pas de contre indication particulière.

[remotesolo]

Effectivement ta solution est plus élégante et je confirme que dans mes projets persos je programme souvent comme un goret pour aller au plus simple/au plus vite

Moi pour éviter une "surclasse" en fait j'ai déclaré "backup" comme transient (du coup il n'est pas sérialisé), mais j'avoue c'est pas terrible comme façon de faire

Après pourquoi j'ai voulu faire un objet qui s'autobackupe/restore c'est parce que j'avais déjà une classe qui fait des traitements assez complexes (simulations) et j'ai voulu faire en sorte que la classes auto adapte ses paramètres à des instants précis de la simulation (du coup je dois faire des simulations dans la simulation en cours pour choisir les paramètres [une sorte de récursion de traitement mais à un seul niveau de récursion]).

C'est l'approche la plus simple que j'ai trouvée pour arriver à mes fins mais je suis preneur d'idées pas trop compliquées et plus élégantes.