Discussion :

[lichman]

Bonjour,

J'aimerai avoir votre avis sur le fonctionnement de mon programme.

J'ai divers objet de type different et qui sont manipulé par le programme.
Tout ces objets sont copié dans une base de donnée lorsque plus aucune personne n'utilise l'objet ( c'est a dire lorsqu'il n'y a plus de pointeur vers cet objet ) et que cette objet n'a pas eu une demande de suppression. Lors d'une demande de supression de l'objet, l'objet est suprimer de la base de donnee et n'est donc pas copié...

Un utilisateur du programme peut demander une copie d'un objet de la base de donnée lorsqu'une copie existe. Dans le cas contrere, on lui fourni un objet nouveau.

C'est donc l'objet qui, dans son destructeur, desside de faire appele ( ou pas )
a sa base de donnée pour se faire copier dans la base de donnée.

Ce type de systeme m'a ete inspiré du fonctionnement des fichiers dans unix ( cf: buffer, inode memoire, inode disque,... ).

Est-ce une bonne idée de faire ceci ou est-il mieux de copier les objets dans la base de donnée lorsque l'utilisateur le demande explicitement? C'est a dire que dans le premier cas, c'est l'objet qui demande de se faire copier dans la base de donnée, et dans l'autre cas, c'est l'utilisateur qui demande de copier l'objet a la base de donnée.

Merci et bonne jourée

[Hephaistos007]

Je ne suis pas sur d'avoir bien compris, mais à première vue il y a un dilemne.

Tu souhaites qu'un objet qui n'est plus référencé prenne la désicion de se sauvegarder dans une BDD lors de sa destruction. Au delà même du fait que je ne sais pas si il est possible qu'un objet ai connaissance de son propre référencement, si tu est capable d'invoquer un destructeur sur un objet, c'est que tu possède nécessairement sa référence ! Cet objet ne pourra donc jamais prendre la désicion de se sauvegarder. Je sais pas si je suis très clair ...

[lichman]

En fait, ce n'est pas reelement lorsqu'il n'a plus de reference vers lui qu'il se copie. Il se copiera lorsque le dernier, qui a une reference vers l'objet, relache la reference.
J'utilise un simple compteur pour savoir le nombre de reference qu'a l'objet et lorsque se compteur est egal a 1 et qu'on se trouve dans le destructeur, alors, on le copie dans la base de donnée.

[Keihilin]

On touche à des notions de responsabilité, et donc une réponse est plus philosophique qu'objectivement technique...

A mon sens, ce n'est pas à l'objet lui-même de s'occuper de sa persistence en base de donnée. Sa responsabilité devrait se limiter à indiquer le jeu de valeurs nécessaires à sa persistence (cf. mécanismes de sérialisation).

D'autre part, si j'ai bien compris ton mécanisme, tu prends le contre-pied de ce qui se fait habituellement :

1. L'objet existe en base de donnée
2. Lorsqu'une demande arrive, l'objet est chargé et mis dans un système de cache.
3. Lors des demandes suivantes, l'objet est accédé directement à partir du cache.
4. On synchronise l'état de l'objet avec sa représentation en base selon les manipulations de l'utilisateur.

Bref, c'est très générique tout cela, peut être que des informations sur ton environnement aideraient à être plus précis sur les conseils.

[cinemania]

Comme déjà dit avant, c'est un peu trop générique pour te conseillé.

Cependant quelques règles de programmation existes pour améliorer la lisibilité et partager les responsabilités

Il est vivement déconseillé de mettre tout le code logique d'accès à la base de données dans ton objet "métier", mais plutot dans un objet à part fait pour ca.

Ensuite selon l'environnement ce que tu demande est "possible" avec des réserves.
Comme déjà cité, si tu procède comme tu procède sa signifie que quelque part tu as un controleur qui controle le nombre de références à l'objet... pourquoi donc ne pas mettre les appels vers le code logique gérant ta persistance dans ce "contrôleur".

Puisque tu gere ton système de la sorte, mettre au point un vrai controleur s'il n'y en a pas ne devrait pas poser de problème.
Et en plus ca t'évitera de laisser le choix de la persistance au client, surtout si celui-ci oublie de le sauver alors qu'il le fallait...

Dans une application .NET par exemple, l'objet peut avoir connaissance du moment où il n'y a plus aucune référence vers lui et qu'il va être "sacrifié" cad nettoyé par le Garbage Collector.
Malheureusement, le moment où ce nettoyage arrive n'est pas forcément juste après la perte de toutes les références mais parfois une éternité après (en informatique une éternité n'a rien avoir avec la notion humaine...)
Autre problème, si ton objet est en cours de nettoyage, (que le GC appel le Finaliseur de l'objet) s'il fait référence à d'autres objets managés (suceptible d'etre balayé par le GC) tu ne peux pas y accèder de façon sure, car l'ordre de suppression des objets n'est pas hierarchique (en clair, il se peut qu'un des objets dont tu as la référence, soit supprimé avant toi)

D'autres langages ne permettent carrément pas de gérer un destructeur ou finaliseur (Java et d'autres langages managés)

Globallement tu ne peux pas faire confiance au destructeur pour savoir si l'objet peut etre supprimé ou non de la base... si n'importe quel utilisateur de ton code fait delete objet en C++ par exemple... le destructeur est appelé, et meme si celui-ci ne libere pas correctement les ressources, quelque soit l'état de son compteur de référence, il sera "DETRUIT" et c'est absolument IMPARABLE, et même une exception ne sauvera pas ton objet de la destruction.