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

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

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

T>> ортогональные алгоритмы и контейнеры
V>По подробнее, я не знаю таких терминов.

bool hard_predicate(const CNode& left, const CNode& right);
std::vector<CNode> nodelist;
CNode searchFor;
std::vector<CNode>::iterator pnode

pnode = std::find(nodelist.begin(),    
                  nodelist.end(),   
                  searchFor,    
                  hard_predicate);

Некую слабую тень этих возможностей даёт Common Collections API, но это же слёзы. Ковариантные массивы в Java или C# требуют приведения всего к какому-нибудь LCA вида Object или Collection, на чём ортогональность и заканчивается, всё что не Object или Collection идёт лесом.

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

Просто: наследование в стандартной библиотеке C++ не комильфо, так что в качестве примера с наследованием vector, list и прочее в лекциях по C++ не подходят совершенно. Возможно в курсе по Java это действительно был бы хороший пример.

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


T>Все книги по C++ которые объясняют наследование вызывают желание убить себе лицо рукой. Вызывали когда я был на втором курсе, вызывают сейчас много лет спустя. Даже дедушка Строструп не уберёгся и унаследовал класс Manger от класса Employer, стыд и унижение. Варианты наследовать котят от собачек, груши от фруктов, кружочки от квадратиков и т.п. не рассматриваются, мне будет стыдно рассказывать, им будет стыдно слушать. Когда я совсем состарюсь пойду воспитателем в детский сад, там мне это очень пригодится, а пока ну нафиг.

T>Нахожусь в активном поиске нормального вменяемого примера наследования. Пока что придумал такую идею -- наследовать от "графа вообще" его частные случаи -- CFG, DAG, дерево. Близко к моей основной теме (оптимизирующие компиляторы), можно что-то рассказать дополнительно.

О господи!

Студенты не знают еще толком С++ (так я понял). Они еще не очень ориентируются в синтаксисе и в простейших приемах. А им предлагается взять в качестве основы граф (не самую простую структуру, вообще-то), сделать от него наследником дерево (которое совсем не обязательно реализовать как граф), рассказать что-то про оптимизирующие компиляторы , которые , видите ли, являются основной любовью лектора, и поэтому их надо сюда обязательно приплести. Тихий ужас.

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

Освоят основные идеи — тогда, пожалуйста, переходите хоть к графам, хоть к деревьям и т.п.

T>Но хотелось бы послушать мнение народа. Как бы вы объясняли наследование?

На примере какой нибудь GUI библиотеки.

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

PD>Собачек от кошечек наследовать не надо. А вот груши от фруктов или прямоугольники от абстрактной фигуры — это и есть самое простое решение. На этом примере можно показать основные принципы и идеи. А при показе основных принципов нужно использовать как можно более простой пример, дабы не затемнять эти принципы вопросами, не имеющими к ним прямого отношения.

Студент должен иметь возможность сесть и написать программу с этим самым простым примером, чтобы убедиться в его полезности. Эта программа должна решать осмысленную и нетривиальную задачу. Какую программу он может написать про груши и фрукты? Тут ещё рядом предлагали наследовать мяу от пуррр, или наоборот, я не вникал.

Написать граф и, скажем, DFS а потом унаследовать дерево и показать что на нём DFS тоже работает это не особо сложно, всё же не в ПТУ занимаемся. Ну посидеть вечерок, но оно того стоит. Я на первом курсе писал нечто подобное влёт, а у меня сейчас лекции для второго курса и на первом курсе им уже читали C и они уже что-то писали.

Пока что мне очень нравится совет от Miroff

Автор: Miroff
Дата: 29.10.14

в этой ветке. Сесть и написать эмулятор с простыми материальными точками — телами — планетами, студент вполне может.

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

UA>На примере какой нибудь GUI библиотеки.

Возможно имеет смысл -- отнаследовать кнопку с прогрессбаром от просто кнопки... должно быть увлекательно и для студентов наглядно. Но тут меня останавливает вопрос какую библиотеку взять за пример няшного ООП? Я в жизни использовал три GUI-библиотеки, ещё когда что-то кодил под винду. Это VCL, MFC и WTL. Все три с точки зрения правильного плюсового ООП -- ад из костылей, тяжелых наркотиков и легаси-кода. К моему великому счастью, последние четыре года я к GUI не прикасался. Я слышал, в QT всё несколько получше, но никогда не смотрел внимательней.

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

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

