Discussion :

[fanzilan]

Bonjour/bonsoir,

En fait le souci que j'ai eu là : https://www.developpez.net/forums/d2...obleme-design/. Il n'est pas résolu.
La question que j'ai posé oui, mais le problème sous-jacent non.

Je vais changer d'univers, les animaux c'est peut-être pas le bon exemple.

Imaginons, une personne cherche un logement, un appartement. Cet appartement est petit. Et la personne sait se contenter de peu.
L'appartement contient un lit, un four, des toilettes, une douche, il est caractérisé par une surface aussi...et un meuble supplémentaire (quand je vous disais qu'il se contentait de peu).
Ce meuble peut être une table à manger, une étagère, ou ce que vous voulez du moment qu'ils sont caractérisés différemment (la table a une surface, l'étagère une hauteur, le bureau des tiroirs...).
Il doit être choisi en fonction de la surface de l'appartement (si c'est petit, on prend une étagère, si c'est moyen un bureau, si c'est grand une grande table à manger et si c'est trop petit, alors pas de meuble du tout).

Comment je peux représenter tout ça ? Déjà l'appartement a ses différents paramètres ainsi que le meuble. Et le meuble est choisi en fonction d'un des paramètres de l'appartement.
Mais comment je fais ensuite ? Je crée N classes différentes ? Une classe mère et plusieurs classes filles avec du polymorphisme ?
Alors pour ce dernier cas je pourrais utiliser ce qu'on m'a proposé, mais je commence à me demander si c'est la meilleure solution pour ce genre de soucis.

Bref, voilà déjà la classe Appartement que je propose :

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
 
class Appartement
{
public:
	Appartement() 
	{
		mArea = 0;
		mMeuble = new Meuble();
	}
	// autre constructeur avec une valeur pour mArea et donc un switch pour le meuble
	~Appartement()
	{
		delete mMeuble;
		mMeuble = nullptr;
	}
 
	void setArea(int area) {mArea = area;};
	int const & getArea() const {return mArea;};
 
	void setMeuble(const Meuble &meubleCopie)
	{
		/* switch qui choisis le type de meuble en fonction de area */
	}
 
private:
	int mArea;
	Meuble *mMeuble;
};

Qu'est ce que je mets alors dans Meuble sachant que je vais vouloir récupérer les caractéristiques des différents types de meubles et que donc c'est chaud avec du polymorphisme (je vais me retrouver avec une mauvaise solution, comme celle dont je parle dans le lien).

[koala01]

Salut,

Bon, déjà, la surface de l'appartement, tu dois la définir une bonne fois pour toute lors de la création de l'instance de celui-ci, parce que tu ne peux pas avoir d'appartement si tu n'en connais pas la surface.

De même, une fois que cette surface a été définie, il n'y a plus aucun sens à permettre à l'utilisateur de la modifier car, ben, je vois mal par quel miracle ton appartement de 20 m² pourrait, subitement, en faire 32

D'ailleurs, tu peux te dire que, de manière générale, s'il y a -- peut-être -- du sens à fournir un accesseur ( getArea) sur une donnée particulière de ta classe, car il peut correspondre à un des services que l'on est effectivement en droit d'attendre de la part de la classe, il y a généralement très peu de sens à fournir un mutateur (setArea) sur cette donnée, ne serait-ce que parce que ce mutateur va rendre l'utilisateur de la classe responsable du calcul de la valeur à lui donner.

Or, l'utilisateur est un imbécile distrait, par nature, qui n'attend qu'une occasion pour faire une connerie en manipulant les données que tu lui donnes. Tu ne dois même pas perdre ton temps à te demander SI l'utilisateur finira (ou non) par faire une connerie, car tu peux avoir la certitude que ce sera le cas à un moment ou un autre. Tu peux, directement te demander QUAND l'utilisateur finira par faire une connerie. Et la réponse va en fait très peu varier, car ce sera toujours ... Au pire moment qui soit.

De plus, les gens se plantent royalement quand ils croient qu'il "suffit" de placer une donnée dans l'accessibilité privée et de fournir un accesseur et un mutateur pour mettre en place ce que l'on appelle l'encapsulation.

