Личный кабинет

Объектно-ориентированное программирование для школьников

Как учить школьников объектно-ориентированному программированию
Станислав Михалкович ( Пользователь )
Цитата (info21, 31.01.2011, 20:31) <{POST_SNAPBACK}>
это ваша весьма пристрастная интерпретация.
Потому что перефразировка дословной быть никак не может.


Да, Вы правы относительно перефразировки. Я, разумеется, утрирую.

Я просто пытаюсь направить топик в конструктивное русло. Если считаете, что нельзя преподавать ООП у школьников в том или ином виде - честно выскажите своё мнение и не пишите в топике. Если считаете, что можно - пишите, как. А то - очень много пространных рассуждений ни о чём.

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

Я - хочу конструктива. От споров все устали.




Цитата (Александр Горячев, 31.01.2011, 21:14) <{POST_SNAPBACK}>
Мне было интересно, как можно обучать ООПрограммированию, начиная с ООАнализа и ООПроектирования. Чтобы была видна польза и от анализа и от проектирования. Вроде бы основная польза от анализа и проектирования ожидается только при работе с большими проектами, при попытках обуздать естественную сложность задачи. Это противоречило тому, что обучают на простых примерах.
...
А проблема выращивания кода актуальна, что для разработчика большой системы, что для разработчика скромного проекта. То есть в этом случае актуальность ООА и ООП не зависит от размера задачи.
Конечно, над такой методикой я ещё детально не задумывался, наверное нужны будут и заранее заготовленные скелеты, которые надо будет наполнять, и много ещё чего, но это просто для меня новая мысль.
Если она для вас очевидна, ну, извините.

Ну, нетривиальные мысли, Александр Владимирович. Наверняка мои не вполне с вашими пересекаются. Но всё же позволю порассуждать.

ООА и ООПроектирование - для школьника, с моей точки зрения - круто. Элементы - да, помощь преподавателя тут неоценима. Скажем, преподаватель спроектирует, нарисует - хороший школьник будет программировать.

В учебных проектах действительно сложно это - либо проект очень простой, либо - школьнику не справиться.

У меня такой опыт обучения ООП школьников: проекты чуть больше простейших. Как правило, игровые - остальное обычно им неинтересно. Самый простой уровень обычно такой - выделяем объекты игры (один-два), определяем их свойства (поля) и пишем для них несколько методов. Скажем, для примера, Робот на клеточном поле - методы Init, Draw, перемещения. Потом пишем простую программу с участием одного Робота. Потом - вторую - чуть более сложную - где, допустим, пара объектов. Всячески подчеркиваю, что оформление Робота в единое целое упростило задачу.

Потом - интересный этап потом. Здесь у школьника происходит этап осмысления, что, написав класс объектов, он может писать простые программы. При этом либо менять логику программы, либо наполнять Робота методами.

В простейшем варианте этим всё заканчивается - сложность начинает превосходить школьную, и школьнику надоедает развивать один проект несколько занятий.

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

Были пробы ввести несколько классов и устроить их взаимодействие. У школьников - обычно только в одну сторону - я проектирую, они пишут. Сами - не проектируют.

Есть ряд мыслей. Все - не вспомню сейчас - возникали в разное время, не систематично. Надеялся, что при обсуждении в этой теме начну их вспоминать.

Ну вот, например, одна. В Смоллток-системах все классы были внутри - в песочнице. И их можно было просмотреть - все их методы. Добавление нового сразу приводило к тому, что он появлялся глобально. Были и учебные системы - SQueak, помнится... Идея - использовать такую постепенно пополняемую объектами систему. Когда одни ученики разрабатывают простые классы, другие в следующем году ими пользуются, разрабатывают свои - и так возникает свой мир учебных самолично сделанных классов - ну, для какого-то круга задач. Найти бы. И - эти классы активно используются для иллюстрации изучаемых алгоритмов и для создания всё более нетривиальных учебных проектов. С количеством строк кода не больше 50 скажем.

