Discussion :

[PilloBuenaGente]

bonjour, j'ai une gestion de classes ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class system
	vecteur interim
   class interim
	   string nom
	   vecteur job
      class job
	      string nom
	      vecteur date
         class date
	         int date
	         classe temps
            class temps
	            int temps

Lorsque je veux récupérer un temps avec :

Code :

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

int temps = system.GetTemps(numInterim, numJob, numDate);

Il y aura donc la fonction "GetTemps" dans chaque classes suivantes.

Seul mon int se déplace dans les classes cependant la classe system va contenir beaucoup de fonctions.

Serait-il intéressant de renvoyer directement les classes ?(elle contiennent tout de même des vecteurs dont taille peut être imposante)
En utilisant les références peut être puis-je éviter les copies.

exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
#include "Job.h"
#include <string>
#include <vector>
 
class Interim
{
public:
   Interim(const std::string name) : m_name(name) {}
   Job &GetJob(const int num) { return vm_job[num]; }
private:
   std::string m_name;
   std::vector <Job> vm_job;
};

Je pourrais faire une truc du genre

int temps = system.GetInterim(num).GetJob(num).GetDate(num).GetTime();

Serait-ce un bon choix ? Vais-je perdre trop de mémoire ?

Merci

[Médinoc]

Ça me parait un bon choix, fais juste attention à ne pas oublier la const-correctness:

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
class Interim
{
public:
   Interim(const std::string name) : m_name(name) {}
   Job       &GetJob(const int num)       { return vm_job[num]; }
   Job const &GetJob(const int num) const { return vm_job[num]; }
private:
   std::string m_name;
   std::vector <Job> vm_job;
};

[PilloBuenaGente]

Merci ! Ça va vraiment me simplifier la vie !
Je ne connaissait pas cette méthode, la surcharge avec "const". Merci aussi de répondre à mes questions avant qu'elles ne soient posées ! ^^ (Je vais TOUT rendre constant :p)
Bonne nuit !

[koala01]

Salut,

Ce qui m'ennuie avec toutes ces fonctions membres get, c'es que tu sembles jeter la loi Déméter aux orties

Peut être le problème est-il du au fait que tu sembles plus réfléchir à tes classes sur base des données qu'elles manipulent plutôt que sur base des services que tu en attends

Car l'idée générale est que la manière dont sont maintenus les différents composants ne sont que des détails d'implémentations dont l'utilisateur de tes classes n'a a priori strictement rien à faire, et que l'utilisateur de la classe Interim ne devrait a priori absolument pas avoir à connaitre la classe Job pour la manipuler (je parle de la classe Interim).

Mais l'idéal pour arriver à déterminer clairement les services que tu es en droit d'attendre de tes différentes classes est de commencer par déterminer quelle est la responsabilité de chacune d'elles, et, surtout, de veiller à ce que chaque classe ne s'occupe que d'une seule chose, mais qu'elle le fasse bien (selon le principe de la responsabilité unique )

Enfin, comme on peut très clairement envisager le fait que les différentes données devront être sérialisées d'une manière ou d'une autre (dans une base de données relationnelle ), il serait peut etre intéressant de veiller à créer, au niveau de la partie métier, des "classes intermédiaires" dont le but est d'éviter autant que possibles les différentes relation "N à N" au profit de relations "un à un" ou "un à plusieurs"

[PilloBuenaGente]

Merci pour ce que vous faîtes !

"tu sembles jeter la loi Déméter aux orties"

Il me semblais bien que ce n'était pas tip top conventionnel...^^
Le problème pourrait être solutionné en ne gardant que le "GetClasse" constant ? (pour ne pas être modifié de l’extérieur)

"tu sembles plus réfléchir à tes classes sur base des données qu'elles manipulent plutôt que sur base des services que tu en attends"

Peut-être me reste t'il encore beaucoup à comprendre de la philosophie binaire...(J'ai aussi lus au moin 10 fois ton message avant de le "saisir" à moitié :p )

"l'utilisateur de la classe Intérim ne devrait a priori absolument pas avoir à connaitre la classe Job pour la manipuler"

Je l'ai déjà fait de cette manière, cependant les headers deviennent ultra chargé. Il est devenu compliqué à faire évoluer. Ma classe Job par exemple doit contenir :
-Gestion du nom (entrée, sortie, changement)
-Getion de la date(entrée, sortie(année, mois, jour), tri)
-Gestion du temps(entrée, sortie(heure, minute), tri)
-et j'en passe

On doit pouvoir, créer, renommer/changer, trier, retourner les valeurs, supprimer... de toutes les classes citées ici.

"il serait peut être intéressant de veiller à créer, au niveau de la partie métier, des "classes intermédiaires""

Genre, pour gérer la relation entre ces classes ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class gestionJob
class gestionDate
class gestionTemps
 
class system(gestionInterim)
	vecteur interim
   class interim
	   string nom
           vecteur job
      class job
	      string nom
	      ....

"le principe de la responsabilité unique"

Alors peut-être même que la classe "interim" comprendrais les classes AjoutDeJob, SuppressionDeJob, tableauDeJob, TriDeJob... ?

"éviter autant que possibles les différentes relation "N à N" au profit de relations "un à un" ou "un à plusieurs""

Désolé mais pas comprendre moi !

Bah je ne sais plus vraiment comment procéder...
J'ai à un moment aussi pensé aux pointeurs, pour avoir une base fixe et un jeu d'adresses, cependant ça m'a l'air plutôt casse-gueule.

