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

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

Как учить школьников объектно-ориентированному программированию
Александр Горячев ( Пользователь )
Цитата (Михалкович Станислав, 24.09.2010, 17:54) <{POST_SNAPBACK}>
Научимся разбивать задачу на объекты для каких-то школьных задач, использовать специально созданные для школы объекты для решения школьных задач.

Это правильно.
Потому как "в ОО-подходе ключевым шагом является выбор правильных абстракций данных: типов объектов, характерных для данной проблемной области."
Ключевой шаг. Запомним.
Станислав Михалкович ( Пользователь )
Цитата (info21, 24.09.2010, 18:29) <{POST_SNAPBACK}>
И совершенно незачем воду мутить: следует начать новую тему "Записи и структурирование данных", а здесь пусть уж будет про настоящее ООП.

Хорошо. Как Вы боитесь слова "объект".
Вернемся к началу. Вот определение объектно-ориентированного программирования из Википедии: Объе́ктно-ориенти́рованное программи́рование (ООП) — парадигма программирования, в которой основными концепциями являются понятия объектов и классов. Я не буду придумывать другие, оригинальные, определения - их можно придумать много, но веры им нет. На этом определении мы и остановимся. Оно - простое. "Записи и структурирование данных" - это ничего не говорящие слова. Неочевидно, непонятно.

Вот и будем работать с классами и объектами. Во многих языках они есть.

Я обещал примеры. Надеюсь, что тему многие читают - она не может быть не интересной.

Пример 1. JavaScript-библиотека JSXGraph - геометрические объекты, графики функций, диаграммы. Типичные объекты. Вот тут - куча примеров. Не массовая школа, но - всё же. В профильных группах - для тех, кто программирует на JS - можно использовать. Никакого тебе разбиения на подзадачи, никакой алгоритмизации. Голые объекты - конструирование, установка свойств - визуализация геометрических объектов. В качестве элементов обучения: создание объектов, свойства, списки, вложенные объекты, события и привязка к ним изменения свойств. Для школьников сложновато, но как идея и при должной адаптации - хорошо. Кстати, там и черепашья графика есть:

<html>
<head>
<link rel="stylesheet" type="text/css" href="jsxgraph.css" />
<script type="text/javascript" src="jsxgraphcore.js"></script>
</head>
<body>
<div id="box" class="jxgbox" style="width:500px; height:500px;"></div>
<script type="text/javascript">
var brd = JXG.JSXGraph.initBoard('box', {originX: 250, originY: 250, unitX: 50, unitY: 50});
var t = brd.createElement('turtle');
for (i=0; i<4; i++)
{
t.forward(1);
t.right(90);
}
</script>
</body>
</html>

Квадратик рисует. Использует объект t - Черепаха.

Пример 2. Невизуальные объекты и классы. Хорошо известные любому школьнику. Это Школа, Класс, Ученик, Учитель, Предмет. Пишутся почти на любом языке программирования. Воспринимаются как классы объектов. Для каждого детализируются свойства. Скажем, Предмет хранит информацию об Учителе, Список Учеников, Список оценок учеников. Затем возникает задача найти для каждого ученика по данному предмету среднюю оценку. Где хранить метод вычисления средней оценки? В Предмете? В специальном классе СтатистикаОценок?

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

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

Пример 3. Scratch. Спрайты - объекты, скрипты - обработчики событий, в которых меняются свойства объектов. Полиморфизм - неявный - объекты разных типов рисуются, перемещаются и проч. Все объекты уже созданы - не надо проводить ОО анализ. Мы с помощью уже готовых объектов строим приложения, управляемые событиями.
Федор Ткачев ( Пользователь )
Цитата (Михалкович Станислав, 24.09.2010, 23:30) <{POST_SNAPBACK}>
Хорошо. Как Вы боитесь слова "объект".

Я не боюсь слов. Я боюсь шарлатанов.


***************************
Цитата (Михалкович Станислав, 24.09.2010, 23:30) <{POST_SNAPBACK}>
детализируются свойства. Скажем, Предмет хранит информацию об Учителе, Список Учеников, Список оценок учеников. Затем возникает задача найти для каждого ученика по данному предмету среднюю оценку.

Цитирую http://www.inr.ac.ru/~info21/texts/2003-08-JMLC/ru.htm

Цитата ("Информатика-21, доклад на конференции JMLC'2003")
Курсы программирования для школ (8-11 классы) должны подводить посредством простых, тщательно построенных примеров к систематическим методам построения программ, которые в полном объеме должны преподаваться в общих курсах программирования в университетах.

... еще только предстоит осознать далеко идущие последствия для преподавания (как, впрочем, и для дизайна алгоритмов) такой особенности Оберона, как автоматическое управление памятью.[8]

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

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

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