Можно обсудить какие-то наполнения этой идеи, можно обсудить другие идеи. Основное - повторная используемость уже написанного школьником кода и посильно лёгкая модифицируемость этого кода.
Александр Горячев ( Пользователь )
Интересно. Мне почему-то кажется, что если ученик будет наблюдать процесс ООА и создания скелета (классов игрового проекта и методов-пустышек), а сам будет только участвовать в наполнении методов, то может быть он сможет "снять" модель работы в ООП. То есть, может заранее отводить ученику не роль мини-мастера в своем мини-проекте, а роль подмастерья, наблюдающего за работой мастера и вносящего свой вклад в эту работу.
Это пока что "фантазии на тему", но многое начинается с хороших плодотворных фантазий.
Федор Ткачев ( Пользователь )
Цитата (Михалкович Станислав, 31.01.2011, 21:41) <{POST_SNAPBACK}>
Если считаете, что нельзя преподавать ООП у школьников в том или ином виде - честно выскажите своё мнение и не пишите в топике. Если считаете, что можно - пишите, как.
...
Я - хочу конструктива. От споров все устали.

Я тоже устал от ваших искажений, и это единственная причина, вынуждающая меня повториться.

Совет начать с того, чтобы взять Оберон, -- если это не конструктив, то что это :)

Вы опять мне приписываете какие-то "считания", причем прямо вопреки всему мною сказанному: первые элементы ООП, для введения которых вам нужно специально что-то придумывать, у нас зримо явлены с первой процедурки для черепашки. Или -- у Виталия Валериевича -- с первого ввода с помощью модуля In.
И никаких "как" тут уже не требуется: как только программа переросла один модуль, "объектность" в ней появляется совершенно автоматически.

От умения абстрагировать и выделить один модуль до умения абстрагировать и выделить объект -- один, по сути чисто синтаксический шаг.

Теоретически для продвинутых можно смотреть файлы, сканеры-мапперы, простенькие вьюшки -- это всё "программирование с объектами", без которого в Блэкбоксе per se шагу ступить нельзя.
Разумеется, можно что-то более игрушечное придумывать. Хотя бы упрощенную файловую систему, в виде фасадика над основной.

О каком-то подобии ООА можно говорить только при уверенном умении жонглировать каскадами процедур и записей.
Думать и чего-то проектировать на высоких уровнях в терминах "объектных" абстракций можно, только умея на автомате заполнять кодом расстояние от этих уровней до самого низа.
Пока такого уверенного автоматизма не достигнуто, говорить о проектировании на высоких уровнях невозможно: мозг либо тупит в непонятках, либо срывается в комбинаторное удовольствие от борьбы с деталями реализации.
Просто так он, мозг устроен: когда видит комбинацию, получает импульс энтузиазма к ее реализации.

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

Цитата (Александр Горячев, 31.01.2011, 23:15) <{POST_SNAPBACK}>
может заранее отводить ученику не роль мини-мастера в своем мини-проекте, а роль подмастерья, наблюдающего за работой мастера и вносящего свой вклад в эту работу.
Это пока что "фантазии на тему"

Это изменение подхода -- вполне в духе того, что я только что написал.

Но необходимость абсолютно уверенного владения способами реализации не отменяется.
Сергей Кондрашов ( Пользователь )
Цитата (Александр Горячев, 31.01.2011, 21:14) <{POST_SNAPBACK}>
Читая эту тему, я подумал, что можно попытаться увидеть и иную пользу от ООА и ООП. Это эволюционный путь создания ПО. Красиво раскладывать код по полочкам полезно не только для того, чтобы держать его в голове под контролем и облегчить отладку. Это ещё можно делать для того, чтобы выращивать программу. Делать как-то работающий скелет и постепенно его наполнять. И здесь раскладывание кода по полочкам сущностей очень даже может помочь.
А проблема выращивания кода актуальна, что для разработчика большой системы, что для разработчика скромного проекта. То есть в этом случае актуальность ООА и ООП не зависит от размера задачи.

Именно так и происходит при проектировании и программировании объктных веб-ориентированных приложений (исполняемых на стороне клиента), например, ajax приложений с использованием библиотеки jQuery (где в основном реализуется не наследственная объектная модель, а агрегатная).
Станислав Михалкович ( Пользователь )
Цитата (info21, 31.01.2011, 23:21) <{POST_SNAPBACK}>
Совет начать с того, чтобы взять Оберон, -- если это не конструктив, то что это :)

Да кто ж спорит.

Цитата (info21, 31.01.2011, 23:21) <{POST_SNAPBACK}>
От умения абстрагировать и выделить один модуль до умения абстрагировать и выделить объект -- один, по сути чисто синтаксический шаг.

Да. Я и предлагаю его сделать. Модуль один - объектов может быть несколько. Объект - это и модуль и тип - ну да - Вы знаете.