Car le but de l'encapsulation est -- justement -- d'empêcher l'utilisateur d'apporter une modification qui serait incorrecte ou incohérente à la donnée. Mieux encore, selon la loi de déméter, l'utilisateur n'a même pas à se soucier de la manière dont une donnée "correctement encapsulée" est représentée à l'intérieur d'un objet.

Ainis, si j'avais -- par exemple -- un personnage, qui est caractérisé par une position qui lui est propre, je pourrais "parfaitement" avoir un type de donnée qui permette de représenter la notion de "position" et qui prendrait une forme proche de

Code :

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

1
2
3
4
5
6
struct Position{
    Position(int x, int y):x{x},y{y}{ //
    }
    int x; // position sur l'axe des X
    int y; // position sur l'axe des Y
};

et, pourtant, mon personnage pourrait se présenter sous une forme proche de

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
class Personnage{
public:
     Personnage(int xDepart, int yDepart): x{xDepart}, y{yDepart}{
     }
     /* pour permettre au personnage de se déplacer */
     void move(int diffX, int diffY){
          /* il faut des vérification pour s'assurer que le déplacement est valide */
          x+=diffX;
          y+=diffY;
     }
     /* pour permettre à l'utilisateur d'en récupérer la position */
     Position position() const{
          return Position{x, y};
     }
private:
    int x; // position sur l'axe des X
    int y; // position sur l'axe des Y
};

Comme tu peux le constater, qu'il s'agisse du constructeur du personnage ou de la fonction move, l'utilisateur n'utilise absolument pas la notion de "position" lorsqu'il manipule un personnage. D'ailleurs, la notion de position n'est ... même pas présente dans la classe. Le seul endroit où cette notion de position apparaît, c'est quand ... l'utilisateur souhaite savoir à quel endroit le personnage se trouve à un instant T.

Voilà donc l'exemple type d'une donnée "correctement encapsulée", car toute la logique du déplacement sera prise en charge "par nous", au niveau de la fonction move. Et le pire que l'utilisateur puisse faire, c'est de demander à son personnage de se déplacer dans une direction dans laquelle il n'aurait pas la place pour aller (chose qui devrait être "interceptée" par la fonction move )

Si on en venait à définir la fonction move (ou pire, une fonction setPosition) sous une forme proche de

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
class Personnage{
public:
     Personnage(Position const & posDepart): pos{posDepart}{
     }
     /* pour permettre au personnage de se déplacer */
     void moveTo(Position const & newPos){
          pos = newPos;
     }
     /* ce qui revient au même que */
     void setPosition(Position const & newPos){
          pos=newPos;
     }
     /* pour permettre à l'utilisateur d'en récupérer la position */
     Position const & position() const{
          return pos;
     }
private:
    Position pos;
};

l'encapsulation est brisée. Non pas parce que l'on donne un sérieux indice sur la manière dont la position est représentée au niveau du personnage (quoi que cela ne favorise pas vraiment l'encapsulation), mais bien parce qu'il revient à l'utilisateur du personnage de calculer lui-même la position du personnage quand il souhaite le faire bouger (parce qu'il doit fournir une donnée de type Position aux fonctions moveTo / setPosition ) et que l'on ne peut absolument pas être sur qu'il respectera toutes les règles qui permettent (normalement) d'éviter que notre personnage ne se retrouve au milieu d'un mur ou dans un fossé

Les choses sont encore pire en ce qui concerne le meuble. Car un meuble va -- typiquement -- avoir sémantique d'entité: même si nous avons acheté la même table, le même jour dans le même magasin et qu'on les place au même endroit dans deux appartements qui se ressemblent comme deux gouttes d'eau, il s'agit de deux tables "fondamentalement différentes", qui vont évoluer de manière totalement différentes, peut être parce que j'ai un grand chien qui aime poser les pattes sur la table, et toi, un perroquet qui jette systématiquement les coquilles de des graines de tournesol dessus.

Tu ne pourras donc pas, a priori, copier un meuble transmis en paramètre à une des fonctions de ta classe Appartement.

Et, de toutes façons, vu la manière dont tu exprime les choses, le choix du meuble est arbitraire, car il dépend de la surface de l'appartement et ne peut pas être remis een question. Ce choix sera donc "fixé, une bonne fois pour toutes" au moment où l'on détermine la surface de l'appartement.

