Как бы вы спроектировали управляющее дерево / иерархию без наследования?

Question

Мне известны ответы на Предпочитаю композицию наследованию и я знаю о достоинствах композиции перед наследованием.

Но бывают случаи, когда наследование играет хорошую роль. Это неправильное использование иерархии наследования, которая вызывает все проблемы, связанные с повторным использованием.

Возьмите пример следующих элементов управления ...

Button/Textbox/Combobox/ListBox/Grid etc.

Обычно они реализуются как

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
{
    ....
}

ПРИМЕЧАНИЕ. Пользовательский интерфейс и функциональность можно использовать повторно.

Я могу быть не прав или частично прав. Ваши мысли помогут мне лучше понять эту тему.

Как бы вы подошли к проектированию модели / иерархии управления без использования наследования, и какая из них, по вашему мнению, лучше?

Пожалуйста, примите во внимание простоту использования, использование IDE и для этого элемента управления.

P.S .: Этот вопрос также вдохновлен этим вопросом .

Answer 1

Предпочитать композицию - это не то же самое, что назначать ее в любой ситуации. Чтобы добавить к вашему примеру пользовательского интерфейса, я бы сказал, что и Java, и .NET выигрывают от использования иерархии наследования для потоков.

Я предлагаю вам взглянуть на дерево наследования для Windows Presentation Foundation - это относительно современный инструментарий пользовательского интерфейса, предназначенный для композиции. Это позволяет создавать странные и замечательные вещи - например, кнопки, которые содержат дополнительные кнопки и т. Д. Иногда (как в этом примере) это будет бесполезно - но общий дизайн мощный.

Я не говорю, что я идеален - и при этом я не буду утверждать, что знаю очень много о WPF - но это интересная отправная точка.

Следует отметить, что даже внутри WPF наследование широко используется, но не совсем так, как в (скажем) WinForms.

Answer 2

Вы бы использовали ряд делегатов для функциональности, которая традиционно находится в родительском классе. Скажем, класс Control содержит базовые функции рисования (например, paint ()) - скважина Control станет BasicControlDelegate или подобным, а «подклассы» будут созданы со ссылкой на BasicControlDelegate, который будет использоваться для всех «унаследованных» функций.

Если вы хотите использовать функцию родителя / делегата как есть, вы создаете метод paint () в каждом «подклассе», который просто вызывает один и тот же метод для делегата. Если вы хотите изменить функциональность, создайте другую реализацию.

TextBoxBase может иметь реализацию paint (), которая используется непосредственно TextBox, но, возможно, NumericTextBox имеет собственную реализацию paint ().

Я думаю, что основные моменты таковы:

• Наследование похоже на композицию с неявной ссылкой на «родительский объект» (конечно, существует только один реальный объект).
• С наследованием вы наследуете и выставляете каждый публичный метод по умолчанию и можете переопределить его, если хотите.
• С композицией вы ничего не выставляете по умолчанию, и вам нужно обернуть каждый метод, который вы хотите выставить.

Answer 3

, когда все задачи находятся в одинаковых ролях, наследственность лучше.