Devo usar classes aninhadas neste caso?

votos
42

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

Eu só aprendeu sobre a existência de classes aninhadas em C ++, e estou curioso para saber o que os programadores pensar em usá-los. Eu sou um pouco cauteloso e não realmente certo o que os benefícios / desvantagens são, mas eles parecem (de acordo com o livro que estou lendo) a ser utilizado em casos como o meu.

O livro sugere que em um cenário como o meu, uma boa solução seria a de ninho das classes laborioso dentro da classe de interface, para que não haja arquivos separados para as classes do cliente não tem a intenção de usar, e para evitar qualquer possível conflito de nomeação? Eu não sei sobre essas justificativas. classes aninhadas são um conceito novo para mim. Só quero ver o que os programadores pensar sobre o assunto.

Publicado 02/08/2008 em 03:51
fonte usuário
Em outras línguas...                            


10 respostas

votos
25

Eu seria um pouco relutantes em usar classes aninhadas aqui. E se você criou uma classe base abstrata para um "driver multimedia" para lidar com as coisas de back-end (cavalo de batalha), e uma classe separada para o trabalho front-end? A classe front-end poderia levar um ponteiro / referência a uma classe condutor implementada (para o tipo de suporte adequado e situação) e realizar as operações sumário sobre a estrutura laborioso.

Minha filosofia seria ir em frente e fazer ambas as estruturas acessível ao cliente de uma forma polida, apenas sob a suposição de que eles seriam usados ​​em conjunto.

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

Respondeu 02/08/2008 em 04:00
fonte usuário

votos
9

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

Neste caso, a principal desvantagem de classes aninhadas é que isso torna mais difícil para voltar a usá-los. Talvez você gostaria de usar sua classe VideoDecoder em outro projeto. Se você faz uma classe aninhada da reprodutor de vídeo, você não pode fazer isso de uma maneira elegante.

Em vez disso, coloque as outras classes em arquivos .h / .cpp separadas, que você pode usar em sua classe VideoPlayer. O cliente de VideoPlayer agora só precisa incluir o arquivo que declara reprodutor de vídeo, e ainda não precisa saber sobre como você implementou.

Respondeu 17/09/2008 em 12:50
fonte usuário

votos
5

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

Se ele existe unicamente para o propósito de ajudar uma outra classe, então eu geralmente torná-lo uma classe aninhada. Há toda uma carga de advertências para que, alguns dos quais parecem contraditórias, mas tudo se resume a experiência e gut-sensação.

Respondeu 05/08/2008 em 09:29
fonte usuário

votos
4

Bem, se você usar ponteiros para suas classes laborioso em sua classe Interface e não expô-los como parâmetros ou tipos de retorno em seus métodos de interface, você não precisa incluir as definições para os cavalos de trabalho em seu arquivo de cabeçalho de interface (você só frente declará-los em vez). Dessa forma, os usuários da sua interface não precisa saber sobre as classes no fundo.

Você definitivamente não precisa de aulas de ninho para isso. Na verdade, arquivos de classe separados vai realmente fazer o seu código muito mais legível e mais fácil de gerir como seu projeto cresce. que também irá ajudá-lo mais tarde, se você precisa subclasse (dizer para diferentes tipos de conteúdo / codec).

Aqui está mais informações sobre o padrão de Pimpl (seção 3.1.1).

Respondeu 26/09/2008 em 00:34
fonte usuário

votos
4

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

Respondeu 21/09/2008 em 01:39
fonte usuário

votos
4

Às vezes é apropriado para esconder as classes de implementação do usuário - nestes casos, é melhor colocá-los em um foo_internal.h do que dentro da definição de classe pública. Dessa forma, os leitores de seu foo.h não vai ver o que você preferir não ser incomodado com, mas você ainda pode escrever testes contra cada uma das implementações concretas da sua interface.

Respondeu 16/09/2008 em 10:31
fonte usuário

votos
4

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

Respondeu 05/08/2008 em 09:37
fonte usuário

votos
2

Você deve usar uma classe interna somente quando você não pode implementá-lo como uma classe separada usando o candidato a interface pública da classe externa. classes internas aumentar o tamanho, complexidade e responsabilidade de uma classe para que eles devem ser usados ​​com moderação.

Sua classe codificador / decodificador soa como ele se encaixa melhor o padrão de estratégia

Respondeu 18/09/2008 em 16:19
fonte usuário

votos
1

Outro aspecto a ter em mente é se você nunca imaginar diferentes implementações de suas funções de trabalho (como codificação e decodificação). Nesse caso, você iria querer uma classe base abstrata com classes concretas diferentes que implementam as funções. Não seria realmente apropriado para aninhar uma subclasse separada para cada tipo de aplicação.

Respondeu 23/09/2008 em 20:07
fonte usuário

votos
1

Uma das razões para evitar classes aninhadas é se você nunca pretende envolver o código com gole ( http://www.swig.org ) para uso com outras línguas. Gole tem atualmente problemas com classes aninhadas, de modo a interface com bibliotecas que expõem quaisquer classes aninhadas torna-se uma dor real.

Respondeu 20/09/2008 em 08:37
fonte usuário

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