Цитата (info21, 31.01.2011, 23:21) <{POST_SNAPBACK}>
Теоретически для продвинутых можно смотреть файлы, сканеры-мапперы, простенькие вьюшки -- это всё "программирование с объектами", без которого в Блэкбоксе per se шагу ступить нельзя.
Разумеется, можно что-то более игрушечное придумывать. Хотя бы упрощенную файловую систему, в виде фасадика над основной.

Во-во. Что-то. Первый шаг. Хотелось бы пораскручивать эти идеи. Не считаю это бесполезным.
Про фасады Вы правы. Но можно и не фасады - можно из низкоуровневого всё-таки делать высокоуровневое. Хотелось бы - оригинальные и нешаблонные идеи. Идея взять стандартный элемент управления - шаблонная.

Цитата (info21, 31.01.2011, 23:21) <{POST_SNAPBACK}>
О каком-то подобии ООА можно говорить только при уверенном умении жонглировать каскадами процедур и записей.

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

Цитата (info21, 31.01.2011, 23:21) <{POST_SNAPBACK}>
Думать и чего-то проектировать на высоких уровнях в терминах "объектных" абстракций можно, только умея на автомате заполнять кодом расстояние от этих уровней до самого низа.

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

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

Цитата (info21, 31.01.2011, 23:21) <{POST_SNAPBACK}>
Поэтому хорошие архитекторы (которые могут реально продуктивно думать на высоких уровнях абстракции) -- это всегда хорошие программисты

Я и предлагаю нам побыть архитекторами, даже если мы себя и не считаем хорошими программистами. Учитель создает каркас, ученик его наполняет и расширяет.

Я об этом веду речь - придумать. разработать коллективными усилиями несколько возможных каркасов. которые а) были бы интересны школьникам и б) выполняли методические задачи по изучению отдельных тем курса информатики.

Ничто, кстати, не мешает. брать предметные области других пердметов. Например, разработать обучающую программу по географии - страны, столицы и города. С учителя - каркас, минимальный конструктор, с ученика - вначале - использование каркаса и уже написанных классов, потом - доработка. Возможен и вариант, когда слабые ученики используют, более сильные - дописывают методы.
Дмитрий Изергин ( Пользователь )
А может быть... по - другому. Для начала, определимся с целью и ее весом (в общей системе ТРЕБОВАНИЙ школьной программы ), затем с начальными параметрами (контингент, реально допустимую степень ментальных и телодвижений исполнителя- учителя). Далее, со сроком в течении которого эта цель должна быть достигнута... После поговорим об существующих инструментах для достижения этой цели. Затем перейдем к примерам и разработкам (если их нет или они целесообразны).... ?
Станислав Михалкович ( Пользователь )
Цитата (DIzer, 05.02.2011, 21:14) <{POST_SNAPBACK}>
А может быть... по - другому. Для начала, определимся с целью и ее весом (в общей системе ТРЕБОВАНИЙ школьной программы ), затем с начальными параметрами (контингент, реально допустимую степень ментальных и телодвижений исполнителя- учителя). Далее, со сроком в течении которого эта цель должна быть достигнута... После поговорим об существующих инструментах для достижения этой цели. Затем перейдем к примерам и разработкам (если их нет или они целесообразны).... ?

Мы вообщем-то уже договорились, что эта тема - для школьников, но не для школьной программы. И Вы - не первый, кто в этом топике пытается спустить обсуждение до того, что это не надо.

Я предлагаю - считаете так - не пишите в тему. Потому что и так рассуждения об этом и не об этом занимают более половины темы.

А цели и представление о хорошем - у каждого свои.
Федор Ткачев ( Пользователь )
Но DIzer прав в том, что чтобы "изучение ООП" стало осмысленным, нужна уже серьезная база, о которой я уже говорил. Без этой базы останется бессмысленная имитация.

Кстати, в классическом Обероне это хорошо видно из того, что там и методов-то нет, не во что играть :) нужно сразу делом заниматься.

Дмитрий Изергин ( Пользователь )
Цитата (Михалкович Станислав, 06.02.2011, 02:11) <{POST_SNAPBACK}>
Мы вообщем-то уже договорились, что эта тема - для школьников, но не для школьной программы. И Вы - не первый, кто в этом топике пытается спустить обсуждение до того, что это не надо.

Я предлагаю - считаете так - не пишите в тему. Потому что и так рассуждения об этом и не об этом занимают более половины темы.

А цели и представление о хорошем - у каждого свои.


