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

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

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

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

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 для этого элемента управления.

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

12.12.2008 17:38:08
Вы должны прочитать этот вопрос еще раз. ОП не сказал, что нет наследства, он сказал, нет базовых классов. Интерфейсы могут наследоваться от других интерфейсов. Таким образом, Button будет реализовывать IButton, который реализует IControl.
jmucchiello 12.12.2008 18:09:28
3 ОТВЕТА
РЕШЕНИЕ

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

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

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

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

2
12.12.2008 17:45:40
Джон Скит является идеальным, это идеализм , который несовершенен: P
Draemon 12.12.2008 17:50:16
Джон, я посмотрю на это. Спасибо за ваш вклад.
rajesh pillai 12.12.2008 17:56:36

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

0
12.12.2008 17:44:13

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

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

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

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

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