Не ходите дети в Африку гулять
Недавно я был на Всероссийском съезде учителей информатики (http://it.teacher.msu.ru/). Без всякого сомнения, это было очень полезное мероприятие. Иногда начинаешь читать хабро-образные форумы на тему "как правильно учить детей программированию", и мозг переходит в состояние тихой эйфории от осознания содержательности дискуссии и бронебойности аргументов. Однако это не позволяет полностью устранить сомнения на тему "а сами-то холиварщики работают учителями?" На съезде мне удалось побыть среди учителей, послушать множество интересных докладов, ознакомиться с широким спектром именно профессиональных мнений, а также высказать ряд собственных соображений.
Только не подумайте, что сделана попытка противопоставить автора и учителей информатики, т.к. ваш покорный слуга в определенный период времени (нет, учителем не работалJ) обучал детей объектно-ориентированному программированию. Весёлое занятие - на голой консоли рассказывать ребятне про полиморфизм в С++! Это к тому, что я был абсолютно в теме.
Чего там только не было! И обучение COM-технологии в 8 классе, и игра в интеллектуально-алгоритмические паззлы, и виртуальные миры… аж завидно стало. Что выпало на долю нашего поколения в школьные годы? Программирование в кодах на MK-61? Извините, увлёкся. Зато сразу вспомнил, что такое "стек".
Одной из главных озвученных проблем, касающихся методологии преподавания и применимости языков программирования для обучения в школе, оказалось следующее: "Как нам преподавать школьникам ООП?" или даже в более жесткой постановке "Ни в коем случае нельзя преподавать ООП в школе!".
Мотивация
Не буду пересказывать смысл понятия "мотивация". На бытовом уровне все и так понимают, а в дебри психологии лезть неэффективно. Уж очень там много различных теорий и подходов. Но единственно близким мне методом "мотивирования" школьников является дать возможность сделать что-то. Нет, не что-то, а вполне конкретную "поделку".
У профессиональных педагогов есть даже такой термин "проектное обучение". Представить себе это легко, если подумать о курсовом или дипломном проекте. Прошу прощения, если у кого-то в памяти возникли негативные воспоминания.
Учителю информатики современные дети задают три вопроса:
- Вы научите нас взламывать сайты?
- Вы научите нас писать компьютерные игры?
- Сколько вы получаете?
Хотя бы один из этих трех вопросов нужно ответить прямо и максимально позитивно, чтобы сохранить авторитет. Я знаю нужный ответ на один из этих вопросов, но он связан с ООП.
Объектно-ориентированное мышление
Беглый взгляд на информацию по ссылкам "инкапсуляция" не вызвал чувство восторга, характерного в случае прочтения диспутов "какой язык программирования круче". Вот бы такую энергию - да в мирное русло! Вообще, читая объяснение ООП (в целом) и инкапсуляции (в частности), складывается впечатление, что нас "за уши тянут", а мы - упираемся. Нас уговаривают, а мы отказываемся. Нам показывают, что инкапсуляция полезна, а мы не доверяем. Нам нужны аргументы и факты.
Нам не нужны аргументы. Достаточно фактов.
Мы воспринимаем окружающий мир образами. Восприятие - биологическая функция. Формирование целостного образа объекта. Природа создала наш мозг объектно-ориентированным. Нас не надо учить объектно-ориентированному анализу. Нам только нужно показать графическую нотацию. Или рассказать, как использовать объектно-ориентированный язык для написания программ.
Инкапсуляция
Инкапсуляция - первая парадигма объектно-ориентированного подхода. Парадигма - совокупность идей и понятий, определяющих стиль программирования. Объектно-ориентированный язык (например, Delphi) позволяет использовать соответствующие парадигмы, т.е. писать в объектно-ориентированном стиле.
Можно уподобить парадигмы программирования правилам спортивной игры. Совокупность идей и понятий, определяющих стиль игры. Мяч, ворота, игровое поле. Или: ворота, клюшка, шайба, коньки. Класс, объект, поле, метод, свойство. Таковы понятия объектно-ориентированной игры мозга.
Я иду в школу. Я (объект) иду (вызов метода) в школу (параметр метода, другой объект).
Гоблин нападает на эльфа. Гоблин (объект) нападает (метод) на эльфа (параметр метода, другой объект).
Мы воспринимаем образы, мы мыслим образами, мы разговариваем образами. Что тут нужно объяснять?
Инкапсуляция - "в капсуле". В оболочке. Нет более бесхозных переменных и функций. Они находятся внутри какого-нибудь класса. Класс - та самая оболочка. Класс в программном коде отражает образ и содержит в себе составляющие объекта. Проекция образа в мозге на программный код.
Код на Delphi скажет лучше длинных предложений.
Goblin1.Attack(Elf1); // Гоблин № 1 атакует Эльфа №1
А что такое "гоблин"?
Из чего формируется образ "гоблина"? Сила атаки, здоровье, возможность перемещаться, возможность атаковать другие объекты. Две переменные и две функции, объединенные общим понятием. Что такое: объединены общим понятием ? С точки зрения написания объектно-ориентированного кода эти две переменные и две функции объявлены внутри класса.
В нашей голове нет бесхозных переменных (неких ячеек памяти с именем, способных хранить значение). Мы не думаем в категориях "функция" - набор действий, выполняемых над абстрактным набором входных параметров.
Мышление образами, программирование образами (классами и объектами) - более естественно, чем оперирование переменными и функциями. Нас так задумала природа.
А что такое "сокрытие"?
Странно, но тут единого мнения нет. Порой складывается впечатление, что сокрытие и есть инкапсуляция, а инкапсуляция нужна для сокрытия переменных или методов класса. Наверное, логично (исходя из значения слов) считать следующим образом.
Инкапсуляция - принцип программирования, когда переменные и функции (процедуры) помещаются в класс. Класс - ограниченная область программного кода, имеющая название, в которую помещены переменные и функции (процедуры). А смысл делать класс? Смысл только в том, чтобы максимально приблизить структуру программного кода к тем образам, которые у нас в голове. Как ни странно - для того, чтобы было проще программировать. Естественнее. Удобнее. Приятнее. Не надо ходить на руках или скакать на одной ноге. Делаем так, как нас задумала природа.
Поместили мы что-то в оболочку. В нашем случае переменные и функции (процедуры). Но часть из них нужно закрыть, чтобы не испортить работу. В автомобиле есть двигатель. Снаружи он закрыт капотом, а от салона изолирован различными панелями. Чтобы грязь не попадала. И чтобы пальцы в него не совали. Для блага же пассажиров. Двигатель находится в своем закрытом отсеке. А "наружу" выведены лишь кнопки, рычаги и педали. Их можно (и безопасно) трогать. С их помощью мы управляем автомобилем. Также и с классами. Часть переменных и функций скрываются во имя безопасности. Другая часть - специально делается доступной, открытой. Сокрытие - изоляция содержимого класса от внешнего мира (остального программного кода). Программист (создатель) класса сам должен решить, что спрятать для соблюдения безопасности, а что "вывести наружу" в качестве органов управления. Для Delphi часть содержимого класса прячется в разделе private (закрытый раздел), а часть - располагается под директивой public (открытый раздел).
Интерфейс
Интерфейс - открытая, доступная часть содержимого класса. Зачем часть содержимого класса открывается (делается доступной)? Чтобы с объектом можно было взаимодействовать. Взаимодействие с автомобилем выполняется посредством его интерфейса - руль, педали, рычаги, кнопки. Если неправильным образом спроектировать интерфейс, класс не будет работать. Если убрать педаль газа, то автомобиль не сдвинется с места. Однако выводить выхлопную трубу в салон тоже не стоит. Подобные рассуждения выглядят тривиально. Но это лишний раз доказывает всю тривиальность (в позитивном значении) сокрытия в рамках объектно-ориентированного подхода.
Смысл учить ООП
Здесь главное понять, что ООП - не цель обучения. Наверное, неправильно говорить "а теперь, дети, мы выучим ООП". Возвращаясь к теме "мотивации" и "программированию игр", следует отметить, что такая следующая цепочка рассуждений вполне эффективна:
"мотивация -> программирование игр -> изучение ООП". Таким образом, мы изучаем ООП для того, чтобы получить возможность программировать сложные задачи.
Мы думаем объектно-ориентированным образом, мы программируем объектно-ориентированным образом. Поэтому никогда другие языки программирования (логические, функциональные, например) не будут настолько естественными и, следовательно, широко распространенными. Изучать подобные языки аналогично познанию санскрита или арамейского.
Delphi навсегда
И вот тут сложно переоценить эффективность Delphi как языка программирования для преподавания информатики в школе. Естественно, на "драйве", на личностных качествах учителя можно пройти этап "переменных, циклов, массивов и функций". Но в какой-то момент нужно будет начать "доставать кроликов из шапки". И тут плавно классический Pascal начинает обрастать объектно-ориентированными возможностями, превращаясь в Delphi. Это касается и принципа визуального программирования, и возможностями использовать объектно-ориентированные парадигмы. Наверное, нет другой такой же эффективной среды обучения.
А то, что Delphi - профессиональный инструмент разработки коммерчески успешных приложений - дополнительный мотив. "Дети, мы работаем в профессиональной среде программирования":
http://www.embarcadero.com/rad-in-action/application-showcase