Pergunta

Já enfrentei este problema, muitas vezes durante o último par de meses, durante o qual eu tenho vindo a construir este sistema. O cenário é o seguinte: eu tenho esse tipo de objeto que é essencialmente uma lista de outros objetos, mas tem algumas outras propriedades específicas de sua natureza. Por exemplo:

  • Class Tests:
    • contém muitos objetos Test
    • Tem propriedades:
      • DefaultTimeouts
      • DefaultNumberOfTries

Eu deveria ter List<Test> esta classe subclasse ou devo tê-lo herdando de Object, simplesmente ter a lista como uma propriedade ao lado dos outros campos?

Eu sei que isso pode ser um pouco subjetiva e gosto pessoal pode desempenhar um papel aqui, mas eu sinceramente gostaria de saber a sua opinião sobre este assunto.

Foi útil?

Solução

Ao contrário do que a maioria das respostas aqui eu não subclasse da lista na maioria dos casos. Descobri que herdando de uma classe para a funcionalidade reutilização geralmente causa problemas mais tarde.

Eu normalmente só tem uma propriedade do tipo List (ou IList) que retorna uma referência à lista. Normalmente, você só precisa de uma propriedade get aqui. Você pode controlar o acesso à lista, escolhendo para retornar uma versão somente leitura da lista com .AsReadOnly () ou apenas expor a lista como um IEnumerable.

Em casos onde eu quero testes para ser uma lista Eu costumo implementar IList e ligar para um campo Lista interno para as implementações reais do IList. Isto é um pouco mais de trabalho e resulta em mais algum código para manter, mas descobri que isso é melhor do que o sustentável herdar Lista apenas para a sua implementação.

Outras dicas

Sub-classe a partir de List . Se você não tem a lista genérico como uma propriedade, é bem encapsulado como uma sub-classe.

Se ele se parece com um List e soa como um List , provavelmente é um List .

Eu diria que é um TestCollection.

Se ele literalmente faz tudo que um List faria, e todas as funções List agiria no objeto Tests de uma forma intuitiva, que dá o resultado correto, em seguida, na minha opinião, deve apenas subclasse List<Test>.

Caso contrário, você vai ter uma classe com uma tonelada de métodos que apenas chamar um método com o mesmo nome na variável List<Test> na instância. Isso só vai ser uma extensão imperfeita da própria classe List<Test>.

Inheritance geralmente mapeia para um "é-um" relacionamento. Desde o seu recipiente é um lista, mas com algumas outras coisas, eu herdaria da lista e adicione suas propriedades adicionais para sua subclasse.

Eu não acho que você tem é um simples "lista de testes," porque você precisava de algo mais. Sugiro que você chamá-lo TestSuite e fazer a lista como uma propriedade. Tem-a é muito mais fácil de manter em relação a herança.

Em geral, eu ficaria muito cuidado para algo herdar como um List.

Ao ler as respostas, parece que a questão chave é para o comprimento é o objeto realmente uma lista? Então, talvez um bom compromisso entre os perigos da herança e da falta de transparência da composição seria ter um List<Test> como um backend privado e para expor apenas os métodos que seriam usados.

"composição Favor sobre a herança" é sempre uma boa regra de ouro. São os métodos que utilizam esta classe usando todos os métodos de lista, bem como os que você adicionar ou apenas os que você adicionar?

No seu exemplo você disse "testes de classe contém muitos objetos de teste", não "Classe Testa é um conjunto de testes de objetos". IMO não é necessário a subclasse Lista neste cenário, a menos que você precisa ter List-como interface para esta classe.

No entanto, a resposta realmente depende do contexto da classe testes. Se ele se comporta como List e será utilizado em contextos onde Lista de objetos é esperado, herdar da lista.

Note que a herança é mais difícil de manter do que composição.

Além disso, gostaria renomear testes para TestCollection (se você subclasse List), ou algo parecido TestUnit (se ele conteria lista de classes de teste.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top