Pull to refresh

Comments 107

Я не программист, но очень бы хотелось глянуть на примеры работ)) Любопытно же, да и я думаю не одному мне)…
Да ребята в основном на листочках делали. :-) Но вот та девушка, делала вообще в ворд документе. :-) Я обязательно попрошу ее скинуть мне этот документик. И сразу опубликую. :-)
интересно :-)
а что за специальность — честно говоря, я удивлен, что только на втором курсе студенты знакомятся с ООП.
Специальность САПР. Да нет конечно, им еще на 1-м курсе о ООП говорили, но толку от этого мало. Но говорили именно про ООП, классы, наследование, полиморфизм и т.д., но объектного мышления и понимания им этого не прибавило.
а ) теперь понятно :-)
очень радует, что остались преподаватели, которые заинтересованы в том, чтобы студенты понимали необходимые основы.
говорю вам спасибо, так как сам являюсь студентом и понимаю, как это здорово, когда на курсе встречаются такие преподаватели :-)
Спасибо вам за теплые слова. :-)
Тут хорошо еще то, что преподаватель понимает, в каком виде дать эти основы и как дать возможность студентам дойти до этих основ самостоятельно. Это ведь не тривиальная для большинства задача — построить такой тренинг. К сожалению, большинство преподавателей очень хорошо знают и теорию и практику, но объяснять так, чтобы было понятно и интересно не могут.
Был бы очень рад, если бы автор поста преподавал у меня года четыре назад )
А так пришлось втыкать во все, уже когда устроился на работу и попал на крупный ООП проект, если можно так выразиться )
Это потому что им нафиг это не надо и пришли они учиться на программистов потому что мама_папа_знакомые/декан_друг_семьи/а как же в наше вреям без высшего?/ нужны корочки/специальность «престижная» и т.д. Студенты которым действительно это интересно знают и начинают понимать что это вообще такое хотя бы приблизительно не на лекциях записывая в конспекты а читая книги и пробуя это «на вкус» самостоятельно. Те кому интересно и кто хоть что-то понимает и хочет добиться, как правило, уже на первых курсах видят и чувствуют что то, что им дают — это жалкий мизер.
Граммар нацикам приношу свои глубочайшие извинения за пунктуацию. Писал на эмоциях и быстро:)
все таки в наше время или в наше евреям?
Я думаю, вашим евреям.
Я когда одному другу объяснял принципы ООП, пользовался другим примером.
Берём абстрактный класс «Алкоголь». У него в свойствах есть «градус», «количество», а в методах «Подействовать». От него наследуем два класса «Пиво» и «Водка».
Пиву выставляем градус к примеру в 7. Переопределяем метод «Подействовать». Теперь в него входят вызовы внутренних (приватных) методов, такие как «Повысить продуктивность написания кода», «Развязать язык», ..., в конце «Приспичить», определённых в классе «Пиво». У водки градус ставим в 40, переопределяем «Подействовать» на другие действия.
Так вот разобрали инкапсуляцию, полиморфизм и наследование.
Само собой я тут сократил пример, а так мы много там по ходу дела придумали :)
После эксперимента друг таки понял, что такое ООП и с чем его едят, и мы перешли к более серьёзным примерам.
:-)) Интересный подход. :-)
Но как я уже сказал, моей задачей было не объяснить принципы ООП, их студенты знают, но именно развитие объектного мышления. Для объяснения принципов ООП я использую печи и пекарей, звучит забавно. :-)
По поводу объектного мышления, из своего опыта могу сказать, что пока не начал программировать с применением ООП, полного понимания плюсов и минусов этого подхода не было.
С Вашим подходом, наверно, не сделал бы столько ошибок, которые в своё время привели к сотням строк множество раз переписанного быдлокода :)
Я тоже на это надеюсь. :-) Спасибо!
Нас учили так:
Задача — сделать шарик, летающий по экрану, отражаясь от стенок. Обычное решение — пара координат, в цикле двигаем.
Продолжение — увеличить количество шариков вдвое. Часть населения добавляет еще пару переменных, часть сделает пару массивов х и y. Удвоение колчиства шариков происходит до тех пор, пока все не перейдут на массивы.
Продолжение — добавляем различий летающим объектам, например цвет. Часть народу заведет массив с цветами шариков. Тогда добавляем еще свойств(например пусть летать будут не только шарики но и квадратики в результате некоторые сделают массив флагов, и будут вызывать разные функции рисования в зависимости от флагов) до тех пор, пока всем не надоест плодить массивы. В этот момент рассказывать о ООП/классах как о способе упростить эту конкретную задачу/уменьшить количество кода. Тогда это будет не просто абстрактная концепция, а реальный механизм для решения конкретных проблем.
Желаемый результат — 1 массив указателей на базовый класс летающих фигур с вызовом в цикле виртуальной функции продвижения на экране.
Превосходно, возьму на заметку :)
А меня просто никто не учил, я на самообразовании программирование изучаю.
Вот с множества одинаковых или неодинаковых объектов на экране или в интерфейсе я тоже начал понимать зачем все это нужно.
С другой стороны еще бы хорошо понять где остановиться. Т.е. не плодить лишних уровней наследования и как это связано со сложностью задачи.
UFO just landed and posted this here
Интересно. Неужели никто не догадался реализовать это на структурах и указателях на функции? :)
Вот из-за таких постов и заходишь в инфо хабраюзера, что бы подписаться на его блог!
Так держать!!!
Эх :) Побольше бы таких преподавателей :) Вы молодец.
Да, хотелось бы и мне того же в университете :)
А у вас, случайно, нет текстового варианта ваших лекций?:) Я бы почитал с удовольствием :)
К сожалению нет. :-( Я вообще сейчас хочу скринкасты делать, но не могу найти достойный инструмент. Либо платный, либо звук плывет, либо вообще что нибудь ужасное… Мб подскажет кто??
UFO just landed and posted this here
Было бы отлично как пример сделать простенькую игру, я думаю это было бы интересней :)
UFO just landed and posted this here
Да скажу честно, начинал то я с геометрических фигур. :-)) У нас все таки САПР и создание пейнта является задачей мало того что стандартной, так еще и привязанной к специфике. :-) И задача на геометрические фигуры у людей никуда не делась, но теперь она будет понятней. :-)
UFO just landed and posted this here
А Вы в чем создавали такую симпатичную диаграмму?
Visual Studio 2008, стандартный редактор диаграмм классов.
Есть ещё одна очень полезная программа для диаграмм, называется Staruml
Не такая уж красивая. Сведения о наследовании зачем-то продублированы.
Вы имеете в виду имя родителя в карточке объекта? По-моему это хорошо, чтобы в крупной диаграмме не выискивать по стрелкам от чего он там пронаследован.
Я думаю можно получить интересный результат если дать задачку, обычно решаемую с помощью паттернов. Посмотреть какие варианты предложат, а потом рассказать про существующий паттерн и бонусы именно такого решения.
Да, думал об этом. :-) буим пробовать. :-)
Полезная штука, а у нас в универе некоторые преподы об UML от меня услышали((( Вот так и живем по блок-схемам. Хотя вот, когда проходили базы данных, там нам UML давали, правда не называли таким образом, и мы красивые такие диаграммы отношений и сущностей рисовали, а потом через валидатор проверяли
Скорее всего вы рисовали физические и логические модели в каком нибудь ERWin'e.
Ну в основном мы их вообще на бумаге делали, но пару последних занятий именно ERWin'у и была посвящена
Всё хорошо, но возникает вопрос: а нафига учить студента мыслить объектно? Ну нарисует он вам 1000 процессов, происходящих в кинотеатре, а дальше что? Он сможет их запрограммировать без противоречий? Сможет их запрограммировать так, чтобы вся система обрабатывалась в 10 нитей?

Не сможет же. И, получается, что к 4 курсу людей надо учить абсолютным основнам: что такое строка, и почему метод в объекте нельзя вызывать из 10 разных нитей, не обвесив его синхронизацией, которая всю производительность нафиг убивает.

Йэхъ. И вот хоть бы кто-нибудь предложил учебную программу, в которой студентам (по ветке обучения программированию) сначала рассказывают об ассемблере, архитектуре процессоров, СИ, модулях, линковке… А к принципам ООП любой нормальный студент от курса алгебры и знаний о модулях и динамической линковке сам придёт, 10 минут поразмыслив.

А то у нас как получается — куча 'гениальных' UML'щиков, которые лихо рисуют монструазные схемки из квадратиков, а людей, которые это всё способны грамотно и эффективно запрограммировать — десятые доли процента от общей массы.
С другой стороны иногда приходится видеть и ещё большие шедевры, где наоборот не витают в облаках ООП, а лепят черти что, с точки зрения архитектуры, но по принципу «лишь бы работало». По собственному опыту скажу, человек может и придёт к принципам и пониманию ООП, но до этого он настрочит кучу непонятного кода, в котором будет странным образом смешан процедурный и ООПшный подход, а вид интерфейсов будет диктоваться сиюминутными проблемами. Потом всё это обрастёт костылями, так, как окажется, что за теми сиюминутными проблемами мы не увидели сути и получится огромная, полная копипасты, каша. ООП штука не такая простая и очевидная, как хотелось бы.
А основы алгоритмизации, вопросы типа «что такое строка?» и базовые знания по архитектуре хотя бы x86 должны ещё в школе давать, а не только учится рисовать в ломаном фотошопе.
Проблема «лишь бы работало» в человеке. В университете большинство кода пишется что быть выкинутым и забытым (ну или что бы кочевать сетям общежитий годами). У многих нет мотивации писать качественный код, да и нету того, кто научил бы этот качественный код писать.
На мой взгляд, есть весьма простое и полезное решение этой проблемы. Дать возможность заменить студенту написание курсовиков и лаб участием в openSource проектах. Тогда и мотивация будет и те, кто будут говорить прямо по делу, чем плох тот или иной код, человек ознакомится с программами контроля версий, научится работать в команде, а главное всё это будет приносить реальную пользу.
> По собственному опыту скажу, человек может и придёт к принципам и пониманию ООП, но до этого он настрочит кучу непонятного кода, в котором будет странным образом смешан процедурный и ООПшный подход, а вид интерфейсов будет диктоваться сиюминутными проблемами.

Вот и хочется что бы «ООПшный» подход стал понятен без «кучи непонятного кода».
Не поверите, но именно так построенна программа сейчас в Белорусском Государственном Университете Информатики и Радиоэлектроники на специальности ПОИТ факультета КСИС.
ООП объясняется на 3-м курсе после паскаля, си, ассемблера и архитектуры эвм.

Мне вот тоже совершенно не нравится то, что описано в посте. Человек должен мыслить не объектно, а практично. Заставлять втискивать мозг в рамки объектной модели C# и Java вредно для студентов.
У нас на соседней кафедре тоже ООП лишь на третьем курсе появляется.
дело в том, что с таким подходом получится не от простого к сложному, а от казалось бы простого к казалось бы сложному. на высокоуровневых языках проще показать алгоритмизацию, один IF с условиями куда понятнее чем десяток CMP + Jxx. человек не знающий программирования, имхо, не сможет начать писать на асме быстрее чем на си, если и тому и другому учить с нуля. программист это в первую очередь не знание языка, а склад ума. если человек может проанализировать задачу, выявить структуру, алгоритм решения, представить процессы взаимодействия элементов, то написать программу, реализующую этот алгоритм, не составит большого труда на любом языке. если же такого умения нет — сколько ни пялься в окно редактора, толковую программу не напишешь. говорю это на основании 2.5 лет наблюдения за потоком специальности Вычислительные машины и комплексы. Там как раз и асм есть и си и с++
Так вот как раз. Есть такое ощущение, что когда студент попишет кучу cmp и jxx, то он поймёт, что есть такое if, зачем он нужен и как работает. Точно так же и с ООП, нужно понять, через сложности с нетривиальными архитектурами, что такое ООП, где он уместен и зачем нужен. Основа всё-равно нужна. Потому что с мозгом, перегруженным объектно-ориентированным представлением о реальности ассемблер потом понять очень сложно. И это при том, что на самом деле в процессорах есть и интерфейсы, и инкапсуляция и прочие рюшечки. Но их обычному ООП-программисту, взрощенному на шаблонах проектирования и концепции 'всё есть объект', просто не видно. Вот… Как-то так. Поэтому и важно картину мироздания здесь выстраивать снизу вверх, а не сверху вниз. Когда человек обучается снизу вверх у него просто больше опыта накапливается в том, что можно считать абстракцией более высокого уровня, и в том, что смысла не имеет переводить на язык этих абстракций. Более богатая картина мира формируется. IMHO.
> Есть такое ощущение, что когда студент попишет кучу cmp и jxx, то он поймёт, что есть такое if, зачем он нужен и как работает. Точно так же и с ООП, нужно понять, через сложности с нетривиальными архитектурами, что такое ООП, где он уместен и зачем нужен.

Ваши ощущения ложны. Понять ООП через сложности с нетривиальными архитектурами, это все равно что учить ребенка плавать просто выбрасывая его за борт. Или сразу научиться, или утонет. При чем летальный исход вероятнее.
Почему? Вы что, заставляете студента без посторонней помощи сразу же писать систему, подобную 1С? Вы же как бы сопровождаете его во время изучения ассемблера, ООП и прочих прелестей. Никто никого никуда не выбрасывает.

Хотя… Вот когда человеку втолковывают ООП весь университетский курс, а потом он сталкивается с реальностью и видит, что в чистом виде ООП совсем не работает, чтобы построить что-то более или менее интересное приходится эти самые концепции ООП направо и налево творчески нарушать. А моделей мышления для способов этого нарушения у него очень мало, потому что ему со второго курса говорили ООП-ООП-ООП-ООП, и при этом он не знает механики этого самого ООП, чтобы понять, как вот в конкретном месте можно ООП обойти не впадая в противоречие с тем, как это ООП работает… То вот как раз и наступает ситуация 'выбросили без спасательного жилета в ледяную воду'.
> в чистом виде ООП совсем не работает
Раскройте. Я не понял.

> приходится эти самые концепции ООП направо и налево творчески нарушать
Мне жаль.

>при этом он не знает механики этого самого ООП
Это я и хочу дать.
Слава богу что ООП это не только три кита (четыре, поправлюсь). В первую очередь ООП это объектное мышление. Все эти полиморфизмы и наследования совершенно бессмысленны без понимания объекта. Объяснить принципы ООП просто. А вот научить МЫСЛИТЬ объектно сложно. Зачем учить мыслить объектно? Да как зачем? Что бы уметь применять ООП.
Технологиям тоже надо учить. И программировать тоже. Но это, не поверите, гораздо проще, если человек понимает принципы ООП, и понимает, что такое объект, зачем это.
Спорить о том, надо ли помимо технологий еще и объяснять основы проектирования — бессмысленно.
Объектное мышление это ООП головного мозга, а не мышление. Есть абстрактное мышление, которое помогает выбирать нужные абстракции под задачу, будь то объектно-ориентированное, функциональное или императивное программирование.
«На современном этапе развития информатики для успешного взаимодействия с компьютером необходим стиль мышления, который можно назвать объектным. Он предполагает умение разделить сложную систему на объекты и выстроить их иерархию, т.е. произвести объектную декомпозицию системы, а затем описать поведение этих объектов. Основной операцией при таком стиле является объектно-ориентированная декомпозиция, разложение объектов. Всевозможные классификации по различным логическим основаниям и логические методы формирования понятий составляют значительную часть методов, используемых при таком стиле мышления.» (С)
Отсюда. Это статья еще за 2006 год.
Выделяют:
1. Операциональный стиль мышления
2. Алгоритмический стиль мышления
3. Объектный стиль мышления
Допустим «объектное мышление» это сильно громко, будем считать, что мы просто используем инструмент ООП (именно ооп, а не объекты) чтобы описать взаимодействие неких сущностей.
ООП хороший инструмент, мы всё хорошо описали. Но когда руки доходят до имплементации, оказывается, что половину можно было упростить, реализовав проще и без объектов. Но я думаю, что вы всё-таки даёте достаточно практических заданий студентам, чтобы те могли выбрать нужный инструмент под задачу. Да и уровни абстракции не ограничиваются основными парадигмами, решение кучи задач без знания графов, множеств, операций над векторами, и т.д. выглядят очень удручающими.
Да нет, это не громко, это так и есть. Инструмент ООП бессмыслен без понимания объектов. Вы никогда не сможете применить этот инструмент правильно.
И, что бы вы там не говорили, ООП — это самый сильный инструмент для упрощения.

> Но когда руки доходят до имплементации, оказывается, что половину можно было упростить, реализовав проще и без объектов.

Не знаю о каких системах вы говорите. У нас кафедра САПР. Упростить систему убрав объекты, по крайней мере у нас (хотя подозреваю что много где), нельзя. Ах да, наверное при написании прошивок для микроконтроллеров там не попахивает ООП. Да, еще можно найти примеры где ООП будет лишним.
ООП лишним точно будет при написании простых скриптов для автоматизации некоторых процессов. Думаю оно будет лишним для мат. расчётов, там всё же вотчина функционального программирования.
А также, когда нужно написать простого, высокопроизводительного демона, ну для примера можно посмотреть на nginx
Ой, ну вот знаете, верно вы говорите, но не нравятся мне ваши слова. Знаете почему? Потому что я тоже разработчик, я разрабатываю корпоративные приложения. Я разработчик САПР, разрабатываю систему моделирования в рамках диссертации. И ваши слова, про то что ООП не нужен, никак не находят отклика в моем сердце. Просто у каждого свои задачи. Но ООП должен знать каждый. И каждый должен уметь применять его.
ООП нужен, конечно. Тов. Gorthauer87, вроде бы и не утверждал обратное. Просто не стоит пытаться его воткнуть в каждую дырку.
Я и говорю, когда речь идёт о каком-нить embedded, то тут уж каждый такт и бит будешь экономить.
Тоже и про приложения, работающие под высокой нагрузкой, там вызов виртуальной функции в цикле может дать «интересный эффект»
ИМХО сначала нужно учить процедурному программированию, потом функциональному, и уже потом ООП.
А вот не соглашусь. На самом деле выделают действительно три типа мышления, только называют их не так 'объектный' — это западный стиль, в котором действительно предполагается реальность разбивать на иерархии объектов, и каждое явление принято классифицировать и давать строгие определения его свойств. Есть стиль мышления 'образный' — это восточный стиль, в котором принято размышлять через описание отношений между некоторыми образами. При этом ценностью в этом стиле считается умение видеть неформальные связи между явлениями, вроде ответов на непостижимые для 'чисто' западного человека коаны: как звучит хлопок одной ладонью? А ещё есть стиль 'процессуальный' — это мышление, основанное на выделении процессов и попытках осознать отношения между ними. Вот. Я не знаю, с каким языком такой стиль связывают, и встречается он и на западе, и на востоке. Вроде как…

Но фишка в том, что и Китайцы, и Англичане, и вот эти процессуальные товарищи, весьма неплохо владеют компьютерами. И весьма неплохо программируют. Так что, утверждать: а вот ООП-шный стиль мышления самый лучший — это не правда. Концепцию объектов можно воспринимать с различных точек зрения, и не обязательно с точки зрения 'всё в мире является объектом' или 'всё в мире можно разбить на объекты' (скажите это электрону).

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

Но с их помощью решить задачу правильной иерархии объектов будет сложно.

Вот! О чём я и говорю :) Вы уже считаете 'задачу построения правильной иерархии' самой важной при программировании. ООП has you. В большинстве случаев задача решается гораздо элегантнее без построения этой иерархии.
> ООП has you
О да, и слава богу.

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

> Вы уже считаете 'задачу построения правильной иерархии' самой важной при программировании.
Если бы в программировании существовал инструмент столь же мощный как ООП, я бы так не считал. И, в следствии этого, да, я так считаю. И более того, как это ни странно, так и есть. Задача построения правильной архитектуры приложения и иерархии типов, является одной из самых важных при разработке программных продуктов, которые нацелены на долгую жизнь. Само собой надо знать и технологии. Но это, поверьте, объяснить порой гораздо проще.
> Задача построения правильной архитектуры приложения и иерархии типов, является одной из самых важных при разработке программных продуктов, которые нацелены на долгую жизнь.

Пожалуй просто программных продуктов.
Эмс. А вот в Linux нет никакой иерархии типов, означает ли это, что архитектура Linux — штука неправильная?
> Если бы в программировании существовал инструмент столь же мощный как ООП, я бы так не считал.

Если считать, что мощность подтверждается повсеместностью, то да. ООП — самый мощный. На самом деле, процессуальный стиль мышления и связанные с ним инструменты (coroutines, continuations) тоже имеет право на жизнь, хотя бы потому, что ООП крайне плохо масштабируется на многоядерные процессоры. И понятие «правильная архитектура приложения» будет различаться при разных подходах.
Как я уже говорил есть задачи решающиеся без применения ООП. Но, для таких задач достаточно знаний технологий и, чаще всего, процедурного подхода, который даже ребенок понимает.

А вот, кстати, нет. Если вспомнить историю, то ООП (Smalltalk) как раз и возникло, как попытка учить школьников программированию в рамках более простой и понятной модели.

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

А почему архитектура может быть правильной только в терминах ООП? Вот в приложениях для суперкомпьютеров, которые, можете сами проверить, живут гораздо дольше, чем всякие '1С', правильность архитектуры совершенно никак не связана с построением иерархии типов. Потому что, многие приложения в этой сфере пишутся на FORTRAN77, а там никаких иерархий нет, и даже user-defined типов. И ещё, из этой же области программирования с большой степень достоверности известно, что ООП плохо подходит для описания параллельного программирования. SUN, конечно, пытается всё свести к идеи о транзакционной памяти, но это не самый эффективный подход к делу.
Почему-то автор известного языка с поддержкой ООП Бьярн Страуструп тоже против «биологической аналогии» при объяснении принципов ООП. Вместо этого он предлагает подход с выделением т.н. «артефактов программирования». А вот что бы научиться эти артефакты выделять, никакое теоретизирование на UML`ях не заменит реальный опыт алгоритмизации без разных абстракций.
SICP — шикарный курс, от основ абстракции до интерпретаторов, регистровых машин и компиляторов.
> Задача студентов — создать модель, позволяющую реализовать как можно больше процессов в кинотеатре.
Плин, чёртов Скайп, порождает привычку писать новые строки по Ctrl+Enter.

> Задача студентов — создать модель, позволяющую реализовать как можно больше процессов в кинотеатре.

Вот из-за таких постановок задач мы имеем то, что имеем.
Ну не придирайтесь. Суть я думаю верно передана. Можно конечно поизвращаться и написать:
Доменную модель, позволяющую реализовать логику для тех или иных процессов, которые может инициировать человек в кинотеатре. :-) может быть вы сформулируете более точно и правильно.:-)
Даже и не подумаю. Сама задача, в самом своём сердце, бесполезна — разработка ради разработки. А потом появляются всякие творения, типа парсера выполненого по всем канонам метапрограммирования, который выпарсивает три числа из строки, зато метапрограммирование во все поля.
> Сама задача, в самом своём сердце, бесполезна — разработка ради разработки
Раскройте. Вот честно — ничего не понял.

Какая задача более полезна для образования начинающего математика «напишите на листочке как можно больше чисел» или «напишите на листочке как можно больше простых чисел»? Очевидно, что вторая.

Задача же которая стояла перед вашими студентами относится к первой детсадовской категории, по той причине что не ставит никаких ограничений-условий — урок рисования.

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

Только в некоторых языках. Непосредственно к ООП это не относится.
UFO just landed and posted this here
Спасибо! Большего и не надо. :-)
UFO just landed and posted this here
Visual Studio 2008, стандартный редактор диаграмм классов. Кнопка будет вверху Solution Explorer'а, при выборе сборки, пиктограмма в виде увеличительного стекла и диаграммы. :-)
А в Express Edition такое присутствует? Мне тоже сильно интересно.
Здорово=) Нам в начале семестра еще дали задачку, где надо было смоделировать ситуацию: у некой бабульки сломалась лампочка и она вызывает электрика, чтобы он ее починил. Чтобы дотянуться до лампочки, электрик может воспользоваться столом, стульями и книгами, которые есть у бабушки. Но у нас акцент делался именно на инкапсуляцию. Т.е. мы должны были строго разделить роли.
А вы показывали или планируете в будущем показывать/рассказывать, как реализуется ООП?
Конечно. Студенты знают принципы ООП и умеют реализовывать их.
Если не секрет, на примере чего?
gobject, CLOS, или, может быть, сами писали? Если последнее, то на каком языке?
Я вас не правильно понял первый раз. Нет, мы не рассматривали то как можно создать ООП язык.
Чувствую в вам просыпается праведный гнев? :-) Нет, скорее всего это мы рассматривать не будем.
Давно перед преподавателями стоит задача научить студентов мыслить объектно >> Давно перед преподавателями стоит задача научить студентов мыслить

Так, пожалуй, будет правильно. Если человек умеет думать, то он может сам легко научиться думать объектно, если человек умеет думать объектно, то он умеет думать.
Я думаю, что студентов не нужно учить мыслить объектно. Технологии должны подстраиваться под людей и служить им, а не наоборот. Это, если рассмотреть вопрос философски. Согласен с предыдущим оратором — нужно учить думать, просто думать.
Так не бывает. Процесс всегда двусторонний: технологии навстречу человеку, человек навстречу технологиям. Это не хорошо и не плохо, это реальность.
Радует близость ваших примеров к жизни. Наш преподаватель по ООП очень любит давать примеры а-ля «опишите матрицу n*n, включая методы для транспонирования, сложения и умножения матриц». Или клон класса BigInteger, например.Вроде бы и полезно, но от скуки, велосипедности и сферовакуумности просто сводит зубы.

Еще очень здорово, что вы даете студентам свободу для творчества.
Тоже применял подобную схему в 2002( или 2003 ?). Мы рассматривали квартиру с электроприборами, розетками, предохранителями. Добавляли сенсоры, кондиционеры, обогреватели, водопровод, жильцов, животных… :)
Заканчивали умным домом.
Еще задачки для тренировки:
— моделирование животного мира на плоскости (волк, заяц, капуста)
— самолет и парашютисты
— таксист и пассажир
Спасибо. :-) Интересно! Обязательно возьму что нибудь. :-)
А почему бы не дать задачку: операционная система и драйверы мышки? :) Или там робот и система распознавания образов?
Всё таки, мне кажется, для студента второго курса «построить» свой живой кинотеатр будет куда интереснее, чем волки и зайцы :)
Да, мне тоже пример понравился. Буду его выдавать. Проблема, собственно, в том что каждому лучше свой вариант выдавать, чтобы больше сам думал и меньше у других срисовывал. Но с другой стороны, коллективное решение позволяет получить более проработанные варианты. Приходится балансировать между «каждому свой вариант» и «всем один».
Наверное, вы хороший преподаватель, раз действительно хотите, чтобы ваши студенты понимали предмет.
Сам будучи студентом, очень уважаю таких преподавателей, с ними же интереснее работать, они мотивируют к действию проявляя свой интерес к решению каких-либо задач.

«Прошла конференция, посвященная ООП. Одни докладчики говорили про моделирование объектов реального мира и их иерархий. Другие — по делу…» =)

Объясните, почему продавец жетонов — которые на диаграмме суть деньги — до сих пор на свободе, ведь он, осуществляя обмен, и не являясь представителем кредитной организации, злостно нарушает закон «О валютном регулировании и валютном контроле»? Как продавцу жетонов самому поиграть на игровом автомате? Как разместить на диаграмме класс для механического продавца — автомат-обменник, меняющий купюры на жетоны, — так чтобы при этом он не оказался киборгом (наследником человека)?
Вы можете сложить 0.5 и 0.5, получив 1, но из двух огрызков вы не получите целого яблока. Объекты из ООП имеют примерно такое же отношение к объектам реального мира, как натуральные числа к огрызкам от яблок — и то и другое это абстракции. Развитие «объектного мышления» это развитие абстрактного мышления, с использованием концепций ООП.

Одна из них — интерфейс — абстракция поведения (взаимодействия сущности в внешним миром). На диаграммах используется наследование классов там, где нужно было использовать реализацию интерфейсов. В самом деле, описав интересующее поведение «продавца» и «игрока» интерфейсами, можно было бы абстрагироваться от конкретной сущности «человек», и в последствии, без проблем, перенести это поведение на автоматы-обменники. Мне кажется, эта ошибка, стала следствием того, что автор слишком много уделяет внимания объектам реального мира. :)
Везде надо идти постепенно. Сначала надо дать представление о том что все объекты реального мира можно представить в виде объекта (программного класса, типа) и его свойств и методов. Дальше что можно создать иерархию объектов. Дальше что можно выделить свойства и методы внутри самого объекта и через которые с объектом можно взаимодействовать. Дальше можно выявить интерфейсы. Потом показать что один и тот же интерфейс подходит для совершенно разных объектов. Дальше можно показать что объектом можно представить все что угодно, даже какой либо процесс.

Я прекрасно знаю что такое интерфейс. Я все таки еще и программист. Но все надо давать последовательно. Опираясь в дальнейшем на знания предыдущие.

Вы верно сказали что объектное мышление это абстрактное мышление, с использованием концепций ООП. Но именно объектное мышление я и хочу развить у студентов.

> Объекты из ООП имеют примерно такое же отношение к объектам реального мира, как натуральные числа к огрызкам от яблок — и то и другое это абстракции.
Верно. И в школе сначала учат считать на палочках и яблоках. Я хочу сделать примерно тоже самое.

Одного не пойму. Вы за или против этого метода? Просто говорите Вы вроде тоже самое что я пытаюсь сделать, но вот Ваш тон, как мне кажется, далек от тона человека который за этот метод.

>Мне кажется, эта ошибка, стала следствием того, что автор слишком много уделяет внимания объектам реального мира.
Автор уделяет объектам реального мира внимания ровно столько, сколько требуется для того что бы развить в студентах объектное мышление. И еще одно, ошибки тут нет. Знаете почему? Потому что не было правил.
Очень хороший подход. Business domain хорошо известен аудитории. Все студенты готовы к построению объектной модели.

На мой взгляд этот пример стоит проходить в 2 итерации. Первая итерация — как Вами описана. Вторая — с добавлением *Требований* и критериев качества к будущей объектной модели.

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

Требования можно описывать в виде коротких User Stories:

— Пользователь имеет возможность начать игру на автомате. Для этого он должен вложить в него жетон.

— Пользователь имеет возможность разменять монеты для получения жетонов.

и т.д.

Для сравнения объектных моделей которые получают студенты можно воспользоваться критерием(ями) оценки. Например та модель лучше, в которой меньше классов.

Sign up to leave a comment.

Articles