Возможно ли потерять в наследстве над наследством?
В настоящее время я работаю над сайтом 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, который будет перерабатывать язык, который вы используете.