Répartition de nombreuses petites classes

Question

J'ai une classe de base appelée EventArgs. Dérivé de cette situation sont nombreuses, de nombreuses spécialités qui représentent des arguments d'événements pour un type particulier d'événement. Les consommateurs de ces événements peuvent avoir besoin, beaucoup, ou très peu de ces classes d'argument.

Ma question est, pourriez-vous fournir un fichier d'en-tête pour chaque type (par exemple, plus de 50 fichiers d'en-tête pour les différentes), tenteriez-vous de les regrouper pour les familles et ont une « commune «fichier d'en-tête pour ceux-ci, ou voulez-vous jeter la prudence à la fenêtre et les jeter dans un seul fichier d'en-tête facile d'utilisation qui peut juste être inclus?

Une autre approche pourrait être d'avoir 50 fichiers d'en-tête, puis je pourrais présenter certains fichiers d'en-tête « famille » qui comprenait les particuliers. Vous ne savez pas sur les conventions de nommage pour ce genre de choses donc il est évident ce qui est où.

Je sais qu'il ne peut y avoir une règle dure et rapide, mais se demander ce que les autres développeurs ont fait quand ils se trouvent en écrivant beaucoup de petites classes.

Merci à l'avance.

Answer 1

Je dois mettre deux classes en-têtes séparés dans l'un des cas suivants:

• ils sont énormes
• ils ne sont pas liés ou peu susceptibles d'être utilisés ensemble
• chacun d'eux présente ses propres dépendances d'en-tête

Dans le cas contraire, il ne fait pas beaucoup de sens pour les séparer. Je sais que certaines personnes ont cette règle « une classe par tête », mais il ne semble pas raisonnable dans votre cas.

Qu'est-ce que pour les « familles » y compris beaucoup de petits fichiers, dans certains systèmes de construction (et les systèmes de fichiers) cela pourrait avoir un impact sur le temps de compilation, et en tout cas je ne vois pas un point à faire cela - habituellement les gens utiliseront documentation ou IDE pour trouver des classes, ne regarde pas les noms de fichiers en-têtes. Donc, vous ne le faire que pour simplifier l'inclusion, mais alors pourquoi ne pas les mettre dans le même en-tête.

Answer 2

Je les groupe dans les familles selon les classes que les utilisateurs voudront probablement utiliser ensemble. 50+ petits fichiers d'en-tête semble excessive dans tous les cas.

Answer 3

Impossible toutes les variantes des modèles être?

Answer 4

Je suis dans une situation similaire où je développais une bibliothèque graphique. Initally tous les composants (ils étaient des petites classes) partageaient le même fichier d'en-tête et la source. Cela a fonctionné assez bien. Plus tard, je tentais de les mettre dans des fichiers séparés mais vraiment ne rien améliorer. Il a seulement ajouté la charge de passer beaucoup de temps à travers la recherche de ces fichiers.

A part ça, vous pouvez peut-être tirer un peu d'inspiration de la bibliothèque de Poco C. Cette bibliothèque suit généralement une classe par idiome d'en-tête, mais il y a des exceptions. Par exemple toute la hiérarchie d'exception est codée sur un fichier d'en-tête et source à l'aide d'un système à base de macro (voir Exception.h et Exception.cpp ).

Answer 5

si elles appartiennent à une même hiérarchie d'héritage, les mettre dans le même fichier .h. Il vous aide à décider ordre pour les classes. L'un des moins connu la vérification de la compilation en c ++ repose sur l'ordre des classes dans .h fichier.