Pour vous quel serait le meilleur moyen de gérer tout ça ?
Merci par avance !
edit: Je me permets d'enlever le résolu, je suis un peut perdu..

[koala01]

Il me semblais bien que ce n'était pas tip top conventionnel...^^
Le problème pourrait être solutionné en ne gardant que le "GetClasse" constant ? (pour ne pas être modifié de l’extérieur)

Ce serait sans doute déjà mieux, mais cela occasionnerait sans doute quelques problèmes pour la mise à jour de tes données (le fait de rajouter un élément, essentiellement )

Peut-être me reste t'il encore beaucoup à comprendre de la philosophie binaire...(J'ai aussi lus au moin 10 fois ton message avant de le "saisir" à moitié :p )

Ce n'est pas la philiosophie "binaire", c'est la philosophie "orienté objets" qu'il faut comprendre.

Tu dois comprendre que tous les types que tu peux créer vont te servir un peu comme les objets de la "vie courante": tu attends certains services de la part de tes objets, et tu vas donc choisir l'objet que tu vas utiliser sur base de l'utilisation que tu peux en faire(tu n'envisagerais jamais d'enfoncer un clou avec une cuiller )

La bonne question est donc "qu'est ce que je m'attend à pouvoir faire avec telle et telle classe "

Je l'ai déjà fait de cette manière, cependant les headers deviennent ultra chargé. Il est devenu compliqué à faire évoluer. Ma classe Job par exemple doit contenir :
-Gestion du nom (entrée, sortie, changement)
-Getion de la date(entrée, sortie(année, mois, jour), tri)
-Gestion du temps(entrée, sortie(heure, minute), tri)
-et j'en passe

Essayes encore, en évitant le terme "gestion" et en ne gardant qu'une seule responsabilité.

Là, tu en as déjà trois, plus toutes celles que tu as passées, c'est au moins deux (plus toutes celles que tu as passées) de trop

Par exemple, que penserais tu de "la classe job met en relation un travailleur et un rapport de prestations" comme description de responsabilité pour cette classe

Seulement, cela implique qu'il faille savoir ce que l'on entend par "travailleur" et par "rapport de prestation"

Hé bien, essayes de trouver la responsabilité unique qui représente les différents services qui pourraient être rendus par ces deux termes, en évitant le mot gestion (qui est définitivement trop vague, à moins de préciser ce que tu entends par ce terme par la suite).

Une fois que tu n'as plus que des termes simples (comprends: des termes pour lesquels tu ne dois pas donner de précision), tu pourras estimer qu'un nom (comme "travailleur", "rapport de prestations" ) correspond à un type qu'il te faudra créer et qu'un verbe (comme "préciser les heures de début") correspond à une fonction qu'il te faudra créer

On doit pouvoir, créer, renommer/changer, trier, retourner les valeurs, supprimer... de toutes les classes citées ici.

Ca, c'est un problème qui apparait uniquement à cause de l'utilisation malheureuse du terme "gestion".

Du coup, ta classe interim se retrouve avec beaucoup trop de responsabilités, car la seule qui lui convient est peut etre simplement... de permettre le calcul des couts

Genre, pour gérer la relation entre ces classes ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class gestionJob
class gestionDate
class gestionTemps
 
class system(gestionInterim)
	vecteur interim
   class interim
	   string nom
           vecteur job
      class job
	      string nom
	      ....

Comme je viens de le dire, évite le terme "gestion" comme la peste

Car, à chaque fois que tu l'utilises, tu devrais te poser la question de "d'accord, mais qu'est ce que j'entends par là"

Alors peut-être même que la classe "interim" comprendrais les classes AjoutDeJob, SuppressionDeJob, tableauDeJob, TriDeJob... ?

Peut etre les utilise-t-elle en interne, mais de manière transparente

Désolé mais pas comprendre moi !

Une relation N à N est une relation dans laquelle "un ou plusieurs job(s)" seraient mis en relation avec "un ou plusieurs truc(s)" (quelque soit "truc").

L'idéal est d'avoir des relations "un à un" --c'est à dire dans lesquelles "un et un seul (quoi que ce soit)" est mis en relation avec "un et un seul (quoi que ce soit d'autre)"-- ou au pire des relations "un à plusieurs" -- c'est à dire dans lesquelles "un et un seul objet" est mis en relation avec "un ou plusieurs objets différents"

Bah je ne sais plus vraiment comment procéder...
J'ai à un moment aussi pensé aux pointeurs, pour avoir une base fixe et un jeu d'adresses, cependant ça m'a l'air plutôt casse-gueule.

Les pointeurs sont une chose à envisager, mais tu peux (tu aurais d'ailleurs intérêt ) aussi envisager d'avoir un identifiant unique pour chaque donnée (hormis les dates et les heures ).

La plupart de tes classes à part date et heure ont en effet sémantique d'entité, ce qui fait que chaque instance est a priori unique

Pour vous quel serait le meilleur moyen de gérer tout ça ?
Merci par avance !
edit: Je me permets d'enlever le résolu, je suis un peut perdu..

Pour pouvoir répondre, il faudrait savoir exactement quel est le but de ton application et sans doute faire une analyse fonctionnelle de tout cela

Mais une solution à base de pointeurs est effectivement envisageable, tout comme une solution à base d'identifiant unique et non ambigu