Et comme je viens de t'expliquer que cette superficie devait être définie dés la construction de l'appartement, le moment "le plus opportun" pour choisir le meuble (ou, plutôt, pour déterminer quel meuble va aller dans l'appartement) sera ... au moment où l'on construit l'appartement, sans possibilité de modifier ce choix par la suite

En exagérant à peine un tout petit peu, nous pourrions donc dire que, une fois que la superficie de l'appartement est définie, on va créer un plancher, poser le meuble adapté à la superficie au milieu, et ... "monter" les murs autour du meuble

La seule question à laquelle il faudrait peut-être envisager d'apporter une réponse serait "que se passe-t-il pour le meuble lorsque l'appartement est détruit le meuble est-il détruit en même temps que l'appartement, ou bien peut on le récupérer pour le mettre ailleurs "

Alors, bien sur, tout ce que je viens de t'expliquer ne résout absolument pas ton problème qui est "comment faire pour pouvoir manipuler différents types de meubles en fonction de la surface des appartements "

Et je crois, qu'en fait, les solutions de base t'ont été données: double dispatch (patron de conception visiteur inside) ou organisation sous la forme d'un ECS.

Il y a sûrement d'autres solutions auxquelles je ne pense pas dans l'immédiat. Le truc, c'est que l'on manque encore énormément d'informations, par exemple sur la manière dont tu veux présenter les appartement à l'utilisateur (car les appartements, ce ne seront que des successions de 1 et de 0, faut il le rappeler), ou sur ce que tu veux faire des appartements, comment tu envisages de les manipuler, une fois qu'ils auront été créés au niveau de ton application.

Ce que tu dois surtout retenir, c'est qu'une classe est en fait un fournisseur de services, et que les services fournis sont en fait de deux types distincts, vu que l'on a

1. le fait de répondre à une question (quelle est ta surface ) et
2. obéir à un ordre (fais ceci ou fait cela)

La première chose que tu devrais donc essayer de faire, c'est ... déterminer les services dont tu estimes "normal", en tant qu'utilisateur de ta classe appartement, de pouvoir disposer; que la classe doit pouvoir te rendre pour être "utile et efficace".

Tant que tu n'auras pas une réponse complète à ce niveau là, tu ne pourras pas définir ta classe de manière correcte et cohérente

(et, bien sur, il en va de même pour la notion de "meuble", avec toutes les variations possibles )

[fanzilan]

Bonjour,

désolé pour cette longue absence, c'est vrai que je donne pas toutes les informations, j'ai peur de donner trop de détails ou bien je ne pense pas que d'autres ont leur importance. Et ce d'autant que je cherche des métaphores : en fait je dois coder un truc qui n'a rien à voir avec les exemples que je vous ai partagé.

Mais revenons en à nos appartements, je pense que je tiens une bonne métaphore, peut-être y en a t il des meilleures ou pas je sais pas.
Effectivement, les mutateurs servent à rien, je pense les enlever.

Si l'appartement est détruit, son contenu (le meuble donc) est détruit aussi.

Ce que je veux en faire des apparts, c'est les mettre dans une collection, l'envoyer à une agence qui loue des meublés on va dire, qui eux ensuite vont "dépiler" cette liste afin de connaître leurs caracs chacun, y compris la surface et le meuble. D'où les accesseurs.
Du coup, si j'ai bien compris, je fais tout dans le constructeur et je touche plus à rien dans cette classe ensuite.

Mais j'ai réfléchi un peu ces derniers temps sur mon problème.
Toujours en rapport avec le meuble, je pensais faire une classe "Meuble" abstraite, puis faire des héritages (une classe "étagère", une classe "table"), alors que...peu importe pour "l'agence", elle s'en fiche au fond. Tout ce qu'elle veut, c'est connaître les caractéristiques du meuble comme sa surface au sol, le nombre d'étagères si il y a, le nombre de tiroirs si il y a, que sais-je d'autres...Avec ces 3 exemples ça devrait aller.
Du coup, est ce que je peux finalement pas faire une simple composition au lieu de me compliquer la tâche avec des héritages ?
Ma classe Meuble ne serait finalement pas abstraite et ne serait pas parente et elle contiendrait des pointeurs pointant sur des entiers pour les étagères et tiroirs, que je mettrais à "nullptr" si jamais mon Meuble ne contient pas de tiroirs ou d'étagères. Pourquoi un pointeur ? Parce que je veux pas que l'information prenne de la place inutile si c'est pour dire "y a pas de tiroirs/étagères" donc le nullptr peut servir à ce que ça prenne pas de place (arrêtez moi si je dis une bêtise).
Reste un détail : comment je construis une instance de Meuble si j'ai des pointeurs dont la valeur dépend de la surface de l'appart. Peut-être faire comme ça ?

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
 
class Meuble
{
public:
 Meuble(int surfAppart)
{
   if (surfAppart<= PETITE_SURFACE)
  {
      _surfSol = 0;
      _nbEtageres = nullptr;
      _nbTiroirs = nullptr;
  }
  else if (surfAppart <= MOYENNE_SURFACE)
  {
    _surfSol = 5;
    _nbEtageres = std::make_unique<int>(2);
    _nbTiroirs = nullptr;
  }
  else
  {
    _surfSol = 6;
    _nbEtageres = std::make_unique<int>(4);
    _nbTiroirs = std::make_unique<int>(1);
  }
}
 
~Meuble(); // ce sont des smart pointers, donc je détruis tout
 
/* getters, pas de setters*/
 
private:
 int _surfSol;
 std::unique_ptr<int> _nbEtageres;
 std::unique_ptr<int> _nbTiroirs;
 
};

Notez que cette fois j'ai mis des unique_ptr !

Est ce que déjà cette idée vous semble pertinente ? Sans danger ? Il y a j'en suis sûr des inconvénients comme avec toutes choses, mais c'est a priori à ça que je pense en ce moment.

[Médinoc]

J'ai du mal à voir pourquoi tu en as fait des pointeurs. Est-ce seulement pour les rendre nullables? Si oui, je suis sûr qu'il y a un meilleur moyen.

[Bousk]

Un pointeur, fut-il unique pour un int... on est dans l'absurde.
Pour nuller un entier, ça s'appelle 0.

[Astraya]

Je vais poser une question bête mais as tu regardé ce qui a été dit dans le thread précèdent concernant ton problème ? A savoir les systèmes d'entités-composants?

J'ai une autre question bête: si il y a des travaux d'agrandissement c'est le même appartement mais plus la même surface (Bon ça c'est pas une question mais une remarque :d)

