Добрый день,
я все-таки никак не пойму почему у "профессиональных" разработчиков ПО часто прослеживается паранойя наследования — надо что-то заимплементить, мы пронаследуемся и еще раз и еще.... Может стоит остановиться и подумать над дизайном??? Ведь неоправданное наследование это тупиковый вариант, для последующего внесения изменений, они нарастают как снежный ком...

Здравствуйте, antonlavreev, Вы писали:

A>Добрый день,
A> я все-таки никак не пойму почему у "профессиональных" разработчиков ПО часто прослеживается паранойя наследования — надо что-то заимплементить, мы пронаследуемся и еще раз и еще.... Может стоит остановиться и подумать над дизайном??? Ведь неоправданное наследование это тупиковый вариант, для последующего внесения изменений, они нарастают как снежный ком...
Кажется, "паранойя наследования" как раз у автора поста а не наоборот

Здравствуйте, Zigmar, Вы писали:

Z>Здравствуйте, antonlavreev, Вы писали:

A>>Добрый день,
A>> я все-таки никак не пойму почему у "профессиональных" разработчиков ПО часто прослеживается паранойя наследования — надо что-то заимплементить, мы пронаследуемся и еще раз и еще.... Может стоит остановиться и подумать над дизайном??? Ведь неоправданное наследование это тупиковый вариант, для последующего внесения изменений, они нарастают как снежный ком...
Z>Кажется, "паранойя наследования" как раз у автора поста а не наоборот

Да у меня как раз нет просто во многих случаях я не понимаю зачем городить огород с наследованием, если можно использовать например, decorator или моделирование на основе стратегий и т.д.

Здравствуйте, Zigmar, Вы писали:

Z>Кажется, "паранойя наследования" как раз у автора поста а не наоборот

нет, это "инХЕРофобия" — боязнь наследования..

Здравствуйте, antonlavreev, Вы писали:

A> я все-таки никак не пойму почему у "профессиональных" разработчиков ПО часто прослеживается паранойя наследования — надо что-то заимплементить, мы пронаследуемся и еще раз и еще.... Может стоит остановиться и подумать над дизайном??? Ведь неоправданное наследование это тупиковый вариант, для последующего внесения изменений, они нарастают как снежный ком...

Это ты про Возможно ли вызвать оператор = класса предка в его потомке

Автор: Melamed
Дата: 09.04.08

?
Да, я бы тоже задумался — зачем это наследоваться от вектора...

A> я все-таки никак не пойму почему у "профессиональных" разработчиков ПО часто прослеживается паранойя наследования — надо что-то заимплементить, мы пронаследуемся и еще раз и еще.... Может стоит остановиться и подумать над дизайном??? Ведь неоправданное наследование это тупиковый вариант, для последующего внесения изменений, они нарастают как снежный ком...
Да нет ниче тупикового при грамотном использовании. Хотя конечно имеются проблемы у людей испорченных общением с делфи.

Здравствуйте, antonlavreev, Вы писали:

A>Да у меня как раз нет просто во многих случаях я не понимаю зачем городить огород с наследованием, если можно использовать например, decorator или моделирование на основе стратегий и т.д.