Можно предположить, что указанный в отрывке крен (=незнание школьными учителями тематики записей-списков-...) и привело к тому, что "объектное программирование" воспринимаются как откровение.

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

И еще, выше говорилось, что главное в ООП это абстракция данных и этим фактом можно ограничится. Но абстракция данных это общая идея любой парадигмы программирования. Поэтому тогда совершенно не понятно, чем ООП отличается от не ООП.
Станислав Михалкович ( Пользователь )
Цитата (Потопахин Виталий, 27.09.2010, 21:41) <{POST_SNAPBACK}>
Но объект без инкапсуляции, наследования и полиморфизма становится настолько выхолощенным, что по моему просто теряет смысл. Нужность же и возможность введения этих понятий в школьный курс очень сомнительна.

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

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

Признайтесь - не использовали объекты для обучения школьников и не пытались? Или всё-таки пытались?

На мой взгляд, без наследования и полиморфизма на начальном этапе можно обойтись. А вот инкапсуляция - это код и данные в одной капсуле. Это важно, как и точечная нотация. Не все языки тут подойдут. Скажем. в том же Обероне нет методов внутри записей - методы синтаксически записываются как внешние функции, привязанные к данной записи. Капсула отсутствует. Если выбирать похожую альтернативу, я бы выбрал язык Зоннон, разработанный, как и Оберон, Гудкнехтом. В нём есть уже классы, где данные и методы находятся в одной капсуле.

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

При сегодняшнем подходе к обучению в школе все программы пишутся с нуля, что формирует неправильное представление о современном программировании.
Федор Ткачев ( Пользователь )
Цитата (Михалкович Станислав, 28.09.2010, 01:25) <{POST_SNAPBACK}>
Мне кажется, что Вы воюете со своими драконами. Вы даете какое-то определение ООП ...

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

А вам непременно хочется выпятить "объектность", потому что слово object зашито в ваш самодельный язык. Это тоже мне так кажется.

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

И даже не просто вредно умножать таким образом сущности -- а конкретно в контексте школы как институции, функционирующей в масштабах 10М школьников и 30 лет, -- преступно. Мне так кажется.

Цитата (Михалкович Станислав, 28.09.2010, 01:25) <{POST_SNAPBACK}>
При сегодняшнем подходе к обучению в школе все программы пишутся с нуля, что формирует неправильное представление о современном программировании.

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

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

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

А переход к коллективной разработке (в будущем проф. обучении на уровне ун-та) отлично подготавливается внедрением в головы понятий модульности, интерфейсов и т.п.
Дай бог хотя бы это суметь сделать на самом базовом (но настоящем) уровне в ограничениях школы (или даже Байтика).
Александра Сурина ( Пользователь )
Цитата (Михалкович Станислав, 28.09.2010, 01:25) <{POST_SNAPBACK}>
При сегодняшнем подходе к обучению в школе все программы пишутся с нуля, что формирует неправильное представление о современном программировании.


Но при этом, как показывает практика, дает неплохую базу для последующего обучения. Другое дело - нужно ли это школьникам, или все-таки это вопрос дополнительного образования? А основная масса пусть учится собирать замки из готовых кубиков без заглядывания внутрь оных - вряд ли более двух-трех человек из класса будут всерьез заниматься программированием в своем взрослом будущем, слишком много других интересных профессий.
Виталий Потопахин ( Пользователь )
ООП в обучении я как раз использую, но я стараюсь различать ситуации, где в этом есть смысл, а где нет. Что же касается определения ООП. У меня своего определения просто нет.
Серж Андреев ( Пользователь )
ООП - а в чем проблема-то? Мне, например, нравится. Многое описывается гораздо проще. В свое время учил оный принцип с помощью книги "Турбо-паскаль".
Станислав Михалкович ( Пользователь )
Цитата (info21, 28.09.2010, 08:11) <{POST_SNAPBACK}>
Цитата
Цитата (Михалкович Станислав, 28.09.2010, 01:25) →
Мне кажется, что Вы воюете со своими драконами. Вы даете какое-то определение ООП ...

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

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

Цитата (info21, 28.09.2010, 08:11) <{POST_SNAPBACK}>
А вам непременно хочется выпятить "объектность", потому что слово object зашито в ваш самодельный язык. Это тоже мне так кажется.

Ну, топик у нас такой. Что-то выпячивается. На самом деле, мы в наших курсах для школьников объекты используем редко. И всё больше на втором году обучения и далее. То есть, прекрасно понятна ваша фраза о том, что времени мало. И я с ней согласен. А топик мог бы получиться неплохим если бы мы как раз не говорили, что ООП - это ерунда, и бедные учителя ведутся, а говорили, как стоит попробовать.

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