[fanzilan]

J'ai du mal à voir pourquoi tu en as fait des pointeurs. Est-ce seulement pour les rendre nullables? Si oui, je suis sûr qu'il y a un meilleur moyen.

Pour qu'ils prennent aucune place, comme si ils n'existaient pas. Je cherche un moyen simple de le faire et les deux solutions de koala1 me semblent complexes. Mais si j'ai plus le choix...

Un pointeur, fut-il unique pour un int... on est dans l'absurde.
Pour nuller un entier, ça s'appelle 0.

Merci Bousk. J'ai choisi un int comme j'aurai pu choisir une structure, une classe plus complexe. Je rappelle que cet exemple est une illustration de mon vrai problème (ce que j'ai écrit dans mon post).

Je vais poser une question bête mais as tu regardé ce qui a été dit dans le thread précèdent concernant ton problème ? A savoir les systèmes d'entités-composants?

Oui, tu veux dire que je n'ai vraiment pas le choix et que je DOIS choisir ce que vous m'avez proposé pour éviter d'implémenter quelque chose de casse gueule ?

Il m'a été proposé deux choses : une avec des templates et une avec le design pattern visiteur. Jusque là, les exemples étaient simples mais si j'ai besoin d'avoir des fonctions avec des types de retour ou des arguments plus nombreux, je sais pas si ça va marcher. A moins que je dois aussi créer des "visit" dans la classe visiteur correspondant à ces arguments en plus ? Je sais pas si je suis clair.

Pour info : ma formation n'est pas l'informatique (au cas où ça s'est pas vu) même si j'ai eu des (mauvais) cours en programmation C++ il y a 15 ans.

EDIT : je viens de faire un test, mon truc ne peut effectivement pas marcher. C'est pas ce que j'espérais...

[droggo]

Bonjour,

Pour info : ma formation n'est pas l'informatique (au cas où ça s'est pas vu) même si j'ai eu des (mauvais) cours en programmation C++ il y a 15 ans

L'expérience montre que les mauvais profs sont rares, et que ceux qui les appellent ainsi sont généralement de mauvais élèves, pour rester poli.

[Médinoc]

Pour qu'ils prennent aucune place, comme si ils n'existaient pas. Je cherche un moyen simple de le faire et les deux solutions de koala1 me semblent complexes. Mais si j'ai plus le choix...

Un pointeur prend (presque?) toujours au moins autant de place qu'un int. Et de nos jours, souvent plus (ex: pointeurs 64 bits et int 32 bits).

Tu auras plus vite fait d'utiliser des int avec une valeur "interdite" (genre zéro, -1 ou INT_MIN) pour dire "rien d'intéressant ici".

[fanzilan]

Bonjour,

L'expérience montre que les mauvais profs sont rares, et que ceux qui les appellent ainsi sont généralement de mauvais élèves, pour rester poli.

Ça c'est une insulte à peine voilée. Tu sais pas ce que j'ai vécu, tu sais pas les efforts que j'ai fourni pendant les TDs et les TPs (et surtout en dehors) qui eux étaient plus réussis que le cours lui même (sans doute parce que c'était pas les mêmes intervenants que le cours). Alors si c'était une blague c'est pas drôle. Sinon, je suis pas venu ici pour me faire insulter, point.

Si tu as quelque chose à dire pour m'aider vraiment autre que de la condescendance ou des propos du genre "reprends tout depuis zéro, tu sais pas programmer", t'es le bienvenue. Sinon, merci de laisser les autres m'aider en silence. C'est un forum d'entraide il me semble, pas un forum pour enfoncer les personnes qui sont sur le point de se noyer.

[fanzilan]

Un pointeur prend (presque?) toujours au moins autant de place qu'un int. Et de nos jours, souvent plus (ex: pointeurs 64 bits et int 32 bits).

Tu auras plus vite fait d'utiliser des int avec une valeur "interdite" (genre zéro, -1 ou INT_MIN) pour dire "rien d'intéressant ici".

Je m'en suis rendu compte oui...

Mais non ça ne va pas marcher avec une valeur interdite, il faut carrément pas de valeur du tout.

Ce qui m'emmène au pattern visiteur ou la solution sous la forme d'ECS.

EDIT : au final tu as peut-être raison...ça pourrait résoudre tous mes soucis...

[Bousk]

std::optional
Mais bon, tant qu'on aura pas le vrai problème, on peut tergiverser des mois en rond, ça avancera à rien....
Sinon, demande à tes collègues ? Les chances qu'un débutant incapable de faire un truc soit seul face à son projet sont normalement nulles.

[fanzilan]

Merci à tous.

[kaitlyn]

je viens de faire un test, mon truc ne peut effectivement pas marcher. C'est pas ce que j'espérais...

Salut,

En orientée objet, quand ça finit dans une impasse, c'est généralement dû à un problème mal posé ou mal transcrit. Normalement on part d'un scénario pour arriver au code, mais dans ce que tu montres tu fais le contraire, ton meuble se retrouve alors avec un comportement étrange et des responsabilités inattendues.
Comme tu n'as pas une bonne expérience du langage, je te conseille de rester simple. L'héritage et le polymorphisme dynamique, notions assez classiques et bien documentées, me semble bien adaptés pour ton mobilier (Cf. classe de base abstraite), le compilateur s’occupera de tout. Par ailleurs, unique_ptr c'est bien parce qu'il permet l'unicité d'un meuble et sa possession exclusive. Tu ajoutes un container std::vector d'unique_ptr de mobilier à ta classe appartement et là tu pourras ajouter des meubles, les enlever, les déplacer à coup de std::move. Tu peux peut-être aussi faire intervenir un acteur pour s’occuper de tout ça, un service de conciergerie par exemple (sous forme de classe auxiliaire, aide, utilitaire ou amie) , qui sera peut-être plus à même de vérifier l’adéquation surfaces appartement/meuble en amont, le design de ces classes s'en trouvera alors facilité car elles auront beaucoup moins de responsabilités.