Comment concevez-vous l'arbre/hiérarchie de contrôle sans héritage?

Question

Je suis au courant des réponses à Prefer composition over inheritance et suis au courant des mérites de la composition sur l'héritage.

Mais il y a des cas où l'héritage a un bon rôle à jouer. C'est l'utilisation incorrecte de la hiérarchie d'héritage qui provoque tous les problèmes liés à la réutilisation.

Prenons l'exemple des contrôles suivants ...

Button/Textbox/Combobox/ListBox/Grid etc. 

Généralement, ils sont mis en œuvre comme

public class Control 
{ 
    ... 
} 


public abstract class TextBoxBase : control 
{ 
    .... 
} 

public class TextBox : TextBoxBase 
{ 
    .... 
} 

public abstract class ButtonBase: control 
{ 
    .... 
} 

public class Button: ButtonBase 
{ 
    .... 
} 


public class TextBox : TextBoxBase 
{ 
    .... 
} 


public class NumericTextBox: TextBox 
{ 
    .... 
} 

REMARQUE: Les deux l'interface utilisateur et le functionlity est réutilisable.

Je peux me tromper ou partiellement corriger. Vos pensées m'aideraient seulement à améliorer ma compréhension de ce sujet.

Comment allez-vous concevoir le modèle/la hiérarchie de contrôle sans utiliser l'héritage, et lequel pensez-vous être le meilleur?

Veuillez tenir compte de la facilité d'utilisation, de l'utilisation de l'IDE pour ce contrôle. Cette question est également inspirée par this question. Lorsque toutes les tâches sont dans les mêmes rôles, l'héritage est meilleur.

Answer 1

Préférer la composition n'est pas la même chose que de le faire dans toutes les situations. Pour ajouter à votre exemple d'interface utilisateur, je dirais que Java et .NET bénéficient d'une hiérarchie d'héritage pour les flux.

Je suggère que vous jetez un oeil à l'arbre d'héritage pour Windows Presentation Foundation - c'est une boîte à outils relativement moderne conçue pour la composition. Cela permet des choses étranges et merveilleuses - comme des boutons qui contiennent d'autres boutons, etc. Parfois (comme dans cet exemple), cela sera inutile - mais le design général est puissant. Je ne dis pas que je suis idéal - je ne prétends pas en savoir beaucoup sur WPF - mais c'est un point de départ intéressant.

Je dois souligner que même dans l'héritage WPF est largement utilisé - mais pas de la même manière que dans (par exemple) WinForms.

Answer 2

Answer 3

Vous utiliseriez une série de délégués pour les fonctionnalités qui sont traditionnellement dans la classe parente. Supposons que la classe Control contienne des fonctions de dessin de base (ie paint()) - bien Control deviendrait BasicControlDelegate ou similaire, et les "sous-classes" seraient créées avec une référence à BasicControlDelegate, qui serait utilisée pour toutes les fonctionnalités "héritées".

Si vous souhaitez utiliser la fonctionnalité parent/délégué telle quelle, créez une méthode paint() dans chaque "sous-classe" qui appelle simplement la même méthode sur le délégué. Si vous souhaitez modifier la fonctionnalité, vous créez une implémentation différente.

TextBoxBase peut avoir une implémentation paint(), utilisée directement par TextBox, mais peut-être que NumericTextBox possède sa propre implémentation paint().

Je pense que les principaux points sont les suivants:

• héritage est similaire à la composition avec une référence implicite au « objet parent » (il n'y a qu'un seul objet réel bien sûr).
• Avec l'héritage, vous héritez et exposez chaque méthode publique par défaut et pouvez la remplacer si vous le souhaitez.
• Avec la composition, vous n'exposez rien par défaut et vous devez envelopper chaque méthode que vous souhaitez exposer.