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

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

Как учить школьников объектно-ориентированному программированию
Федор Ткачев ( Пользователь )
Цитата (Михалкович Станислав, 09.09.2010, 10:20) <{POST_SNAPBACK}>
Данная тема - продолжение обсуждения, возникшего здесь.

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

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

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

Никакого противопоставления ООП алгоритмам нет -- это просто ерунда, которая от многократного повторения нисколько не прибавляет в содержательности.

"Алгоритмы" -- это, так сказать, мелкозернистая структура программ, так называемое "программирование в малом".

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

ООП совершенно естественно вырастает в сложных программах, где также естественно возникают динамические структуры данных и раздельно разрабатываемые модули.
Именно это сделано очевидным в Обероне/Компонентном Паскале.

Поэтому, строго говоря, проблемы в том виде, в котором она тут сформулирована, нет.

Достаточно взять Оберон, спокойно научить алгоритмам, записям, спискам ... и ООП само собой подверстается у тех, кто дойдет до больших программ.
Александр Горячев ( Пользователь )
Цитата (info21, 09.09.2010, 11:02) <{POST_SNAPBACK}>
Никакого противопоставления ООП алгоритмам нет...

Но есть два вида анализа: процедурно-ориентированный и объектно-ориентированный.
Есть разница, создаете вы модель некоторой области в виде процессов или в виде объектов.
Это как бы взгляды с разных сторон на одни и те же вещи. Вещи не меняются от этого, но для каждого из этих подходов есть более подходящие средства реализации: процедурно-ориентированные и объектно-ориентированные ЯП.
Но основа различения этих подходов - два разных вида анализа. Результат - разные модели одной и той же области: процедурно- и объектно-ориентированные модели.
Мораль: учить школьников ООП, это далеко не только учить их синтаксису ОО ЯП, это прежде всего учить иному взгляду на моделируемую действительность.
В некотором смысле эти два взгляда на моделируемый мир тем не менее противопоставляются.
Они действительно разные.
Мне так кажется.
Федор Ткачев ( Пользователь )
Цитата (Александр Горячев, 09.09.2010, 14:59) <{POST_SNAPBACK}>
Но есть два вида анализа: процедурно-ориентированный и объектно-ориентированный.
Есть разница, создаете вы модель некоторой области в виде процессов или в виде объектов.

Это как бы взгляды с разных сторон на одни и те же вещи. ...

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

В сложной задаче отделить одно от другого невозможно.

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

Совершенно параллельные рассуждения можно проделать с набившим оскомину противопоставлением функционального программирования императивному:
Почему никто не обсуждает как проблему "процедурно-ориентированный" и "функционально-ориентированный" анализ?

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

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

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

*********

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

Можно вот что сказать:
Введение полиморфизма можно (в силу простоты) и, думаю, нужно вводить после элементарного введения записей-указателей -- без забурения в двусвязные списки, деревья и графы.
Это простые понятия, которые не требуют ни математики, ни сложной логики. Где-то 9-классникам должно быть доступно в смысле требований к мозгам.
Практически это, возможно, можно реализовать, если с 5-класса посадить их на Блэкбокс, чтобы к 8-му они основные циклы по последовательным данным могли делать.

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

Да, правильно и по-настоящему продуктивно заполнить провал 5-7-х классов -- большая задача. Ее правильное решение сильно перетряхнуло бы школьный программизм.
Роман Еннер ( Пользователь )
Пример цикла занятий со школьниками с "чистым" ООП: 1, 2, 3
Обратите внимание на дату публикации: 1999
Станислав Михалкович ( Пользователь )
Цитата (Roman Enner, 09.09.2010, 19:17) <{POST_SNAPBACK}>
Пример цикла занятий со школьниками с "чистым" ООП: 1, 2, 3
Обратите внимание на дату публикации: 1999

Ну да, в Смоллтоке это вообще использовалось с момента его возникновения.

Собственно, вопрос - нужно ли продолжать этот топик? Есть ли к нему интерес? Или - тему закрывать?
Федор Ткачев ( Пользователь )
Цитата (Михалкович Станислав, 09.09.2010, 19:23) <{POST_SNAPBACK}>
Собственно, вопрос - нужно ли продолжать этот топик? Есть ли к нему интерес? Или - тему закрывать?

