Diagrammes C++ et UML

Question

Soit les classes A et B qui sont les héritiers de la classe C. Tous sont dans un fichier.cpp avec la méthode main de la classe Main. Si je veux créer une instance de A ... puis classe

file.cpp

class C{ 
} 

class A : public C{ 
} 

class B : public C{ 
} 
class Main{ 
. 
. 
. 
void main(){ 
    C *c = new A(); 
} 
} 

Lorsqu'un UML diagramme est

Maintenant, supposons que j'ai les mêmes classes mais chaque classe dans un fichier différent. Si je veux instancier la classe A, comme ci-dessus, j'aurais inséré une directive #include Ah dans la classe Main qui ferait apparaître une dépendance dans mon diagramme:

Ma question est: Quel cas est correct si je le voulais Faire la même chose? ou j'interprète mal les relations UML en C++?

Answer 1

Tout d'abord, vous ne devriez pas mettre le code dans les fichiers .h sauf si vous savez ce que vous faites (voir inline functions, principalement utilisé pour la vitesse)

Puis, en main.h, vous ne avez pas besoin de référence R. Dans main.cpp cependant, vous devrez inclure Ah Rappelez-vous que UML est agnostique, il est utilisé pour dessiner "qui parle à qui" plutôt que "qui compile avec qui".

Le plus souvent, votre compilateur C++ génère un fichier de sortie (avec gcc ce sont des fichiers .o, Visual Studio le fait aussi de manière transparente) pour chaque fichier cpp. Tous les fichiers de sortie seront alors fusionnés ensemble (la plupart du temps) dans votre application ou votre bibliothèque et seulement alors votre fonction sera liée.

Vous pouvez également jeter un coup d'œil à forward references. C'est pour dire au compilateur (pas à l'éditeur de liens) que "cette classe existe, vous ne le savez peut-être pas en ce moment, mais je jure devant Dieu qu'elle existera dans le blob".

Dans votre cas particulier, je dessinerais le diagramme de classes comme votre deuxième exemple, que vous n'utilisiez qu'un ou plusieurs fichiers cpp. Votre classe principale ne sait sur A.

Maintenant, imaginez que votre classe C ont des méthodes telles que

A* C::createA() 
{ 
    return new A; 
} 

B* C::createB() 
{ 
    return new B; 
} 

Ensuite, votre classe principale aurait

int main() 
{ 
    C* instance1 = C::createA(); 
    C* instance2 = C::createB(); 
} 

Dans ce cas, votre classe principale perdrait toutes les connaissances intimes de A et B, conformes à votre premier schéma. Cela créerait bien sûr plus de couplage entre A, B et C, ce qui apporte ses propres problèmes mais est plus proche d'un factory pattern

Answer 2

Vous devez utiliser la composition relation montrer que Maina-une instance de C. Je n'ai jamais documenté quels fichiers doivent être inclus, car il est supposé que si vous avez besoin de la fonctionnalité d'une classe qui réside dans un autre fichier, vous aurez probablement besoin d'un include.

EDIT: En fait, il n'y a pas de composition , comme il vous semble Main classe a une des méthodes appelées main() qui crée une instance de la classe C, et n'est pas membre lui-même.

Answer 3

Je ne pense pas qu'il soit nécessaire d'avoir les relations has-a comme dans le second diagramme parce qu'il est implicite.

A est un un C, B est-un C et principal a-un C.

Son plus sur la structure de votre conception que includes dans vos fichiers.