How would you design a tree / control hierarchy without inheritance?
I know the answers to Prefer Composition over Inheritance and I know the merits of Composition over Inheritance.
But there are times when inheritance really plays a role. It is the misuse of the inheritance hierarchy that causes all the reuse issues.
Let's take an example of the following controls ...
Button/Textbox/Combobox/ListBox/Grid etc.
They are usually implemented as
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
{
....
}
NOTE. Both the user interface and the function are reusable.
Perhaps I am wrong or partially correct. Your thoughts would only help me improve my understanding of this topic.
How would you like to design a control model / hierarchy without using inheritance, and which one do you think is best?
Consider ease of use, use the IDE for this control.
PS: This question is also inspired by this question .
source to share
The preferred composition does not match the mandate in every situation. To add to your UI example, I would say that both Java and .NET benefit from using an inheritance hierarchy for threads.
I suggest you take a look at the inheritance tree for Windows Presentation Foundation, although it is a relatively modern set of user interface tools for composition. This allows you to create weird and wonderful things - like buttons containing extra buttons, etc. Sometimes (as in this example) it is useless, but the overall design is powerful.
I'm not saying I'm perfect - and I can't claim to know a lot about WPF, but this is an interesting starting point.
I should point out that even WPF uses inheritance extensively - but not quite in the same way as (say) WinForms.
source to share
You would use a series of delegates for functionality that is traditionally found in the parent class. Let's say the Control class contains basic painting functions (such as paint ()). Well control will become BasicControlDelegate or similar, and "subclasses" will be created with reference to BasicControlDelegate, which will be used for all "legacy" functionality.
If you want to use the parent / delegate as-is functionality, you create a paint () method in each "subclass" that simply calls the same method on the delegate. If you want to change the functionality, you create a different implementation.
The TextBoxBase may have a paint () implementation that is used directly by the TextBox, but perhaps the NumericTextBox has its own paint () implementation.
I think the main ones are the following:
- Inheritance is like a composition with an implicit reference to the "parent object" (of course, there is only one real object).
- With inheritance, you inherit and publish each default public method and can override it if you want.
- With composition, you don't show anything by default and have to wrap every method you want to expose.
source to share