Por que as estruturas Windows Forms / Swing favorecem a herança em vez da Composition?

Hoje, um professor meu comentou que achou estranho que, embora a filosofia da SWT seja a de fazer seus próprios controles por composição, Swing parece favorecer a herança.

Quase não tenho contato com ambas as estruturas, mas pelo que me lembro no Windows Forms do C # geralmente se estende controles, assim como o Swing.

Sendo que geralmente as pessoas tendem a preferir composição a herança, por que o pessoal do Swing / Windows Forms não prefere composição ao invés de herança?

JComponentexpõe muitas funcionalidades . Se JComponenthouvesse uma interface e componentes fossem implementados com composição, os componentes simples precisariam ter dezenas de invólucros de métodos triviais, por exemplo

class MyComponent implements JComponent {
    JPanel panel;
    public boolean contains(int x, int y) {
        return panel.contains(x, y);
    }
    ...
}

Há também um motivo de eficiência para preferir a herança à composição - substituir não custa nada (assumindo nenhuma superligação), enquanto a composição custa um extra INVOKEVIRTUAL. Não sei se isso influenciou o design do Swing, mas é uma grande preocupação para as classes de coleção.

O Swing Framework é realmente projetado de acordo com o Composite Design Pattern. Concedido que há muita herança lá, mas você normalmente compõe seus próprios formulários usando composição. Ou seja, um formulário é uma composição de contêineres e controles de nível intermediário.

Com Java, é muito mais fácil acabar usando herança apenas porque tudo é virtual. Precisa corrigir um "recurso" no JTable / JFrame? Estenda-o, substitua os métodos do problema e use a Tabela / Quadro em qualquer lugar.

Eu acho que com coisas como o WPF, em que a ligação de dados é um recurso principal do design, facilita muito a composição, em vez da herança.

No Java Efetivo , Item 17, Bloch menciona que uma classe projetada para herança "deve documentar seu uso próprio de métodos substituíveis". Uma característica disso é a frase nesta implementação . Você verá isso em aulas como JTablee JInternalFrame. É uma medida de herança por design no Swing.

A partir do C # 3.5, temos um conceito chamado de Métodos de extensão que permite o conceito de composição do que herança.

Nesse processo, implementamos uma funcionalidade estendida em uma classe existente apenas adicionando uma classe de extensão que renderiza o novo recurso à classe existente.

Você pode consultar aqui para mais detalhes