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

[PilloBuenaGente]

Je crois avoir compris le "truc", vraiment merci, je me suis aussi inspiré d'un ancien message à toi (en me renseignant sur les vecteurs et constantes...).http://www.developpez.net/forums/d12...vector-classe/
Voici le "tout début" du nouveau code :

Le Emp.h //(Emp = Interim) Ne contient plus que l'essentiel !!

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
#ifndef EMP_H_INCLUDED
#define EMP_H_INCLUDED
 
#include <string>
class Emp
{
public:
    Emp(const std::string name, const unsigned int id) : name(name), id(id) {}
 
    const std::string Name() const { return name; }
    const unsigned int Id() const { return id; }
 
    void Name(std::string name) { this->name = name; }
 
private:
    std::string name;
    unsigned int id;
};
 
#endif // EMP_H_INCLUDED

EmpPool.h //stock, supprime, change le nom(c'est pas de trop ?)

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
#ifndef EMPPOOL_H_INCLUDED
#define EMPPOOL_H_INCLUDED
 
#include "Emp.h"
#include "IdGen.h"
#include <vector>
class EmpPool
{
public:
    EmpPool() {}
 
    const unsigned int Add(const std::string name) { unsigned int newId(id.Generate()); pool.push_back(Emp(name, newId)); return newId; }
    //void Delete(const unsigned int id) { ... }
 
    std::string Name(const unsigned int id) const { return pool[id].Name(); }
    void Name(const unsigned int id, const std::string name) { pool[id].Name(name); }
 
private:
    EmpPool(const EmpPool &);
    EmpPool &operator = (const EmpPool &);
 
    std::vector<Emp> pool;
 
    IdGen id;//id.Generate() envoi un "unsigned int" à chaque fois différent
};
 
#endif // EMPPOOL_H_INCLUDED

Si j'ai compris !..(en croisant les doigts) Merci pour ton temps !

[koala01]

Il n'y a aucune raison de renommer un employé (Dupont Jacques ne va pas se réveiller un jour dans la peau de Durant Henry )

Sinon, je travaillerais peut etre sur une std::map (id, employé), mais c'est effectivement l'idée

[r0d]

Il n'y a aucune raison de renommer un employé

Moi je vois plusieurs raisons. Par exemple s'il y a eu une erreur à la saisie du nouvel employé (donc lors de la création de l'instance de la classe). Où lors d'un changement de nom (mariage et autres). Tu me diras, dans ces cas-là il faut détruire l'instance et la recréer. Ok pour cet exemple, mais ce n'est pas toujours la bonne solution.