Я говорю Вам про конкретику, которая у Вас напрочь отсутствует - об этом свидетельствует употребление слова "это" - Это - что? Комплекс который вы собираетесь разработать?, OOП (если ООП то в каком объеме, все компоненты парадигмы охватываются или только, например инкапсуляция)? А может имеется ввиду то, что, некоторые форумчане называют "ООП анализом"? Школьники кто они? - вундеркинды тинейджеры, интересующиеся предвыпускники? Требуется ли от учителя экстра квалификация (по отношению к среднестатистическому уровню). Если для достижения "ЭТОГО" потребуются значительное время , пойдет ли он на это? Наконец, инструментарий (очень хорошая идея может достаточно просто реализовываться на одном языке -например, PABC - но в какой нибудь школе совершенно невозможно будет результатами Вашего труда воспользоваться , даже если там будет талантливые педагог и школьники - он просто нормально не встанет на компьютеры класса, с другой стороны, допустим ту же идею можно реализовать затратив на порядок больше усилий на ББ - но работать продукт будет на всем)...Как преподаватель, который встречает школьников на входе в ВУЗ, я буду только рад если хотя бы часть из них сможет нормально инкапсулировать. Да что там, я буду просто счастлив если хотя бы 1 или 2 человека умели грамотно выписывать интерфейс (процедуры или функции). Просто реальность уже как 3 года такова - что 1-2 человека на группу в принципе могут написать подпрограмму, и то для них она всего лишь "именованная последовательность операторов языка".... Извините...
Станислав Михалкович ( Пользователь )
Цитата (DIzer, 06.02.2011, 16:48) <{POST_SNAPBACK}>
Я говорю Вам про конкретику, которая у Вас напрочь отсутствует - об этом свидетельствует употребление слова "это" - Это - что? Комплекс который вы собираетесь разработать?, OOП (если ООП то в каком объеме, все компоненты парадигмы охватываются или только, например инкапсуляция)? А может имеется ввиду то, что, некоторые форумчане называют "ООП анализом"? Школьники кто они? - вундеркинды тинейджеры, интересующиеся предвыпускники? Требуется ли от учителя экстра квалификация (по отношению к среднестатистическому уровню). Если для достижения "ЭТОГО" потребуются значительное время , пойдет ли он на это? Наконец, инструментарий (очень хорошая идея может достаточно просто реализовываться на одном языке -например, PABC - но в какой нибудь школе совершенно невозможно будет результатами Вашего труда воспользоваться , даже если там будет талантливые педагог и школьники - он просто нормально не встанет на компьютеры класса, с другой стороны, допустим ту же идею можно реализовать затратив на порядок больше усилий на ББ - но работать продукт будет на всем)...Как преподаватель, который встречает школьников на входе в ВУЗ, я буду только рад если хотя бы часть из них сможет нормально инкапсулировать. Да что там, я буду просто счастлив если хотя бы 1 или 2 человека умели грамотно выписывать интерфейс (процедуры или функции). Просто реальность уже как 3 года такова - что 1-2 человека на группу в принципе могут написать подпрограмму, и то для них она всего лишь "именованная последовательность операторов языка"...

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

1. Охватываются не все компоненты парадигмы, а некоторые. Какие - предлагается обсудить - на примере какой-нибудь реализации. Навскидку - использование инкапсуляции без защиты доступа. И самое примитивное проектирование типа CRC-карточек. Это - мой опыт.
2. Ориентация - на школьников, которые собираются поступать по специальности (предлагаю это не формализовывать или формализовать так - в те ВУЗы, куда сдается информатика)
3. Ориентация - на учителей выше среднего (все здесь присутствующие и некоторые остальные :)
4. Ориентация - не на какую-то конкретную систему. Предполагалось, что решения будут приводиться на разных языках, не предполагалось сравнивать языки между собой, а, наоборот, найти общее, что более-менее выражается везде - даже на КуМире (наверное, если сильно постараться).
5. Идти от конкретной задачи, а не от общих принципов.
6. Взять задачу, близкую школе.

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

Задача. Создать систему, тестирующую ученика по какому-нибудь предмету. На вопросы можно отвечать только Да, Нет. В конце выводится количество правильных ответов. Может, предлагается повторно пройти тест. Хорошо бы обеспечить хоть какую-то расширяемость в будущем.

Эту задачу я решал со своими школьниками не далее как сегодня. Не ОО образом - цели такой не было, и уровень у них был пониже требуемого, и разработка заканчивалась одним уроком.

Эта задача в разных интерпретациях попадается мне каждый год на всевозможных олимпиадах школьных программных разработок - большинство реализаций в ужасном исполнении.

footer logo © Образ–Центр, 2020. 12+