Perché i framework Windows Form / Swing preferiscono l'ereditarietà invece di Composizione?

Question

Perché i framework Windows Form / Swing preferiscono l'ereditarietà invece di Composizione?

#1 da (7 voti)
#2 da (2 voti)
#3 da (1 voti)
#4 da (1 voti)
#5 da (-2 voti)

12

Oggi un mio professore ha commentato che trovava strano che, mentre la filosofia di SWT fosse quella di creare i propri controlli per composizione, Swing sembra favorire l'ereditarietà.

Non ho quasi alcun contatto con entrambi i framework, ma da quello che ricordo nei Windows Form di C # uno di solito estende i controlli, proprio come Swing.

Dato che generalmente le persone tendono a preferire la composizione rispetto all'ereditarietà, perché la gente di Swing / Windows Form preferisce la composizione invece dell'ereditarietà?

c# java forms swing

posta devoured elysium 25.05.2011 - 23:27

fonte

5 risposte

Leggi altre domande sui tag c# java forms swing

Quali sono le differenze tra i prototipi usa e getta e quelli evolutivi? Come strutturare il sistema template usando PHP semplice?

score 7 · Answer 1

JComponent espone molte funzionalità . Se JComponent era un'interfaccia e i componenti sono stati implementati con la composizione, i componenti semplici avrebbero bisogno di avere dozzine di wrapper di metodi banali, ad es.

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

Esiste anche un motivo di efficienza per preferire l'ereditarietà rispetto alla composizione: nessun costo di override (supponendo che non sia chiamata super ), mentre la composizione costa un extra INVOKEVIRTUAL . Non so se questo abbia influenzato il design di Swing, ma è un grosso problema per le classi di raccolta.

score 2 · Answer 2

Lo Swing Framework è in realtà progettato in accordo con il Pattern di progettazione composito. Ammesso che ci sia molta eredità lì, ma di solito componi le tue forme usando la composizione. Cioè, una forma è una composizione di contenitori e controlli di livello intermedio.

score 1 · Answer 3

Con Java, il suo lotto è più facile da utilizzare utilizzando l'ereditarietà solo perché tutto è virtuale. Hai bisogno di riparare una "funzionalità" in JTable / JFrame? Estendilo, ignora i metodi del problema e poi usa la tua Table / Frame ovunque.

Penso che con elementi come WPF, in cui l'associazione dei dati è una caratteristica principale del progetto, rende molto più semplice la composizione anziché l'ereditarietà.

score 1 · Answer 4

In Java efficace , articolo 17, Bloch afferma che una classe progettata per ereditarietà "must" documenta l'auto-uso dei metodi sovrascrivibili. "Un tratto distintivo di questa è la frase questa implementazione . La vedrai in classi come JTable e JInternalFrame . È una misura dell'ereditarietà del design in Swing.

score -2 · Answer 5

Da C # 3.5, abbiamo un concetto chiamato come metodi di estensione che consente il concetto di composizione piuttosto che l'ereditarietà.

In questo processo, implementiamo una funzionalità estesa a una classe esistente semplicemente aggiungendo una classe di estensione che restituisce la nuova funzione alla classe esistente.

Puoi consultare qui per ulteriori dettagli