En fait, comme j'en parlais ailleurs, je suis sceptique sur cette classification valeur/entité. En théorie, c'est joli, ça brille et c'est limpide. Dans la pratique, ce n'est jamais aussi simple, et surtout, pas vraiment utile. Je verrai plutôt une classification du type: entité de donnée (pour des classes destinées à stocker des données), entité de traitement (pour les classes qui manipulent les données) et entité de comportement (proche de l'idée du controler dans le MVC).

[backlash]

Je me posais les mêmes questions que r0d...

Si on prenait le cas d'une appli avec un pool de mémoire (typé) contenant des Employé, lorsque les objets Employé reviendraient à ce pool il faudrait bien réinitialiser les Employé pour ensuite les redistribués au besoin.

Sur cet exemple, je rejoins un peu r0d, même si la classification valeur/entité me semble être une approche robuste.

[PilloBuenaGente]

Il n'y a aucune raison de renommer un employé

J'aimerais accéder aux "Emp" et aux "Job" via leur "int id".
(stocker et comparer des "string" semble plus gourmand et moins précis qu'avec des "int", et embêtant pour les changements de noms comme le précisait rOd)

Je créerait ensuite la classe "MiseEnRelationInterimEmployé" qui adressera les "idJob" aux "idInterim".(je vais bossé "std::map")

(Avec les vecteur imbriqués, mes "Job" étaient directement contenues dans"Interim", il faut maintenant chercher l'Id correspondant mais la responsabilité unique va tout de même apporter de la clarté)

[PilloBuenaGente]

Rebonjour ! J'ai tout refait avec des Ids, je n'y vois pas plus de stabilité que de cafouillage :p.J'ai du coup gardé mes vecteurs imbriqués, mais réorganisé un peut tout ça.
J'ai suivis la responsabilité unique et quelques conseil du forum, en particulier : http://www.developpez.net/forums/d12...code-doom-3-a/
Mon problème était seulement d'organisation, j'y vois beaucoup plus clair.

Pool.h

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
#ifndef POOL_H_INCLUDED
#define POOL_H_INCLUDED
 
#include "PoolEmp.h"
#include <vector>
 
/*
========================================
Pool
========================================
*/
class Pool {
public:
        Pool();
 
        //--------------------------------------
        //Employer
        //--------------------------------------
        void                            EmpNew( const std::string name );
        void                            EmpRemove(const int num);
 
        void                            EmpName( const int num, const std::string name );
        const std::string               EmpName( const int num ) const;
 
        const int                       EmpSizeAll() const;
        const int                       EmpSize( const int num ) const;
        const int                       EmpDaySize( const int empNum );
        const int                       EmpTimeSize( const int empNum) const;
 
        void                            EmpFirst( const int num );
 
        //--------------------------------------
        //Job
        //--------------------------------------
        void                            JobNew( const int empNum, const std::string name );
        void                            JobRemove( const int empNum, const int jobNum );
 
        void                            JobName( const int empNum, const int jobNum, const std::string name );
        const std::string               JobName( const int empNum, const int jobNum ) const;
 
        const int                       JobSizeAll() const;
        const int                       JobSize( const int empNum, const int jobNum ) const;
        const int                       JobTimeSize( const int empNum, const int jobNum) const;
 
        void                            JobFirst( const int empNum, const int jobNum );
 
        void                            JobChangeEmp( const int empNum, const int jobNum, const int newEmpNum );
 
        //--------------------------------------
        //Day
        //--------------------------------------
        void                            DayNew( const int empNum, const int jobNum, const int date, const int time );
        void                            DayRemove( const int empNum, const int jobNum, const int dayNum );
 
        const int                       DaySizeAll();
        const int                       DayTimeSize( const int empNum, const int jobNum, const int dayNum ) const;
 
        const int                       DayDate( const int empNum, const int jobNum, const int dayNum ) const;
 
private:
        Pool( const Pool & );
        Pool &operator = ( const Pool & );
 
        std::vector < PoolEmp >  empPool;
};
 
#endif // POOL_H_INCLUDED

Première question, j'utilise seulement la bibliothèque standard c++ (sstream, iostream, vecteur...)(viré la "gestion"(pardon) de la fenêtre et des couleurs), est-ce que mon .exe pourra tourner sur toutes les plateformes ?
Je compile avec code::block et GNU, et affiche une fenêtre que j'ai besoin en taille standard (80*25).

Deuxième question, je sauvegarde mes données dans un fichier texte qui ce créer à coté et qui sert de sauvegarde. N'y a t-il pas moyen de réserver une partie du .exe ou "coller" les deux fichiers pour éviter à tout pris leur séparation ?

(edit)Troisième question, l'utilisation de vecteur en inline est sans doûte une mauvaise idée ?! :

Code :

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

        void                            EmpName( const int empNum, const std::string name ) { empPool[ empNum ].EmpName( name ); }

Merci !

[koala01]

Rebonjour ! J'ai tout refait avec des Ids, je n'y vois pas plus de stabilité que de cafouillage :p.J'ai du coup gardé mes vecteurs imbriqués, mais réorganisé un peut tout ça.
J'ai suivis la responsabilité unique et quelques conseil du forum, en particulier : http://www.developpez.net/forums/d12...code-doom-3-a/
Mon problème était seulement d'organisation, j'y vois beaucoup plus clair.

Une fois que tu t'organise mieux, c'est toujours beaucoup plus facile

Pool.h

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
#ifndef POOL_H_INCLUDED
#define POOL_H_INCLUDED
 
#include "PoolEmp.h"
#include <vector>
 
/*
========================================
Pool
========================================
*/
class Pool {
public:
        Pool();
 
        //--------------------------------------
        //Employer
        //--------------------------------------
        void                            EmpNew( const std::string name );
        void                            EmpRemove(const int num);
 
        void                            EmpName( const int num, const std::string name );
        const std::string               EmpName( const int num ) const;
 
        const int                       EmpSizeAll() const;
        const int                       EmpSize( const int num ) const;
        const int                       EmpDaySize( const int empNum );
        const int                       EmpTimeSize( const int empNum) const;
 
        void                            EmpFirst( const int num );
 
        //--------------------------------------
        //Job
        //--------------------------------------
        void                            JobNew( const int empNum, const std::string name );
        void                            JobRemove( const int empNum, const int jobNum );
 
        void                            JobName( const int empNum, const int jobNum, const std::string name );
        const std::string               JobName( const int empNum, const int jobNum ) const;
 
        const int                       JobSizeAll() const;
        const int                       JobSize( const int empNum, const int jobNum ) const;
        const int                       JobTimeSize( const int empNum, const int jobNum) const;
 
        void                            JobFirst( const int empNum, const int jobNum );
 
        void                            JobChangeEmp( const int empNum, const int jobNum, const int newEmpNum );
 
        //--------------------------------------
        //Day
        //--------------------------------------
        void                            DayNew( const int empNum, const int jobNum, const int date, const int time );
        void                            DayRemove( const int empNum, const int jobNum, const int dayNum );
 
        const int                       DaySizeAll();
        const int                       DayTimeSize( const int empNum, const int jobNum, const int dayNum ) const;
 
        const int                       DayDate( const int empNum, const int jobNum, const int dayNum ) const;
 
private:
        Pool( const Pool & );
        Pool &operator = ( const Pool & );
 
        std::vector < PoolEmp >  empPool;
};
 
#endif // POOL_H_INCLUDED

Première question, j'utilise seulement la bibliothèque standard c++ (sstream, iostream, vecteur...)(viré la "gestion"(pardon) de la fenêtre et des couleurs), est-ce que mon .exe pourra tourner sur toutes les plateformes ?

A priori, oui, c'est fait pour

Je compile avec code::block et GNU, et affiche une fenêtre que j'ai besoin en taille standard (80*25).

Normalement oui

Deuxième question, je sauvegarde mes données dans un fichier texte qui ce créer à coté et qui sert de sauvegarde. N'y a t-il pas moyen de réserver une partie du .exe ou "coller" les deux fichiers pour éviter à tout pris leur séparation ?

Non, pour deux raison:
1- Il y a généralement un "lock" sur les fichiers exécutables qui empêche qu'ils soient modifiés alors qu'ils sont utilisés

2- L'écriture d'un fichier revient à "graver le contenu dans le marbre".

Chaque fois que tu modifies le fichier ailleurs qu'à la fin, tu "casses la pierre" pour la regraver entièrement.

(edit)Troisième question, l'utilisation de vecteur en inline est sans doûte une mauvaise idée ?! :

Code :

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

        void                            EmpName( const int empNum, const std::string name ) { empPool[ empNum ].EmpName( name ); }

Merci !

Non, absolument pas.

Les fonction inlines ne font que demander au compilateur de remplacer l'appel de la fonction par le code qui la compose, et le compilateur décide, en fonction du nombre d'instructions processeur qu'il devra mettre en oeuvre, de le faire effectivement ou non.

Pour les fonctions simples (dont l'opérateur [] de vector), le compilateur a de grandes chances d'accéder à ta demande, et, selon la complexité de Empname aussi

Tu risques cependant d'observer une légère augmentation de la taille de l'exécutable, si tes fonctions inline sont appelées très souvent, mais ce n'est, a priori, pas excessif

[PilloBuenaGente]

Très clair, rapide, merci beaucoup !