Возможно ли потерять в наследстве над наследством?

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

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

Спасибо!

Ответ 1

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

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

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

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

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

Ответ 2

Существует несколько рекомендаций по разработке "предпочтительной композиции над наследованием" 8-10 уровней наследованиях.

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Итак, в резюме

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

Ответ 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 empty
 Public Class B : Inherits A
 End Class

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

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

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