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

voix
42

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 telles que play(), stop(), pause(), record()etc ... Ensuite , j'ai des classes de bourreau de travail 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 à leur utilisation. Je suis un peu méfiant et pas vraiment sûr de ce que les avantages / inconvénients sont, mais ils semblent (selon le livre que je lis) à utiliser dans des cas comme le mien.

Le livre suggère que, dans un scénario comme le mien, une bonne solution serait nicher les classes cheval de bataille à l'intérieur de la classe d'interface, donc il n'y a pas des fichiers séparés pour les classes du client ne vise pas à utiliser, et pour éviter tout conflit de noms possibles? Je ne sais pas au sujet de ces justifications. Les classes imbriquées sont un nouveau concept pour moi. Je veux juste voir ce que les programmeurs pensent de la question.

Créé 02/08/2008 à 03:51
source utilisateur
Dans d'autres langues...                            


10 réponses

voix
25

Je serais un peu réticent à utiliser les classes imbriquées ici. Que faire si vous avez créé une classe de base abstraite pour un « pilote multimédia » pour gérer les choses back-end (cheval de bataille), et une catégorie distincte pour le travail frontal? La classe frontal pourrait prendre un pointeur / référence à une classe de pilote mis en œuvre (pour le type et la situation des médias appropriés) et effectuer les opérations abstraites sur la structure de cheval de bataille.

Ma philosophie serait d'aller de l'avant et de faire les deux structures accessibles au client d'une manière polie, juste sous l'hypothèse qu'ils seraient utilisés en tandem.

Je référence quelque chose comme un QTextDocument dans Qt. Vous fournissez une interface directe à la manipulation des données en métal nu, mais passer l'autorité le long d'un objet comme une QTextEdit faire la manipulation.

Créé 02/08/2008 à 04:00
source utilisateur

voix
9

Vous utilisez une classe imbriquée pour créer une (petite) classe d'aide qui est nécessaire pour mettre en œuvre 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 que cela rend plus difficile de les réutiliser. Peut-être que vous souhaitez utiliser votre classe VideoDecoder dans un autre projet. Si vous faites une classe imbriquée de VideoPlayer, vous ne pouvez pas faire cela d'une manière élégante.

Au lieu de cela, mettre les autres classes dans les fichiers .h / .cpp séparés, que vous pouvez ensuite utiliser dans votre classe VideoPlayer. Le client de VideoPlayer maintenant besoin que d'inclure le fichier qui déclare VideoPlayer, et n'a toujours pas besoin de savoir sur la façon dont vous a mise en œuvre.

Créé 17/09/2008 à 12:50
source utilisateur

voix
5

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

Si elle existe uniquement dans le but d'aider une autre classe alors je fais généralement une classe imbriquée. Il y a un tas de mises en garde à cela, dont certains semblent contradictoires, mais tout se résume à l'expérience et de l'intestin sentiment.

Créé 05/08/2008 à 09:29
source utilisateur

voix
4

Eh bien, si vous utilisez des pointeurs vers vos classes de bête de somme dans votre classe d'interface et ne les exposez pas en tant que paramètres ou retour types dans vos méthodes d'interface, vous aurez pas besoin d'inclure les définitions pour les chevaux de travail dans votre fichier d'en-tête d'interface (vous venez avant de les déclarer à la place). De cette façon, les utilisateurs de votre interface ne sera pas besoin de savoir sur les classes en arrière-plan.

Vous certainement ne pas besoin de classes de nid pour cela. En fait, les fichiers de classe distincts seront effectivement rendre votre code beaucoup plus lisible et plus facile à gérer que votre projet se développe. il vous aidera également à plus tard si vous avez besoin de sous-classe (dire pour différents contenus / types de codecs).

Voici plus d' informations sur le modèle de PIMPL (section 3.1.1).

Créé 26/09/2008 à 00:34
source utilisateur

voix
4

Nous avons frappé un problème avec un compilateur semi-vieux Sun C ++ et la visibilité des classes imbriquées qui ont changé le comportement dans la norme. Ce n'est pas une raison de ne pas faire votre classe imbriquée, bien sûr, juste quelque chose à être au courant si vous envisagez de compiler votre logiciel sur beaucoup de plates-formes, y compris les anciens compilateurs.

Créé 21/09/2008 à 01:39
source utilisateur

voix
4

Parfois, il est approprié de masquer les classes d'implémentation de l'utilisateur - dans ces cas, il est préférable de les mettre dans un foo_internal.h que dans la définition de la classe publique. De cette façon, les lecteurs de votre foo.h ne verra pas ce que vous préféreriez qu'ils ne soient pas troublés par, mais vous pouvez toujours écrire des tests contre chacune des mises en œuvre concrètes de votre interface.

Créé 16/09/2008 à 10:31
source utilisateur

voix
4

sonne comme un cas où vous pouvez utiliser le modèle de stratégie

Créé 05/08/2008 à 09:37
source utilisateur

voix
2

Vous devez utiliser une classe interne que lorsque vous ne pouvez pas le mettre en œuvre en tant que classe distincte à l'aide de la soi-interface publique de la classe externe. Les classes internes augmentent la taille, la complexité et la responsabilité d'une classe, ils devraient être utilisés avec parcimonie.

Votre sons encodeur / décodeur de classe comme il correspond mieux à la modèle de stratégie

Créé 18/09/2008 à 16:19
source utilisateur

voix
1

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

Créé 23/09/2008 à 20:07
source utilisateur

voix
1

L' une des raisons pour éviter les classes imbriquées est si vous avez l' intention jamais d'envelopper le code avec rasade ( http://www.swig.org ) pour une utilisation avec d' autres langues. Rasade a actuellement des problèmes avec des classes imbriquées, donc l' interface avec les bibliothèques qui exposent toutes les classes imbriquées devient une vraie douleur.

Créé 20/09/2008 à 08:37
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more