T>>> ортогональные алгоритмы и контейнеры
V>>По подробнее, я не знаю таких терминов.

T>

T>bool hard_predicate(const CNode& left, const CNode& right);
T>std::vector<CNode> nodelist;
T>CNode searchFor;
T>std::vector<CNode>::iterator pnode

T>pnode = std::find(nodelist.begin(),    
T>                  nodelist.end(),   
T>                  searchFor,    
T>                  hard_predicate);
T>

О чем вообще код?

T>Некую слабую тень этих возможностей даёт Common Collections API, но это же слёзы. Ковариантные массивы в Java или C# требуют приведения всего к какому-нибудь LCA вида Object или Collection, на чём ортогональность и заканчивается, всё что не Object или Collection идёт лесом.

А где такому языку учат? ортогональность? В Java любой объект наследуется от Object.

Ну естествено коллекции должны реализовывать интерфейст Collection — это особенность языка. Тут нет настоящих C++ шаблонов.

T>В любом случае всё это слабоконструктивный оффтоп. Я не ставил целью диспут с джавистами за "у кого лохмаче" -- интернет полон таких диспутов, аргументы сторон, в общем, ясны. Лохмаче у малболга.

Скорее всего шизофазия.

T>Просто: наследование в стандартной библиотеке C++ не комильфо, так что в качестве примера с наследованием vector, list и прочее в лекциях по C++ не подходят совершенно. Возможно в курсе по Java это действительно был бы хороший пример.

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

T>Студент должен иметь возможность сесть и написать программу с этим самым простым примером, чтобы убедиться в его полезности.

Несомненно.

>Эта программа должна решать осмысленную

Разумеется

>и нетривиальную задачу.

А вот с этим решительно не согласен. При изучении некоего нового понятия надо дать как можно более простую и тривиальную задачу, потому что целью является (пока что) изучение этого понятия и его реализации. А вот когда они понятие усвоят и с техникой разберутся — вот тогда можно найти и нетривиальную задачу , пусть делают.

В общем, простое правило обучения — от простого к сложному. А не наоборот.


>Какую программу он может написать про груши и фрукты? Тут ещё рядом предлагали наследовать мяу от пуррр, или наоборот, я не вникал.

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

T>Написать граф и, скажем, DFS а потом унаследовать дерево и показать что на нём DFS тоже работает это не особо сложно, всё же не в ПТУ занимаемся. Ну посидеть вечерок, но оно того стоит. Я на первом курсе писал нечто подобное влёт, а у меня сейчас лекции для второго курса и на первом курсе им уже читали C и они уже что-то писали.

T>Пока что мне очень нравится совет от Miroff

Автор: Miroff
Дата: 29.10.14

в этой ветке. Сесть и написать эмулятор с простыми материальными точками — телами — планетами, студент вполне может.

Пойдет. То же самое, только в 3D. Расчеты траекторий едва ли нужны (пользы от этого немного, не астрономов готовим), а сама иерархия вполне годится. Кстати, одно из упражнений, которое я даю — именно такое, только у меня есть продолжение иерархии : планеты с атмосферой, планеты с жизнью.

Кстати, и Мяу ничем не хуже. Почему иерархия небесных тел годится, а животных нет ?

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

T>>Но хотелось бы послушать мнение народа. Как бы вы объясняли наследование?

UA>На примере какой нибудь GUI библиотеки.
Начинающему очень рано в это влезать.
Тем более, что "GUI библиотеки" обычно переполнены тонкостями конкретной технической реализации. Что снижает их ценность в данном случае.

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

T>мне будет стыдно рассказывать, им будет стыдно слушать. Когда я совсем состарюсь пойду воспитателем в детский сад, там мне это очень пригодится, а пока ну нафиг.

тебе нельзя преподавать.

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

F>тебе нельзя преподавать.

Неизбежный оверхед задавания вопросов на любом русскоязычном форуме: тебе помимо всего прочего рассказывают о том кто ты и зачем нужен. Я всё ждал -- кто же, кто же.

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

F>>тебе нельзя преподавать.
T>Неизбежный оверхед задавания вопросов на любом русскоязычном форуме: тебе помимо всего прочего рассказывают о том кто ты и зачем нужен. Я всё ждал -- кто же, кто же.

