timochka> Рома, объем кода давно никого не пугает, пугает сложность. Т.е. много простого кода лучше чем мало сложного.
Меня пугает. Если мне для реализации класса, который в ином случае реализуется в 10 строк, придётся писать 100 строк, то на весь проект вместо месяца работы мне понадобится год. А та же Авиабаза в нынешнем варианте потребовала бы уже не 10 лет экспериментов, а 100 лет
Как раз объём кода (утрированно, естественно) - это то, за чем упорно гонится весь программистский мир за последние лет 30
Каждое повышение уровня языка заключается в том, чтобы как можно меньшими усилиями реализовать как можно больший функционал. Одно из важных требований для осуществления этой задачи - как раз повышение функциональной насыщенности кода.
В противном случае до сих пор бы все программировали в машинных кодах
timochka> Ты смотришь на проблему с позиции разрабочика-одиночки. Сейчас развитие идет в сторону групповой разработки.
Видишь ли, я как раз уже нарывался несколько на эти проблемы именно в групповой разработке на Java
Когда вместо простого и наглядного решения через множественное наследование приходилось добавлять никому непонятные костыли.
timochka> 1) Для влезания в середину существующего кода желательно изучать как можно меньше. Т.е. разлишные модули должны быть слабо связанны.
Множественное наследование этому никак не мешает.
timochka> 2) Для того что-бы переиспользовать существующую реализацию нельзя требовать изучения толстого унаследованного API (крайне желательно перечислить большинство методов объекта прямо в классе реализации).
Опять же, со множественным наследованием это никак не связано. Ну выдаст тебе компилятор ошибку одноимённых методов, ну избавишься ты от их использования или прямо укажешь родителя.
Ведь точно такая же проблема вылезает, скажем, в той же Java при импорте. Совершенно разные классы разных пакетов могут иметь одно имя и может вылезать конфликт имён при массовом испорте сторонних пакетов. Компилятор в этом случае просто ругается и программист уточняет, чей конкретно класс он имел в виду.
Почему для имён классов такой подход допустим, а для имён методов в случае множественного наследования - нет?
timochka> 3) У множественного наследования есть еще проблема с многократным наследованием реализации (и данных) одного базового класса от нескольких родителей
Не понял проблемы. Если у кого-то из родителей в цепочке метод переопределён - это будет
другой метод с тем же именем и компилятор прекрасно отловит неоднозначность.
timochka> В большом коллективе 80% работы это задачи типа есть неправильное поведение в таком-то случае.
Компилятор способен в 100% случаев отловить проблемы множественного раследования. Как он отлавливает те же проблемы со "множественным импортом".
Поэтому неожиданного поведения тут просто не может быть. Или программа не соберётся, или соберётся, но с явным знанием компилятора о том, какой метод вызывался.
timochka> Поэтому считают что лучше явно прописать все методы в классе при агрегации, чем полагаться на унаследованную реализацию.
При пропагандируемом сейчас принципе максимального рефакторинга получается полнейший бред. Приходится писать в 10 раз больше кода, при этом в 10 раз возрастает риск пропустить ошибку. Ежу понятно, что любой типичный программист начинает делать копипаст. И вместо:
code cpp
int modify_time() { return parent2->modify_time(); }
int create_time() { return parent2->create_time(); }
мы получим:
code cpp
int modify_time() { return parent2->modify_time(); }
int create_time() { return parent2->modify_time(); }
И ошибку такого рода отлавливать будем
очень долго. Я сам на эти грабли (в немного более сложных случаях, естественно, но таких же по принципу) наступал несколько раз.
В результате на одной чаще весов - сильное замедление разработки, забивание головы программиста не самой задачей, а рутинной операцией, увеличение вероятности ошибок, а с другой... ничего! Потому что любые неоднозначности способен отловить компилятор на этапе компиляции!