positionement des fonctions de vérfications et interutilisation des classes
Une ville est constitué de 2 listes de pointeurs (une link* et une district*, les objets sont donc crée en utilisant new).
Un district est constitué d'une liste de link* qui sont le liens concernant les district en question
Un link est constitué de de 2 pointeurs sur des districts.
Celà nous amène à 3 questions
1. Nous avons déclarés une class District vide dans link.h, comme ceci
Class District;
Class Link{
...
}
Ce qui nous force à ensuite définir cette classe au début du .cc donc nous avons ceci au début du link.cpp
#include<link.h>
#include<district.h>
ce qui ne marche que si on se limite a utiliser des pointeurs de district dans la classe link.
Notre question est la suivante: est-ce autorisé par les conventions, sinon quel est le moyen "conventionné" de parer à ce problème ?
2. Il est spécifié dans les specs de rendu 1 que l'on doit pouvoir créer un district en lui envoyant directement la ligne du fichier sauvegardé, ce qui revient a dire que toutes les vérifications concernant la création d'un district doivent avoir lieu dans le constructeur de district. Cela revient aussi à dire que les constructeur de district doit avoir accès aux listes de city.
Notre approche jusqu'a maintenant à été de dire que la création d'un quartier se faisait au niveau de la ville et que les vérifications associées se faisaient aussi au niveau de la ville (ce qui certes laisser la place pour la création d'un district non vérifié, mais vu que de toute façon ce district ne serait pas crée avec new et qu'il ne serait pas rajouté à la liste des district amoins qu'il ait été crée par notre fonction de city (qui elle vérifie tout), il serait donc immédiatement détruit, donc au final cela ne change rien). Somme nous donc obligés de faire toute les vérifications au sein de district ou pouvons nous faire cela dans city comme nous le faisons ?
3:
La 3 ème question est un peu hors sujet mais il est dit dans le mooc d'éviter d'utiliser friend. Le truc c'est que nous utilisons beaucoup de surcharge d'opérateur dans tools et que l'un d'eux permet de cout et que le seul moyen que l'on à trouvé pour y' parvenir état de lier iostream et notre struct Point avec friend. Est-ce toleré ?
Cordialement Mathieu Ziegler
1. Nous avons déclarés une class District vide dans link.h, comme ceci
Class District;
ceci s'appelle une "prédéclaration" de la classe ; c'est un élément de la solution pour résoudre le problème des includes mutuels de 2 modules.
Une solution plus clean que celle que vous décrivez est la suivante.
Supposons que 2 modules A et B définissent des classes A et B interdépendantes (comme vous, avec des pointeurs)
Dans A.h : mettre la prédéclaration de la classe A avant d'inclure l'interface du module B (qui contient l'interface de la classe B) qui elle même est avant de donner les détails de l'interface de la classe A, comme ci-dessous:
class A;
#include "B.h"
class A{
...
};
Dans B.h : même principe, mettre
la prédéclaration de la classe B avant d'inclure l'interface du module A
(qui contient l'interface de la classe A) qui elle même est avant de
donner les détails de l'interface de la classe B, comme ci-dessous:
class B;
#include "A.h"
class B{
...
};
2. Il est spécifié dans les specs de rendu 1 que l'on doit pouvoir créer un district en lui envoyant directement la ligne du fichier sauvegardé, ce qui revient a dire que toutes les vérifications concernant la création d'un district doivent avoir lieu dans le constructeur de district. Cela revient aussi à dire que les constructeur de district doit avoir accès aux listes de city.
Si vous voulez que District obtienne ces listes, il doit les obtenir en paramètre d'une fonction ou méthode qu'il met à disposition dans son interface.
Selon l'architecture du projet ni District, ni Link ne doivent être dépendants de ville (pas de #include "ville.h" dans ces 2 modules).
Notre approche jusqu'a maintenant à été de
dire que la création d'un quartier se faisait au niveau de la ville et
que les vérifications associées se faisaient aussi au niveau de la ville
(ce qui certes laisser la place pour la création d'un district non
vérifié, mais vu que de toute façon ce district ne serait pas crée avec
new et qu'il ne serait pas rajouté à la liste des district amoins qu'il
ait été crée par notre fonction de city (qui elle vérifie tout), il
serait donc immédiatement détruit, donc au final cela ne change rien).
Somme nous donc obligés de faire toute les vérifications au sein de
district ou pouvons nous faire cela dans city comme nous le faisons ?
plusieurs message sur le forum ont déjà validé le fait que les vérifications géométriques ou de la cohérence du graphe pouvaient être pilotées depuis le niveau ville
3: La
3 ème question est un peu hors sujet mais il est dit dans le mooc
d'éviter d'utiliser friend. Le truc c'est que nous utilisons beaucoup de
surcharge d'opérateur dans tools et que l'un d'eux permet de cout et
que le seul moyen que l'on à trouvé pour y' parvenir état de lier
iostream et notre struct Point avec friend. Est-ce toleré ?
le cours donne une méthode très simple pour ne pas utiliser friend dans la redéfinition de << : la fonction de surcharge externe appelle une méthode affiche sur l'opérande droit. Donc pas de friend.
- Selon les conventions O31 et O33.1, les déclarations anticipées de type structure viennent après les #include. Est-ce que les classe sont considérés comme les struct? Dans ce cas prédéclarer une classe avant les #include ne briserai pas les conventions?
- Si non, dans le cas de plusieurs #include, notre fichier devrait avoir la forme:
#include ".."
class B;
#include<..>
#include "..."
#include "A.h"
- Si le code compile avec seullement une prédeclaration dans une des deux classses interdépendantes, faut-il en tout cas mettre les 2 prédeclarations dans les 2 fichiers?
#include <..>
#include ".."
class B;