А куда спешить?

Или вы не хотите иметь площадку, где с Оберонами невозможно соревноваться? :)
Станислав Михалкович ( Пользователь )
Цитата (info21, 09.09.2010, 19:33) <{POST_SNAPBACK}>
А куда спешить?

Или вы не хотите иметь площадку, где с Оберонами невозможно соревноваться? :)

Пока я не увидел обсуждения по сути. Приводите примеры кода на Обероне - будем сравнивать, будет всем интересно. И - нужны другие мнения и другие языки.
Федор Ткачев ( Пользователь )
Цитата (Михалкович Станислав, 09.09.2010, 20:34) <{POST_SNAPBACK}>
Пока я не увидел обсуждения по сути.
Это ваша, между прочим, проблема.
Станислав Михалкович ( Пользователь )
Цитата (Александр Горячев, 09.09.2010, 10:42) <{POST_SNAPBACK}>
1. ИМХО "правильное ООП" то, которое идет вслед ОО анализу и ОО проектированию.То есть, дети, научитесь объектно-ориентированно мыслить и реализовывать свои ОО замыслы на одном из ОО языков. (Раньше мы бы говорили: научитесь алгоритмически мыслить и реализовывать замыслы своих алгоритмов на одном из алгоритмических языков).

2. Тема "ООП для школьников" помимо "Как учить ООП школьников" может включать и "Зачем учить ООП школьников", "Надо ли изучение ООП делать магистральным направлением и вводить в ЕГЭ", "Является ли изучение ООА (анализа) значимым для массовой школы" и т.п.

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

Давайте я выскажу своё мнение.
1. Всё правильно. Но для школьников ООА и ООПроектирование либо сложно, либо должно быть подвергнуто хорошей методической обработке. Моё представление - начинать с простых классов, наполняя их поведением. То, зачем они понадобятся, станет ясно потом.
2. Зачем учить? Интуитивно понятно, что если ООП появилось везде, то учить надо. Даже Кушниренко в проекте имеет ключевое слово "исп" - это аналог слова class. Да, исполнитель - это класс. В ЕГЭ, на мой взгляд, - алгоритмы. Проверить задания с ОО подходом, по-моему, невозможно.
3. На мой взгляд, ОО для школьников не сильно увеличит код при правильном подходе, но сделает его понятнее для программ среднего размера. Разумеется, придется отказаться от сложных алгоритмов в пользу этих тем. Вопрос, готовы ли это сделать в школе.
Федор Ткачев ( Пользователь )
Цитата (Михалкович Станислав, 09.09.2010, 20:34) <{POST_SNAPBACK}>
Приводите примеры кода на Обероне

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

Отсюда следует простой вывод: интересные примеры будут великоваты (примеры уже тут приведенные имеют к ООП лишь поверхностное отношение).

Но раз дискуссия достигла уровня крутизны "программирования-в-большом", то серьезным участникам лучше для начала пробежать по двум документам:

1. для ориентира: Отличия Компонентного Паскаля от старого:
http://www.inr.ac.ru/~info21/cpascal/otliq...p_ot_pascal.htm
где в конце даны пунктики, касающиеся собственно ООП:

Цитата
• Расширенное переопределение типов
Типы записей (указательные типы) могут переопределяться, обеспечивая таким образом полиморфизм. Полиморфизм — одно из главных средств объектно-ориентированного программирования.

• Методы
Процедуры могут быть связаны с типами записей (указательными типами), таким образом обеспечивая позднее связывание. Позднее связывание является одним из главных средств объектно-ориентированного программирования. Такие процедуры еще называются методами.
.....
• Атрибуты записей
По умолчанию записи не могут быть переопределены (are non-extensible), но могут быть помечены как EXTENSIBLE, ABSTRACT или LIMITED.

• Атрибуты методов
Методы не могут быть переопределены по умолчанию, но могут быть помечены как EXTENSIBLE, ABSTRACT или EMTPY. Вновь вводимые методы должны быть помечены как NEW.


2. А детали определения с короткими фрагментами-примерами синтаксиса даны в соответственных местах достаточно короткого Сообщения о языке:
http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm

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