У меня уже длительное время происходит накопление паранойи стратегий и чувствую, скоро она случится

    class СChudoStrategnyiClass
        : public strats::armer<СChudoStrategnyiClass, bmpl::vector<
            strats::control_handleEventsStatic
            ,strats::control_data4UpdateCookieOnce
            ,strats::method
            ,strats::processor_static
            ,strats::methodInitializer_holder
            ,strats::singletonSeparator_fld
        > >::type
    {
    public:
        ...

Здравствуйте, antonlavreev, Вы писали:

A>Добрый день,
A> я все-таки никак не пойму почему у "профессиональных" разработчиков ПО часто прослеживается паранойя наследования — надо что-то заимплементить, мы пронаследуемся и еще раз и еще.... Может стоит остановиться и подумать над дизайном??? Ведь неоправданное наследование это тупиковый вариант, для последующего внесения изменений, они нарастают как снежный ком...

А можно как-то более конкретно пояснить, о каких "профессиональных" разработчиках идет речь и привести примеры случаях неуместного наследования, сделанного ими? В моем представлении если разработчик применяет наследодование без рабору, где нужно и где не нужно, то профессиональным его назвать никак нельзя.

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, antonlavreev, Вы писали:

A>>Добрый день,
A>> я все-таки никак не пойму почему у "профессиональных" разработчиков ПО часто прослеживается паранойя наследования — надо что-то заимплементить, мы пронаследуемся и еще раз и еще.... Может стоит остановиться и подумать над дизайном??? Ведь неоправданное наследование это тупиковый вариант, для последующего внесения изменений, они нарастают как снежный ком...

R>А можно как-то более конкретно пояснить, о каких "профессиональных" разработчиках идет речь и привести примеры случаях неуместного наследования, сделанного ими? В моем представлении если разработчик применяет наследодование без рабору, где нужно и где не нужно, то профессиональным его назвать никак нельзя.

К примеру, есть некий класс B, который хранит некие идентификаторы — контейнер с числами. Далее требуется сделать так, чтобы он хранил контейнер с идентификаторами + каждому идентификатору ставился в соответствие еще один атрибут At. Происходит наследование от B. Далее другой атрибут At2 — еще раз наследование от B. Уже выглядит странновато. А затем выясняется, что нужен такой объект у которого был бы и идентификатор, и At, и At2... И лучше бы обойтись без виртуального наследования...Т.е. на каждый дополнительный атрибут(ы) будут создаваться классы-наследники...

Здравствуйте, antonlavreev, Вы писали:

A>Добрый день,
A> я все-таки никак не пойму почему у "профессиональных" разработчиков ПО часто прослеживается паранойя наследования — надо что-то заимплементить, мы пронаследуемся и еще раз и еще.... Может стоит остановиться и подумать над дизайном??? Ведь неоправданное наследование это тупиковый вариант, для последующего внесения изменений, они нарастают как снежный ком...

ты параною с манией не путаешь случайно?

You will always get what you always got
  If you always do  what you always did

A>> я все-таки никак не пойму почему у "профессиональных" разработчиков ПО часто прослеживается паранойя наследования

J>ты параною с манией не путаешь случайно?

Путает, вне всякого сомнения. "Паранойя чего-либо" -- так по-русски вообще не говорят.

Здравствуйте, antonlavreev, Вы писали:

A>К примеру, есть некий класс B, который хранит некие идентификаторы — контейнер с числами. Далее требуется сделать так, чтобы он хранил контейнер с идентификаторами + каждому идентификатору ставился в соответствие еще один атрибут At. Происходит наследование от B. Далее другой атрибут At2 — еще раз наследование от B. Уже выглядит странновато. А затем выясняется, что нужен такой объект у которого был бы и идентификатор, и At, и At2... И лучше бы обойтись без виртуального наследования...Т.е. на каждый дополнительный атрибут(ы) будут создаваться классы-наследники...

имхо наследование нужно, когда нужно добавить/изменить поведение объекта, а не хранимые данные..
если только данные, то рефакторинг в сторону большей гибкости..

Здравствуйте, antonlavreev, Вы писали:

A> я все-таки никак не пойму почему у "профессиональных" разработчиков ПО часто прослеживается паранойя наследования — надо что-то заимплементить, мы пронаследуемся и еще раз и еще.... Может стоит остановиться и подумать над дизайном??? Ведь неоправданное наследование это тупиковый вариант, для последующего внесения изменений, они нарастают как снежный ком...

ИМХО, всё дело в виде наследования: нельзя забывать, что в С++ _по умолчанию_ предлагается private-наследование, в котором ничего плохого нет: при желании заменить его на агрегирование или на что-то другое или выкинуть вовсе будет не так сложно. Проблемы есть с "видимым наружу" наследованием, которое надо обдумывать весьма и весьма тщательно.

Как говорили некогда гиганты мысли: "наследование (от себя добавлю, что речь, бузусловно, шла не о закрытом наследовании) — сильнейшая связь между объектами, разорвать которую сложнее всего". Вот поэтому избегать его, при возможности, необходимо.

Здравствуйте, antonlavreev, Вы писали:

A>Да у меня как раз нет просто во многих случаях я не понимаю зачем городить огород с наследованием, если можно использовать например, decorator или моделирование на основе стратегий и т.д.
Предложите программистам почитать, к примеру, GoF-ов. Наследованию стоит предпочитать композицию объектов.

1. Наследование
   Плюсы:
   • статически детерминировано;
   • проще в использовании, так как вшито в ООЯ.
   Минусы:
   • статическая определенность кроме того и минус: нельзя изменить реализацию во время исполнения;
   • наследование нарушает инкапсуляцию, так как наследник имеет доступ к членам класса родителя, как следствие, в наследниках возникают, к примеру, проблемы безопасности инициализации при потере указателя this, вызов виртуальных методов, потоков и т.п. из конструктора и прочее;
   • наследование настолько тесно связывает классы, что изменение в родителе вызывает или волну изменений в наследниках, или волну ошибок в оных.
2. Композиция
   Плюсы
   • определяется динамически за счет перекрестных ссылок (не связаны руки компилятором, во время исполнения любой объект может быть подменен другим соответствующего типа);
   • применяется на основе взаимного соблюдения классами контрактов друг друга, предпочтительно основанных на интерфейсах, то есть не нарушается принцип инкапсуляции;
   • не помню, писали об этом GoF-ы или нет: такие структуры объектов проще понимать, чем сложные графы наследования, ведь композиция приводит к более простым графам наследования, принуждает постепенно писать ориентируясь на шаблоны проектирования, в первую же очередь на основной принцип — одной ответственности класса.
   Минусы:
   • на ум приходит только высокий порог вхождения, то есть необходимость в некотором минимальном опыте разработки, чтобы понять, чем композиция лучше наследования; соответственно минус в том, что новичкам сложно понимать "композиционный код".

Многие задачи, решаемые наследованием, могут быть решены, как вы и сказали выше, на основе делегирования (а это и есть один из вариантов композиции). Кроме того, часто от наследования можно уйти за счет обобщенного программирования.

Здравствуйте, neFormal, Вы писали:

F>имхо наследование нужно, когда нужно добавить/изменить поведение объекта, а не хранимые данные..

Вот насчет "изменить", имхо, таки нет.

---
С уважением, Сиваков Константин.

Здравствуйте, rsn81, Вы писали:

>Многие задачи, решаемые наследованием, могут быть решены, как вы и сказали выше, на основе делегирования (а это и есть один из вариантов композиции). Кроме того, часто от наследования можно уйти за счет обобщенного программирования.

+1. Только старые компиляторы не позволяют иногда, а иногда и наоборот бывает приходится эмулировать наследованием отсутствие частичных специализаций.

Извиняюсь за оффтоп — накипело от общения с VC 6.

Здравствуйте, rg45, Вы писали:

R>А можно как-то более конкретно пояснить, о каких "профессиональных" разработчиках идет речь и привести примеры случаях неуместного наследования, сделанного ими? В моем представлении если разработчик применяет наследодование без рабору, где нужно и где не нужно, то профессиональным его назвать никак нельзя.

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

Здравствуйте, rg45, Вы писали:

R>А можно как-то более конкретно пояснить, о каких "профессиональных" разработчиках идет речь и привести примеры случаях неуместного наследования, сделанного ими? В моем представлении если разработчик применяет наследодование без рабору, где нужно и где не нужно, то профессиональным его назвать никак нельзя.

Классический пример в мире Java — класс Stack (или Queue, точно уж не помню) реализованный через наследование от класса Vector. Бага допущена очень давно, сейчас применяются совсем другие решения — но как пример сойдет.

Здравствуйте, antonlavreev, Вы писали:

A>Добрый день,
A> я все-таки никак не пойму почему у "профессиональных" разработчиков ПО часто прослеживается паранойя наследования — надо что-то заимплементить, мы пронаследуемся и еще раз и еще.... Может стоит остановиться и подумать над дизайном??? Ведь неоправданное наследование это тупиковый вариант, для последующего внесения изменений, они нарастают как снежный ком...


Встает вопрос, а нужно ли использовать наследование вообще?
Отношение "интерфейс-реализация" — согласен, нужно и необходимо на уровне языка программирования.
А вот моделировать отношение "широкое понятие — узкое понятие" теми способами, которые предлагают C++/Java (наследование) — куча смутных сомнений.
Как считает цивилизованная общественность, идея полного отказа от наследования в пользу делегирования — имеет ли право на существование?

Здравствуйте, antonlavreev, Вы писали:

A>Добрый день,
A> я все-таки никак не пойму почему у "профессиональных" разработчиков ПО часто прослеживается паранойя наследования — надо что-то заимплементить, мы пронаследуемся и еще раз и еще.... Может стоит остановиться и подумать над дизайном??? Ведь неоправданное наследование это тупиковый вариант, для последующего внесения изменений, они нарастают как снежный ком...

Да, иной раз смотришь на то, что понаписали джуниоры, и понимаешь, что порой наследование — это как копипаст, но без копипаста