OberonCore
https://forum.oberoncore.ru/

Графика без ООП - пример, и стоит ли овчинка выделки?
https://forum.oberoncore.ru/viewtopic.php?f=7&t=1782
Страница 1 из 1

Автор:  Илья Ермаков [ Воскресенье, 23 Август, 2009 13:25 ]
Заголовок сообщения:  Графика без ООП - пример, и стоит ли овчинка выделки?

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

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

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

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

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

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

Вложение:
Shar.7z [15.21 КБ]
Скачиваний: 449


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

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

Автор:  Илья Ермаков [ Воскресенье, 23 Август, 2009 13:29 ]
Заголовок сообщения:  Re: Графика без ООП - пример, и стоит ли овчинка выделки?

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

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

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

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

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

Автор:  Alexey_Donskoy [ Воскресенье, 23 Август, 2009 13:39 ]
Заголовок сообщения:  Re: Графика без ООП - пример, и стоит ли овчинка выделки?

Илья Ермаков писал(а):
"как пользоваться объектами". Кем-то уже сделанными. Давать как разновидность типов данных. Вот, типа, с переменной такого типа вот такие операции бывают :)

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

Автор:  Илья Ермаков [ Воскресенье, 23 Август, 2009 13:57 ]
Заголовок сообщения:  Re: Графика без ООП - пример, и стоит ли овчинка выделки?

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

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

Автор:  Alexey Veselovsky [ Воскресенье, 23 Август, 2009 14:38 ]
Заголовок сообщения:  Re: Графика без ООП - пример, и стоит ли овчинка выделки?

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

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

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

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

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

Автор:  Илья Ермаков [ Воскресенье, 23 Август, 2009 14:40 ]
Заголовок сообщения:  Re: Графика без ООП - пример, и стоит ли овчинка выделки?

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

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

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

Автор:  Илья Ермаков [ Воскресенье, 23 Август, 2009 14:53 ]
Заголовок сообщения:  Re: Графика без ООП - пример, и стоит ли овчинка выделки?

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

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

Код:
MODULE МояГрафика;

  ..
  VAR
  ..
 
  (* НШ - Начало данного преподавателем шаблона *)
  TYPE
      View = POINTER TO RECORD (Views.View) END;
    - никакого состояния объект не хранит. Он использует глобальное состояние модуля.
  (* КШ *)


  PROCEDURE ...
  PROCEDURE ...

  PROCEDURE (v: View) Restore (f: View.Frame; l, t, r, b: INTEGER);
    - здесь из непонятного пока - только (v: View).
  ...
  BEGIN
  - здесь понятно, как рисовать, обращаясь к процедурам f. Всё это доступно и легкообъяснимо. Особенно, если уже систематически вводим "пользование готовыми объектами"
  END Restore;

  PROCEDURE Открыть*;
    VAR v: Views.View;
  BEGIN
     NEW(v);
     Views.OpenAux(v, "Графическое окошко")
  END Открыть;

END МояГрафика.



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

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

Автор:  Илья Ермаков [ Воскресенье, 23 Август, 2009 14:55 ]
Заголовок сообщения:  Re: Графика без ООП - пример, и стоит ли овчинка выделки?

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

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

Автор:  Alexey Veselovsky [ Воскресенье, 23 Август, 2009 15:04 ]
Заголовок сообщения:  Re: Графика без ООП - пример, и стоит ли овчинка выделки?

Вот это ещё непонятно:
Цитата:
View = POINTER TO RECORD (Views.View) END;

Автор:  Илья Ермаков [ Воскресенье, 23 Август, 2009 15:17 ]
Заголовок сообщения:  Re: Графика без ООП - пример, и стоит ли овчинка выделки?

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

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

Автор:  Валерий Лаптев [ Четверг, 27 Август, 2009 11:16 ]
Заголовок сообщения:  Re: Графика без ООП - пример, и стоит ли овчинка выделки?

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

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/