Qual seria a desvantagem de definir uma classe como uma subclasse de uma lista própria?

Em um projeto recente, defini uma classe com o seguinte cabeçalho:

public class Node extends ArrayList<Node> {
    ...
}

No entanto, depois de discutir com meu professor de CS, ele afirmou que a classe seria "horrível para a memória" e "má prática". Não achei o primeiro particularmente verdadeiro e o segundo subjetivo.

Meu raciocínio para esse uso é que eu tinha uma ideia para um objeto que precisava ser definido como algo que pudesse ter profundidade arbitrária, em que o comportamento de uma instância pudesse ser definido por uma implementação customizada ou pelo comportamento de vários objetos semelhantes interagindo . Isso permitiria a abstração de objetos cuja implementação física seria composta de muitos subcomponentes interagindo.¹

Por outro lado, vejo como isso pode ser uma prática ruim. A idéia de definir algo como uma lista em si não é simples ou fisicamente implementável.

Existe algum motivo válido para eu não usar isso no meu código, considerando o meu uso?

¹ Se eu precisar explicar isso mais, ficaria feliz em; Estou apenas tentando manter essa pergunta concisa.

Francamente, não vejo a necessidade de herança aqui. Isso não faz sentido; Node é um ArrayList dos Node?

Se isso é apenas uma estrutura de dados recursiva, você simplesmente escreveria algo como:

public class Node {
    public String item;
    public List<Node> children;
}

O que faz sentido; O nó possui uma lista de nós filhos ou descendentes.

O argumento “horrível para a memória” está totalmente errado, mas é objetivamente uma “má prática”. Quando você herda de uma classe, não herda apenas os campos e métodos nos quais está interessado. Em vez disso, herda tudo . Todo método declarado, mesmo que não seja útil para você. E o mais importante, você também herda todos os seus contratos e garante que a classe fornece.

O acrônimo SOLID fornece algumas heurísticas para um bom design orientado a objetos. Aqui, o I nterface Segregação Princípio (ISP) eo L iskov Substituição Pricinple (LSP) tem algo a dizer.

O ISP nos diz para manter nossas interfaces o menor possível. Mas, ao herdar de ArrayList, você obtém muitos, muitos métodos. É significativo para get(), remove(), set()(substituir), ou add()(inserir) um nó filho em um índice específico? É sensato à ensureCapacity()lista subjacente? O que isso significa para sort()um nó? Os usuários da sua classe realmente deveriam receber um subList()? Como você não pode ocultar os métodos que não deseja, a única solução é ter o ArrayList como uma variável de membro e encaminhar todos os métodos que você realmente deseja:

private final ArrayList<Node> children = new ArrayList();
public void add(Node child) { children.add(child); }
public Iterator<Node> iterator() { return children.iterator(); }

Se você realmente deseja todos os métodos que vê na documentação, podemos seguir para o LSP. O LSP nos diz que devemos poder usar a subclasse onde quer que a classe pai seja esperada. Se uma função usa um ArrayListparâmetro as e passamos o nosso Node, nada deve mudar.

A compatibilidade das subclasses começa com coisas simples, como assinaturas de tipo. Quando você substitui um método, não pode tornar os tipos de parâmetro mais rigorosos, pois isso pode excluir usos legais da classe pai. Mas isso é algo que o compilador verifica para nós em Java.

Mas o LSP é muito mais profundo: precisamos manter a compatibilidade com tudo o que é prometido pela documentação de todas as classes e interfaces-pai. Em sua resposta , Lynn encontrou um desses casos em que a Listinterface (que você herdou por ArrayList) garante como os métodos equals()e hashCode()devem funcionar. Pois hashCode()você recebe um algoritmo específico que deve ser implementado exatamente. Vamos supor que você tenha escrito isso Node:

public class Node extends ArrayList<Node> {
  public final int value;

  public Node(int value, Node... children) {
    this.value = Value;
    for (Node child : children)
      add(child);
  }

  ...

}

Isso requer que o valuenão possa contribuir para hashCode()e não possa influenciar equals(). A Listinterface - que você promete honrar herdando dela - precisa new Node(0).equals(new Node(123))ser verdadeira.

Como a herança de classes facilita demais a quebra acidental de uma promessa feita por uma classe pai e, como geralmente expõe mais métodos do que você pretendia, geralmente é sugerido que você prefira composição do que herança . Se você deve herdar algo, é recomendável herdar apenas interfaces. Se você deseja reutilizar o comportamento de uma classe específica, pode mantê-lo como um objeto separado em uma variável de instância, para que todas as suas promessas e requisitos não sejam impostos a você.

