Можно ли потерять наследование в коде?

Question

В настоящее время я работаю над сайтом asp.net, созданным кем-то другим, и он слишком сложен для того, что делает ...... Ну, я так думаю! Практически каждый класс наследует от другого класса, затем от другого, другого и так далее ........ В среднем вам нужно пройти 8/10 уровней, чтобы получить базовый класс, иногда больше! И у этих классов есть другие классы внутри, которые следуют той же схеме Uber Inheritence. Это приводит к тому, что я теряюсь в коде много-много раз, в результате чего Бог знает, сколько вкладок открыто в visual studio.

Это хорошая / нормальная практика или плохая практика? Я чувствую, что это плохая практика, поскольку что-то настолько простое усложняется из-за чрезмерного использования наследования, что приводит к нерасширяемому коду ............... но я могу ошибаться:)

Спасибо!

Answer 1

Да, чрезмерное использование наследства может привести к складу спагетти.Наследование - это инструмент для инкапсуляции и абстракции.Злоупотребление этим вызывает слишком много абстракции, и тогда цель кода становится непригодной для использования.Я видел, как этот шаблон злоупотреблял и в императивных конструкциях, где метод передается от метода к методу до метода до фактического применения действия.

private bool getData()
{
    return getOtherData();
}

private bool getOtherData()
{
    return getSomeExtraData();
} 

private bool getSomeExtraData()
{
    return SeeHowTediousThisIs();
}

Все это работает, но это исключительно плохая архитектурадля поддержания.Я нахожу, что это часто происходит с консультантами / подрядчиками, пытающимися ввести сложность (re: безопасность работы).

Answer 2

Существует несколько рекомендаций по проектированию «композиция благосклонности по сравнению с наследованием» при нескольких нарушениях наследования.

http://en.wikipedia.org/wiki/Composition_over_inheritance

Answer 3

Наследование как средство многократного использования кода - действительно очень плохой выбор. Учтите, что каждый класс на языках .NET имеет единственный слот наследования, куда может идти код. Следовательно, для каждого класса следует выбирать мудро, наследовать ли он от чего-то другого или нет.

Обычно говорят, что наследование описывает отношение "is-a" , где, поднимаясь по цепочке наследования, мы достигаем более высоких уровней абстракции.

Первый вопрос всегда должен заключаться в том, не является ли отношение *1011* "can-act-as" недостаточным. В этом случае описание отношений через интерфейсы часто является лучшим выбором. Во-вторых, при добавлении абстракций вопрос должен заключаться в том, может ли немало кода работать с этими абстракциями, чтобы удовлетворить функции, которые вы ищете.

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

Итак, в итоге

• Отношения "можно действовать как" обычно достаточно - тогда вам не нужно идти на отношения "есть"
• Слот наследования драгоценен - ​​его можно использовать только один раз.
• Существует намного больше способов повторного использования кода, чем наследование от класса
• Базовые классы и интерфейсы являются абстракциями: убедитесь, что ваш код действительно может их использовать. Если ваш интерфейс реализован только одним классом, ваша абстракция может оказаться бесполезной и легко вводиться, когда это становится необходимым.
• Если существует необходимость в абстракции, штраф на интерфейсах ниже, чем на базовых классах.

Answer 4

Звучит как наследственное излишество, очень редко нужно выходить за рамки 2-3 уровней, и это было бы для сложной бизнес-модели.

Что это за классы?Органы управления?Бизнес Объекты?Документированы ли они (UML) где-нибудь, чтобы вы могли получить хороший обзор модели?

8-10 уровней - это много, я бы рискнул предположить, что эти классы были написаны до (или никогда) разработанного.

Answer 5

Скорее всего, я копался в аду наследства в последнее время.у нас буквально есть код, который выглядит следующим образом:

 Public Class A
   ' Do Stuff, methods, members, etc.
     Public var As Object

     Public Sub New()
         member = New Object
     End Sub
 End Class

 ' yes it's empty
 Public Class B : Inherits A
 End Class

 ' yes it's empty
 Public Class C : Inherits A
     Public Sub New()
         MyBase.New()
         member.SomeMethod()
     End Sub
 End Class

Тогда есть базовый класс, который содержит список объектов, которые ДОЛЖНЫ быть унаследованы для добавления объектов в этот список.

КорочеДа, наследство, безусловно, можно злоупотреблять, как и все.Самым полезным для меня было найти хороший инструмент для моделирования UML, который обратный инжиниринг языка, который вы используете.