Discussion :

[dev.go]

Bonjour,

Mon application comprend un modèle qui lui même comprend des projets qui eux même comprennent des scénarios.

Le modèle est sauvegardé sous la forme d'un répertoire qui comprend des sous répertoire pour les projets et un .properties qui comprend quelques clés.
Un scénario est sauvegardé sous la forme d'un répertoire qui comprend des sous répertoire pour chaque scénario et un .properties qui comprend quelques clés.
Enfin un scénario est sauvegardé sous la forme d'un ensemble de fichier texte et properties.

Donc je me retrouve avec un conception de la forme

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
20
21
22
23
24
25
26
27
28
29
Modele
 ListProjet
 directory
----------
 Modele()
 save()
 load()
 
 
Projet 
 Name
 Description
 ListScenario
 Directory
-----------
 Projet()
 save()
 load()
 
 
Scénario
 Name
 Description
 ListScenario
 Directory
-----------
Scénario
save()
load()

Ma question est la suivante.
Dois je m'occuper des fichiers et répertoires utilisé pour initilialiser/sauver ces objet dans les constructeurs des objets avec un constructeur de type Projet(File Directory) ou dois-je localiser ce code uniquement dans les méthodes load et save.
Si je fais cela cela veux dire que mon objet ne contiendra pas de données une fois que je l'ai crée.

Je suis ouvert à la discussion car je n'ai pas les idées claire sur ce point et cela me m’embête.

En vous remerciant

[chtig]

Tu as je pense besoin du constructeur vide pour pouvoir créer un nouvel élément qui n'est pas encore persisté.
Ta remarque sur l'object "vide" est pertinente, et c'est une des raison pour lesquelles je n'aime pas trop les conceptions avec des load et save dans les objets, et lui préfère les conception avec des dao.
Tu aurais alors :
Modele Projet Scenario qui ont un constructeur vide et des getters/setters
et
ModeleDao, ProjetDao et ScenarioDao qui contiennent les load/save

[dev.go]

OK je me doutais qu'une réponse de ce type la aller arrivé .
Le truc c'est que le design pattern DAO je ne le comprend pas trop.
Je comprend que le but de ce design pattern est d'isoler la partie qui gère la persistance des données de la logique de l'objet .
Mais je ne comprend pas comment cela s'applique vraiment a ce cas là ?
Et je me demande toujours si cela ne complique pas trop le code sachant qu'il s'agir de lire et écrire dans des fichiers ?

[chtig]

Te retrouver avec 6 classes au lieu de 3 ne veut pas dire complexifier le code.
L'idée c'est de découper en éléments "logiques" comme tu le dis, c'est à dire d'un côté l'objet, ce qu'il est, et de l'autre côté, comment il est persisté.
Autrement dit, dans ce cas précis, on a deux notions différentes :
- Qu'est qu'un Modele ? Qu'est-ce qu'un Projet ? etc ...
- Comment je fais pour sauvegarder/charger mon Model, Projet, etc ...
Le fait de découper est souvent signalé comme plus modulaire, dans le sens ou si demain tu veux changer et sauvegarder tes objets dans une base de données et non plus sur file system, tu ne changes que la couche dao. Mais ce n'est pas à mon avis l'intérêt premier, car c'est un cas "touche pipi théorique". Dans la réalité, je trouve en revanche que c'est très intéressant d'isoler les problématiques similaires. Ca te permet éventuellement ensuite de mutualiser du code etc ... (par ex boite à outil pour écriture/lecture des fichiers)