это уже твои домыслы. впрочем, ожидаемые.

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

PD>Кстати, и Мяу ничем не хуже. Почему иерархия небесных тел годится, а животных нет ?

потому что это сюси-пуси для девочек.
в смысле, комплексы.

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

F>потому что это сюси-пуси для девочек.
F>в смысле, комплексы.

Комплексы у того, кто так считает ? Его проблемы.

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

>>и нетривиальную задачу.

PD>А вот с этим решительно не согласен. При изучении некоего нового понятия надо дать как можно более простую и тривиальную задачу, потому что целью является (пока что) изучение этого понятия и его реализации. А вот когда они понятие усвоят и с техникой разберутся — вот тогда можно найти и нетривиальную задачу , пусть делают.

Нетривиальная задача в моём понимании это не что-то такое, что сложно запрограммировать, а что-то, что нужно запрограммировать, поскольку это неоправданно долго делается без привлечения ЭВМ и т.п.

PD> скажем, для набора классов , наследуемых от абстрактной 2D-фигуры, можно сдеать полиморфный список из этих фигур и на его примере показать очень не мало (конструкторы, деструкторы, полиморфизм, время жизни, клонирование и т.д.)

Что конкретно делать с этим списком? Пример должен иметь осмысленную постановку и осмысленное применение. "Перемножить матрицы и найти определитель" -- бессмысленная задача. "Подсчитать токи в заданной цепи" -- осмысленная задача.

PD>Кстати, и Мяу ничем не хуже. Почему иерархия небесных тел годится, а животных нет ?

Иерархия небесных тел позволяет прикинуть решение задачи трёх тел, вывести в файл их траектории, посмотреть их с помощью gnuplot. Что делать с иерархией животных?

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

V>Ну естествено коллекции должны реализовывать интерфейст Collection — это особенность языка.
V>Тут нет настоящих C++ шаблонов.

Именно так.

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

T>Но весь этот план требует некоего сквозного примера для которого проводить объяснения. И вот тут у меня затык.

Вы не знаете, для чего нужно наследование, а беретесь объяснять другим. Поэтому я всегда считал, что препод должен быть ветераном промышленности.

Если я не прав, откройте свой код и возьмите оттуда столько примеров, сколько надо.

***

Оффтопик. Главное, что я бы про наследование рассказал — есть места, где оно нужно, поскольку облегчает чтение, а есть места, куда его втыкают либо по глупости, либо из-за ограниченности языка. Пример первого — любая оконная библиотека. Пример второго — boost::operators. Обожаю на диаграмме наблюдать [boost::operators] -> [FileInfo] только потому, что кто-то коллекцию FileInfo решил отсортировать. Не надо так делать. Презренные макросы и то лучше.

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

T>Именно так.

И какое оно отношение имеет к наследованию?

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

T>Нетривиальная задача в моём понимании это не что-то такое, что сложно запрограммировать, а что-то, что нужно запрограммировать, поскольку это неоправданно долго делается без привлечения ЭВМ и т.п.

Это замечательно, но какое отношение это имеет к ООП ?

T>Что конкретно делать с этим списком? Пример должен иметь осмысленную постановку и осмысленное применение. "Перемножить матрицы и найти определитель" -- бессмысленная задача. "Подсчитать токи в заданной цепи" -- осмысленная задача.

Демонстрировать приемы и понятия ООП. При изучении ООП надо именно это делать, не затемняя эту тему чем бы то ни было посторонним.

Если конкретно — показать, как работает виртуальная , скажем, print, почему происходит memory leak при невиртуальном деструкторе, и т.д.

T>Иерархия небесных тел позволяет прикинуть решение задачи трёх тел, вывести в файл их траектории, посмотреть их с помощью gnuplot. Что делать с иерархией животных?

Ради всего святого, объясни, какое отношение задача трех тел имеет к ООП ? Почему учить ООП надо на примере задачи трех тел — не понимаю. Ее на Фортране можно написать, где ООП и в помине не было. И ничем не хуже будет рассчитана траектория.

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

F>>потому что это сюси-пуси для девочек.
F>>в смысле, комплексы.
PD>Комплексы у того, кто так считает ? Его проблемы.

нет, теперь это проблемы студентов.