избегать нового класса каждый раз, когда вы хотите ввести новую функциональность?

Question

избегать нового класса каждый раз, когда вы хотите ввести новую функциональность?

0

В огромном сложном приложении интересно, приемлемо ли вводить класс просто для реализации простой новой функциональности.

Например, класс C и D наследует от A (среди многих других классов, которые также наследуются от A).

Если мы хотим представить новые общие функции для C и D, мы можем:

1) ввести новый класс B (и реализовать в этом классе общую функциональность) между родительским классом A и двумя дочерними классами C и D, чтобы B наследовал от A, а C и D наследовал от B

2) добавьте функциональность в родительский класс A и добавьте флаг для использования этой функции только тогда, когда ребенок является типом B или C (и убедитесь, что таким образом мы не сломаем что-либо для остальных классов, которые наследуют от A )

(в delphi я думал, что этот флаг является опубликованным свойством, доступным в инспекторе объектов, что позволяет легко включать или исключать функциональность каждого из дочерних классов)

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

siwmas 10 март 2015, в 18:19

Источник

0

если это c ++, вы можете использовать множественное наследование, в этом случае C и D продолжают наследовать от A, но они также наследуют от B, но в этом случае B не должен наследовать от A, для меня это выглядит довольно аккуратно.
Marco 10 март 2015, в 17:05
1

Не злоупотребляйте наследованием. Спросите у себя , если B на самом деле является , и A C и D на самом деле являются B .
πάντα ῥεῖ 10 март 2015, в 17:05
2

№ 2 не так. Родительский класс вообще ничего не должен знать о классах-потомках, и добавление функциональности к родительскому классу и последующее его использование или нет в зависимости от класса дочернего элемента просто неправильно с точки зрения ООП.
Ken White 10 март 2015, в 17:09
0

Более того, в C ++ / Java / C # и Delphi вы можете использовать обобщения для определения класса, который использует фасеты / сервисы другого класса, указанного во время компиляции - весь STL основан на этом. Наследование не должно быть использовано для обеспечения общих функций, следует использовать только для модели is a иерархиями
Panagiotis Kanavos 10 март 2015, в 17:30
0

@Marco Multiinheritance полезен, когда вы хотите объединить функциональность двух существующих классов в один. Но я верю, что пользователь пытается добавить одну и ту же функциональность к двум существующим классам, не объединяя их в один. В этом случае вставка дополнительного класса в существующее изменение наследования является правильным решением.
SilverWarior 10 март 2015, в 17:44
0

Если вы используете Delphi и в противном случае выбрали бы множественное наследование в стиле C ++, другим вариантом было бы использовать интерфейсы и реализовывать их в классах C и D, предполагая, что интерфейсы хорошо подходят для всей архитектуры.
J... 10 март 2015, в 17:53
1

Вы рассматривали композицию, а не наследство?
David Heffernan 10 март 2015, в 18:17
0

Без лишних деталей я остаюсь ломать голову, размышляя о том, что не так с виртуальным методом в базовом классе, который может быть переопределен при необходимости. Это простой подход, который не требует ни нового класса, ни того, чтобы родительский класс ничего не знал о производных классах. Просто определите пустое тело для виртуального метода в базовом классе, затем переопределите его в любых дочерних классах, и все будет в порядке. Тем не менее, если вы действительно хотите иметь общую реализацию над классами C и D, вам нужно будет ввести класс между A и C / D. Виртуальный метод все еще полезен.
David Schwartz 10 март 2015, в 19:35

Показать ещё 6 комментариев

Теги:

c++

delphi

inheritance

1 ответ

Ещё вопросы

если это c ++, вы можете использовать множественное наследование, в этом случае C и D продолжают наследовать от A, но они также наследуют от B, но в этом случае B не должен наследовать от A, для меня это выглядит довольно аккуратно.
Не злоупотребляйте наследованием. Спросите у себя , если B на самом деле является , и A C и D на самом деле являются B .
№ 2 не так. Родительский класс вообще ничего не должен знать о классах-потомках, и добавление функциональности к родительскому классу и последующее его использование или нет в зависимости от класса дочернего элемента просто неправильно с точки зрения ООП.
Более того, в C ++ / Java / C # и Delphi вы можете использовать обобщения для определения класса, который использует фасеты / сервисы другого класса, указанного во время компиляции - весь STL основан на этом. Наследование не должно быть использовано для обеспечения общих функций, следует использовать только для модели is a иерархиями
@Marco Multiinheritance полезен, когда вы хотите объединить функциональность двух существующих классов в один. Но я верю, что пользователь пытается добавить одну и ту же функциональность к двум существующим классам, не объединяя их в один. В этом случае вставка дополнительного класса в существующее изменение наследования является правильным решением.
Если вы используете Delphi и в противном случае выбрали бы множественное наследование в стиле C ++, другим вариантом было бы использовать интерфейсы и реализовывать их в классах C и D, предполагая, что интерфейсы хорошо подходят для всей архитектуры.
Вы рассматривали композицию, а не наследство?
Без лишних деталей я остаюсь ломать голову, размышляя о том, что не так с виртуальным методом в базовом классе, который может быть переопределен при необходимости. Это простой подход, который не требует ни нового класса, ни того, чтобы родительский класс ничего не знал о производных классах. Просто определите пустое тело для виртуального метода в базовом классе, затем переопределите его в любых дочерних классах, и все будет в порядке. Тем не менее, если вы действительно хотите иметь общую реализацию над классами C и D, вам нужно будет ввести класс между A и C / D. Виртуальный метод все еще полезен.

Akash · Accepted Answer · 2015-03-10T15-09-00.000Z

Если вам нужна новая функциональность, лучше создать для этой цели новый класс. После этого становится легче изменить функциональность.
Как вы сказали, "другие классы также наследуются от класса А"; это может быть так, что этим классам не нужны функциональные возможности, которые вы добавляете в класс A. Таким образом, лучше создать отдельный класс.
Хотя во 2-м подходе вы создаете флаг, чтобы решить, использовать ли его функциональность или нет, я рассматриваю его как накладные расходы и может вызвать сложность.

Создание отдельного класса для отдельной функциональности всегда помогает. Вы можете легко разрабатывать, поддерживать, обновлять/модифицировать код; что красота объектно-ориентированного программирования. Итак, я бы предпочел вариант 1.