Dois-je utiliser des classes imbriquées dans ce cas ?

Je travaille sur une collection de classes utilisées pour la lecture et l'enregistrement vidéo. J'ai une classe principale qui agit comme l'interface publique, avec des méthodes comme play(), stop(), pause(), record() etc... Ensuite j'ai des classes bourrées qui font le décodage vidéo et l'encodage vidéo.

Je viens d'apprendre l'existence de classes imbriquées en C et je suis curieux de savoir ce que les programmeurs pensent de leur utilisation. Je suis un peu méfiant et je ne sais pas vraiment quels sont les avantages/inconvénients, mais ils semblent (selon le livre que je lis) être utilisés dans des cas comme le mien.

Le livre suggère que dans un scénario comme le mien, une bonne solution serait d'imbriquer les classes de bête de somme dans la classe d'interface, de sorte qu'il n'y ait pas de fichiers séparés pour les classes que le client n'est pas censé utiliser, et d'éviter toute dénomination possible conflits? Je ne connais pas ces justifications. Les classes imbriquées sont un nouveau concept pour moi. Je veux juste voir ce que les programmeurs pensent du problème.

0 commentaires
Classification:catégorie par défaut

Tri par défaut ordre chronologique

5 réponses

graham.reeds 2022-12-10 08:22

Une façon de décider d'utiliser ou non des classes imbriquées est de penser si oui ou non cette classe joue un rôle de soutien ou si c'est sa propre partie.

S'il existe uniquement dans le but d'aider une autre classe, j'en fais généralement une classe imbriquée. Il y a toute une série de mises en garde à cela, dont certaines semblent contradictoires, mais tout se résume à l'expérience et à l'intuition.

0124816 2022-12-10 08:24

Parfois, il est approprié de cacher les classes d'implémentation à l'utilisateur - dans ces cas, il est préférable de les mettre dans un foo_internal.h plutôt qu'à l'intérieur de la définition de classe publique. De cette façon, les lecteurs de votre foo.h ne verront pas ce avec quoi vous préféreriez qu'ils ne soient pas dérangés, mais vous pouvez toujours écrire des tests sur chacune des implémentations concrètes de votre interface.

Frederik Slijkerman 2022-12-10 08:25

Vous utiliseriez une classe imbriquée pour créer une (petite) classe d'assistance requise pour implémenter la classe principale. Ou par exemple, pour définir une interface (une classe avec des méthodes abstraites).

Dans ce cas, le principal inconvénient des classes imbriquées est qu'il est plus difficile de les réutiliser. Vous aimeriez peut-être utiliser votre classe VideoDecoder dans un autre projet. Si vous en faites une classe imbriquée de VideoPlayer, vous ne pouvez pas le faire de manière élégante.

Au lieu de cela, placez les autres classes dans des fichiers .h/.cpp séparés, que vous pourrez ensuite utiliser dans votre classe VideoPlayer. Le client de VideoPlayer n'a plus qu'à inclure le fichier qui déclare VideoPlayer, et n'a toujours pas besoin de savoir comment vous l'avez implémenté.

Allan Wind 2022-12-10 08:29

Nous avons rencontré un problème avec un compilateur Sun C semi-ancien et la visibilité des classes imbriquées dont le comportement a changé dans la norme. Ce n'est pas une raison pour ne pas faire votre classe imbriquée, bien sûr, juste quelque chose à savoir si vous envisagez de compiler votre logiciel sur de nombreuses plates-formes, y compris d'anciens compilateurs.

Michael Mathews 2022-12-10 08:30

Une autre chose à garder à l'esprit est de savoir si vous envisagez différentes implémentations de vos fonctions de travail (telles que le décodage et l'encodage). Dans ce cas, vous voudriez certainement une classe de base abstraite avec différentes classes concrètes qui implémentent les fonctions. Il ne serait pas vraiment approprié d'imbriquer une sous-classe distincte pour chaque type d'implémentation.

Dois-je utiliser des classes imbriquées dans ce cas ?

5 réponses

problème similaire