Discussion :

[rockeye]

Bonjour,

J'essaye, autant que je peux, de choisir le meilleur design pour mes classes, mais là je suis aboulique.

A chaque fois que je dois implémenter des méthodes de sauvegarde/chargement, je me pose la question du design le mieux adapté. Pour trancher une bonne fois pour toute, j'utilise mon joker : "je demande au public JP".

Je vois 2 solutions (pseudo code c++):

SOLUTION 1 :
class Foo
{
void Load();
void Save();
};

dans le code, l'appel ressemble a ca :

Foo fooInst;
fooInst.Load();

En gros, chaque instance sait s'autogérer

ou

SOLUTION 2
class Bar
{
static void Load(Bar& barObject);
static void Save(Bar& barObject);
}

dans le code, j'aurai : Bar::Save(barInst) qu'on peut interpréter comme si la classe gère les instances.

Qu'est ce qui vous semble le plus correct (pour info les classes concernées représentes des Animations, caméras, ...) ?
Est ce qu'il existe des cas où il vaut mieux préférer l'un à l'autre ?

Vous pouvez aussi répondre : "tu te prends trop la tete, c'est pareil, prends en un au hasard"...

Merci d'avance !

EDIT : je pense que la méthode statique est moins performante que l'autre, à cause d'un passage d'un paramètre, non ?

[rockeye]

Bon, je pense avoir trouver la solution. Je vais différencier les 2 méthodes.

Lors d'un Save, l'objet est censé être valide, il peut donc se sauvegarder. J'opterai donc pour la fonction membre.

Pour le Load, l'état de l'objet pose problème. En effet, si c'est une fonction membre, on aura le code suivant :

Code :

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

1
2
3
Foo fooInst;
fooInstLoad;

Ca m'oblige à écrire un constructeur qui initialise les variables membres à des valeurs par defaut. Or l'objet serait inutilisable et cela favoriserait les erreurs possibles. On pourrait par exemple faire:

Code :

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

1
2
3
4
5
Animation anim;
anim.Save()
ou
anim.Play();

..ce qui ne serait pas correct. Si je peux éviter ce genre d'erreur grace au design, c'est mieux.

D'où le choix d'utiliser un Load statique qui renvoie un objet Animation.


Si certains ont des remarques, qu'ils n'hésitent pas!

[ze_corsaire]

Je serais plutôt pour une ou des classes externalisées qui prennent en charge les traitements considérés. Car dans le cas contraire, tu ne pourras pas factoriser les traitements communs des différentes "Animations".
Donc plutôt ta solution 2, mais avec un singleton.

______________

[3DArchi]

Je partage l'avis de ze_corsaire. Une classe :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class FooBarLoader
{
public:
   Foo*Load(...);
}

class FooBarSaver
{
public:
    void Save(Bar*,...);
}

Ca permet de regrouper ce qui est spécifique à la sauvergarde/lecture dans ta classe.

[Davidbrcz]

3DArchi >> On est dans le forum conception, donc dehors les pointeurs !
Sinon, pour moi c'est chaque objet qui devrait être responsable de charger ses propres données, je vote donc la méthode 1.

[wiztricks]

Je serais plutôt pour une ou des classes externalisées qui prennent en charge les traitements considérés. Car dans le cas contraire, tu ne pourras pas factoriser les traitements communs des différentes "Animations".
Donc plutôt ta solution 2, mais avec un singleton.

______________

La solution 2 propose des méthode de classe.
Pourquoi ajouter "singleton"?
Juste curieux ;-(
- W

[wiztricks]

3DArchi >> On est dans le forum conception, donc dehors les pointeurs !
Sinon, pour moi c'est chaque objet qui devrait être responsable de charger ses propres données, je vote donc la méthode 1.

Pour le save, çà ne pose pas trop de problème.
Pour le load, çà peut se discuter.
Ceci dit dans le cas particulier, Animation représente un objet dont une partie est persistante - le contenu du fichier "disque" - et dont l'état { chargé, sauvé } peut être de la responsabilité de l'objet.
Donc la méthode 1 me plait bien aussi.
- W

[ze_corsaire]

La solution 2 propose des méthode de classe.
Pourquoi ajouter "singleton"?
Juste curieux ;-(
- W

Ouais, pardon, c'est l'habitude du java !
Je n'ai pas vu qu'il pouvait s'agir de la déclaration d'une interface dans un autre langage.
Mais cela ne change pas mon point de vue !

__________

[3DArchi]

Je reste partisant d'un loader et d'un saver séparé. Ca permet souvent de factoriser des devs, de permettre des chargements en lots, d'évoluer plus rapidement....