OberonCore

Имеется следующая проблема (или мнимая проблема), идея по её решению - да уже и решение начато.

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

Нежелание забивать мозги Views-ами раньше времени привело к след. решению.

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

Далее этот объект запускается командой "ШарГрафика.Открыть('МодульМоегоГрафическогоОбъекта')", создаётся и открывается вьюшка-шлюз, которая всё поведение перенаправляет на модуль. Даже была идея (сомнительная), что вьюшка может забирать глобальные переменные в себя и потом их подкладывать, чтоб на экране могло быть несколько экземпляров объекта (надо ли?).

Эта штука (в одном экземпляре) уже сейчас фурычит. Выкладываю архив - можно посмотреть.
Программист - Елена Шамардина.



Собственно, движок - модуль ШарГрафика, + там же 2 вспом. модуля. В Шар_этюды - два модуля-примера (Ханойские башни и Сапёр). Команды для запуска внизу исходников.

У меня имеются к уважаемым коллегам два вопроса для обсуждения:
1) А оно надо в принципе?
2) Конкретно ситуации, подобной моей, со студентами (3 курс СПО, т.е. аналог 1 курса ВУЗа) - стоит ли вводить промежуточный этап с такой графикой? Или дать шаблон вьюшки, не вдаваясь в подробности ООП? Сжуют, и пускай сразу привыкают?

Ещё такая мысль.

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

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

А потом позже гораздо - уже ООП как концепция. И как самому создавать свои типы данных.

Вроде здравая мысля?

Вроде обычно обучение именно так и построено...

Ну да. Вот это и не нравится, то что даётся это просто в силу "обычно" "Вот, научимся тыкать вот так вот".

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

IMHO тут хорошо бы подошел подход аля Оберон-1. Т.е. классы/записи это обычные типы и работа с ними ведется с обычным синтаксисом, без этих новомодной префиксной записи (obj.method) да связанных функций.

Т.е. тут даже в общем то и наследование не нужно. В простейшем случае.

А объяснить record'ы без наследования и на уровне Оберон-1/07, вполне думаю можно довольно быстро. + туда же type'ы -- работа с типами (создание).

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

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

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

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

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

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

Почему бы не делать так?



Ничего ужасного, правда?

Если нужно обрабатывать сообщения, то добвлятся HandleCtrlMsg - и WITH для RECORD. Хороший повод поупражняться с записями. И расширение тоже объяснить можно довольно рано, очень доступная штука.

Зато потом полностью к ООП переходить легче. Уже знакомые "камушки" в фундаменте есть.

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

Вот это ещё непонятно:

Объяснить, что этой строчкой мы говорим, что у нас есть своя разновидность графических объектов. Кои все являются расширением Views.View. И пока хватит

Так же как в Черепашке детям ещё задолго до переменных показывается частный шаблонный случай - счётчик VAR i: INTEGER для цикла FOR.

Собственно, не понятно, почему использование типов данных вызывает вопоросы. Какая разница, встроенные-элементарные они или реализованные?.
Простые имеют такие операции, а сложные - такие операции. На то они и сложные. А уж конструирование сложных типов - это потом.
ИМХО, как раз очень хорошо сначала научаем использовать реализованное.
А уж для повышения квалификации потом учим создавать.