Цитата (info21, 28.09.2010, 08:11) <{POST_SNAPBACK}>
А на самом деле понятия "запись" не только достаточно для преподавания первых навыков моделирования, но и просто вредно путать деткам (да и учителям) мозги умножением сущностей, вводя еще зачем-то и ключевое слово object (крайне неудачное как термин, т.к. "объект" слишком расхожее слово в обычном языке); "запись" в этом отношении даже выигрывает.

Ну, Вы не правы. Что касается нашей реализации Delphi, то в ней нет ключевого слова object - откуда Вы такое взяли? В старом Турбо-Паскале, да и в Зонноне есть, и я нахожу это не очень удачным решением. Но это всё - частности. А запись более ассоциируется просто с набором полей - никак не с набором методов.

Записи с голыми полями мне не нравится считать объектами вот чем. Когда в модуле много записей и методов записей - если методы находятся не внутри, то всё перемешивается. Капсула класса хороша, она позволяет говорить о чем-то как об отдельной сущности и ВОСПРИНИМАТЬ это так. Точка - это пара координат и набор из нескольких операций (ВНУТРИ ТОЧКИ). Отрезок - это пара точек и набор операций (ВНУТРИ отрезка). Многоугольник - это набор отрезков с набором операций (внутри). И потом - пожалуйста - создаём много точек, отрезков, многоугольников и решаем с ними задачи, используя наши любимые алгоритмы. В этом отношении операции ВНУТРИ делают объект АКТИВНЫМ: не мы делаем над объектом операции, а он сам умеет их делать, мы их лишь вызываем в нужное время. То есть, объект класса в отличие от записи - активный.

Вопрос лишь в том, чтобы СФОРМИРОВАТЬ у школьника это другое восприятие при изучении нового: не "какие тут алгоритмы используются", а "ИЗ КАКИХ ОБЪЕКТОВ ЗДЕСЬ ВСЁ СОСТОИТ" и только потом - а "КАКИЕ У ЭТИХ ОБЪЕКТОВ АЛГОРИТМЫ". Только и всего. И это - не технологическая сторона - это - другое восприятие мира. Копья ломать незачем.

Цитата (info21, 28.09.2010, 08:11) <{POST_SNAPBACK}>
Во-первых, никакая программа не пишется с нуля хотя бы потому, что использует библиотеки ввода-вывода (в случае блэкбоксовского "текста как интерфейса" так и весьма высокоуровневого).

Да, в блэкбоксе широко используется точечная нотация, и это хорошо. Уже для работы с вводом-выводом вы используете объекты. Я уверен, что Вы что-то такое говорите на занятиях со школьниками. Я не думаю, что прям на первом занятии Вы говорите про записи и абстракцию данных - объекты тут - самое понятное слово. Это из моего богатого опыта обучения. В Блэкбоксе также есть и всякие списки и прочие контейнеры. Это тоже объекты и классы - их надо использовать вместе, а порой и вместо простейших типа массивов.

Цитата (info21, 28.09.2010, 08:11) <{POST_SNAPBACK}>
Во-вторых, собственно общий школьный курс программирования (даже если речь о профиле) не должен ставить целью давать "правильное представление..." о технологической стороне разработки большого ПО.

Ещё раз. Я с этим согласен. Но объекты и классы - это не технологическая сторона. Вы же не говорите, что процедуры - это технологическая сторона.

Цитата (info21, 28.09.2010, 08:11) <{POST_SNAPBACK}>
Для того, чтобы "дать представление", я практикую заглядывание всей группой в реальные коды ББ, когда нужно что-нибудь проиллюстрировать (язык-то тот же самый).
Там есть практически всё, что может понадобиться для демонстрации культуры программирования на насточщем современном уровне искусства. Этого достаточно.

Да. это хорошая практика. Если коды, конечно, простые. Я обычно практикую это не на реальных кодах, а на специальной библиотеке с понятной реализацией функций.

Но - этого недостаточно. По крайней мере, для нас. Мышление в терминах объектов по нашему опыту позволяет проявить себя детям, мыслящим более гуманитарно. Создайте свои объекты - говорим мы им - и потом из этих объектов создайте свой маленький мир. И это работает - поверьте. Заодно и кто-то увлечется программированием, и алгоритмы какие-то изучит. Именно поэтому подход, основанный на Исполнителях, так востребован школьниками средних классов.

Цитата (info21, 28.09.2010, 08:11) <{POST_SNAPBACK}>
А переход к коллективной разработке (в будущем проф. обучении на уровне ун-та) отлично подготавливается внедрением в головы понятий модульности, интерфейсов и т.п.
Дай бог хотя бы это суметь сделать на самом базовом (но настоящем) уровне в ограничениях школы (или даже Байтика).

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

Цитата (Потопахин Виталий, 28.09.2010, 14:14) <{POST_SNAPBACK}>
ООП в обучении я как раз использую, но я стараюсь различать ситуации, где в этом есть смысл, а где нет. Что же касается определения ООП. У меня своего определения просто нет.

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

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