Às vezes, nossa linguagem natural sugere uma relação de herança: um carro é um veículo. Uma motocicleta é um veículo. Devo definir classes Care Motorcycleque herdam de uma Vehicleclasse? O design orientado a objetos não se trata de espelhar o mundo real exatamente em nosso código. Não podemos codificar facilmente as ricas taxonomias do mundo real em nosso código fonte.

Um exemplo é o problema de modelagem empregado-chefe. Temos vários Persons, cada um com um nome e endereço. Um Employeeé um Persone tem um Boss. A Bosstambém é a Person. Então, devo criar uma Personclasse que é herdada por Bosse Employee? Agora eu tenho um problema: o chefe também é funcionário e tem outro superior. Então parece que Bossdeveria se estender Employee. Mas o CompanyOwneré um Bossmas não é um Employee? De qualquer forma, qualquer tipo de gráfico de herança será dividido aqui.

OOP não é sobre hierarquias, herança e reutilização de classes existentes, é sobre generalizar o comportamento . OOP é sobre "Eu tenho vários objetos e quero que eles façam uma coisa em particular - e não me importo como." É para isso que servem as interfaces . Se você implementar a Iterableinterface para o seu computador Nodeporque deseja torná-lo iterável, tudo bem. Se você implementar a Collectioninterface porque deseja adicionar / remover nós filhos, etc., tudo bem. Mas herdar de outra classe, porque isso lhe dá tudo o que não é, ou pelo menos não, a menos que você tenha pensado cuidadosamente, conforme descrito acima.

Estender um contêiner por si só é geralmente aceito como uma má prática. Há realmente muito pouca razão para estender um contêiner em vez de apenas ter um. Estender um contêiner de você mesmo o torna ainda mais estranho.

Além do que foi dito, há um motivo específico de Java para evitar esse tipo de estrutura.

O contrato do equalsmétodo para listas exige que uma lista seja considerada igual a outro objeto

se e somente se o objeto especificado também for uma lista, ambas as listas terão o mesmo tamanho e todos os pares de elementos correspondentes nas duas listas serão iguais .

Fonte: https://docs.oracle.com/javase/7/docs/api/java/util/List.html#equals(java.lang.Object)

Especificamente, isso significa que ter uma classe projetada como uma lista em si mesma pode tornar caras as comparações de igualdade (e cálculos de hash também se as listas forem mutáveis) e, se a classe tiver alguns campos de instância, eles deverão ser ignorados na comparação de igualdade. .

Em relação à memória:

Eu diria que isso é uma questão de perfeccionismo. O construtor padrão de se ArrayListparece com isso:

public ArrayList(int initialCapacity) {
     super();

     if (initialCapacity < 0)
         throw new IllegalArgumentException("Illegal Capacity: "+ initialCapacity);

     this.elementData = new Object[initialCapacity];
 }

public ArrayList() {
     this(10);
}

Fonte . Este construtor também é usado no Oracle-JDK.

Agora considere construir uma lista vinculada individualmente com seu código. Você acabou de aumentar com sucesso o seu consumo de memória pelo fator 10x (para ser mais preciso, ainda que marginalmente mais alto). Para as árvores, isso pode facilmente ficar muito ruim sem requisitos especiais sobre a estrutura da árvore. Usar uma LinkedListou outra classe como alternativa deve resolver esse problema.

Para ser sincero, na maioria dos casos isso não passa de mero perfeccionismo, mesmo que ignoremos a quantidade de memória disponível. A LinkedListdesaceleraria um pouco o código como alternativa, por isso é uma troca entre desempenho e consumo de memória de qualquer maneira. Ainda assim, minha opinião pessoal sobre isso seria não desperdiçar tanta memória de uma maneira que possa ser tão facilmente contornada quanto esta.

EDIT: esclarecimentos sobre os comentários (@amon, para ser mais preciso). Esta seção da resposta não trata da questão da herança. A comparação do uso da memória é feita com uma Lista vinculada única e com o melhor uso da memória (em implementações reais, o fator pode mudar um pouco, mas ainda é suficientemente grande para resumir um pouco de memória desperdiçada).

Em relação às "más práticas":

Definitivamente. Esta não é a maneira padrão de implementar um gráfico por um motivo simples: um nó de gráfico possui nós filhos, não é como uma lista de nós filhos. Expressar com precisão o que você quer dizer com código é uma habilidade importante. Seja em nomes de variáveis ​​ou estruturas de expressão como esta. Próximo ponto: mantendo as interfaces mínimas: você disponibilizou todos os métodos ArrayListpara o usuário da classe por herança. Não há como alterar isso sem quebrar toda a estrutura do código. Em vez disso, armazene a Listvariável como interna e disponibilize os métodos necessários por meio de um método de adaptador. Dessa forma, você pode facilmente adicionar e remover funcionalidades da classe sem estragar tudo.

Parece que parece a semântica do padrão composto . É usado para modelar estruturas de dados recursivas.