Devo usar classes aninhadas neste caso?

Question

Estou trabalhando em uma coleção de classes usadas para reprodução e gravação de vídeo.Eu tenho uma classe principal que atua como uma interface pública, com métodos como play(), stop(), pause(), record() etc...Depois, tenho aulas robustas que fazem a decodificação e codificação de vídeo.

Acabei de aprender sobre a existência de classes aninhadas em C++ e estou curioso para saber o que os programadores pensam sobre usá-las.Estou um pouco cauteloso e não tenho certeza de quais são os benefícios/desvantagens, mas eles parecem (de acordo com o livro que estou lendo) para serem usados ​​em casos como o meu.

O livro sugere que, em um cenário como o meu, uma boa solução seria aninhar as classes robustas dentro da classe de interface, para que não haja arquivos separados para classes que o cliente não deve usar e para evitar possíveis conflitos de nomenclatura.Não sei sobre essas justificativas.Classes aninhadas são um novo conceito para mim.Só quero ver o que os programadores pensam sobre o assunto.

Answer 1

Eu ficaria um pouco relutante em usar classes aninhadas aqui.E se você criasse uma classe base abstrata para um "driver multimídia" para lidar com o material de back-end (burro de carga) e uma classe separada para o trabalho de front-end?A classe front-end pode pegar um ponteiro/referência para uma classe de driver implementada (para o tipo e situação de mídia apropriados) e executar as operações abstratas na estrutura robusta.

Minha filosofia seria ir em frente e tornar ambas as estruturas acessíveis ao cliente de uma forma refinada, partindo do pressuposto de que seriam usadas em conjunto.

Eu faria referência a algo como um QTextDocument em Qt.Você fornece uma interface direta para a manipulação de dados bare metal, mas passa a autoridade para um objeto como um QTextEdit para fazer a manipulação.

Answer 2

Você usaria uma classe aninhada para criar uma classe auxiliar (pequena) necessária para implementar a classe principal.Ou, por exemplo, para definir uma interface (uma classe com métodos abstratos).

Nesse caso, a principal desvantagem das classes aninhadas é que isso torna mais difícil reutilizá-las.Talvez você queira usar sua classe VideoDecoder em outro projeto.Se você torná-la uma classe aninhada de VideoPlayer, não poderá fazer isso de maneira elegante.

Em vez disso, coloque as outras classes em arquivos .h/.cpp separados, que você poderá usar em sua classe VideoPlayer.O cliente do VideoPlayer agora só precisa incluir o arquivo que declara o VideoPlayer, e ainda não precisa saber como você o implementou.

Answer 3

Uma maneira de decidir se deve ou não usar classes aninhadas é pensar se essa classe desempenha ou não um papel de apoio ou se é sua própria parte.

Se existir apenas com o propósito de ajudar outra classe, geralmente a torno uma classe aninhada.Há uma série de advertências sobre isso, algumas das quais parecem contraditórias, mas tudo se resume à experiência e à intuição.

Answer 4

parece um caso em que você poderia usar o padrão de estratégia

Answer 5

Às vezes é apropriado ocultar as classes de implementação do usuário - nesses casos é melhor colocá-las em foo_internal.h do que dentro da definição de classe pública.Dessa forma, os leitores do seu foo.h não verão o que você prefere que eles não se preocupem, mas você ainda poderá escrever testes em cada uma das implementações concretas da sua interface.

Answer 6

Encontramos um problema com um compilador Sun C++ semi-antigo e visibilidade de classes aninhadas cujo comportamento mudou no padrão.Esta não é uma razão para não fazer sua classe aninhada, é claro, apenas algo que você deve estar ciente se você planeja compilar seu software em muitas plataformas, incluindo compiladores antigos.

Answer 7

Bem, se você usar ponteiros para suas classes de trabalho em sua classe Interface e não os expor como parâmetros ou tipos de retorno em seus métodos de interface, você não precisará incluir as definições para esses cavalos de carga em seu arquivo de cabeçalho de interface (você apenas forward declare-os).Dessa forma, os usuários da sua interface não precisarão saber das classes em segundo plano.

Você definitivamente não precisa aninhar classes para isso.Na verdade, arquivos de classe separados tornarão seu código muito mais legível e fácil de gerenciar à medida que seu projeto cresce.também o ajudará mais tarde se você precisar criar uma subclasse (por exemplo, para diferentes tipos de conteúdo/codec).

Aqui estão mais informações sobre o Padrão PIMPL (seção 3.1.1).

Answer 8

Você deve usar uma classe interna somente quando não puder implementá-la como uma classe separada usando a interface pública da suposta classe externa.As classes internas aumentam o tamanho, a complexidade e a responsabilidade de uma classe, portanto devem ser usadas com moderação.

Sua classe de codificador/decodificador parece se adequar melhor ao Padrão de Estratégia

Answer 9

Um motivo para evitar classes aninhadas é se você pretende agrupar o código com swig (http://www.swig.org) para uso com outros idiomas.Atualmente, o Swig tem problemas com classes aninhadas, portanto, a interface com bibliotecas que expõem quaisquer classes aninhadas torna-se uma verdadeira dor de cabeça.

Answer 10

Outra coisa a ter em mente é se você já imaginou diferentes implementações de suas funções de trabalho (como decodificação e codificação).Nesse caso, você definitivamente desejaria uma classe base abstrata com diferentes classes concretas que implementassem as funções.Não seria realmente apropriado aninhar uma subclasse separada para cada tipo de implementação.