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

Информатика и преподавание ООП

Серж Андреев ( Пользователь )
Цитата (DIzer, 30.06.2011, 19:44) <{POST_SNAPBACK}>
Это системы, которые состоят из набора компонент , каждый из которых сам по себе является совокупностью атрибутов и действий над ними...


А я уж было подумал про ИИ (AI)...
Дмитрий Изергин ( Пользователь )
Да, речь идет об обычном, достаточно сложном, конечно- пользовательском приложении (EUA) - используемый мною составной термин ( :) ) - всего навсего краткая характеристика того чем оно является в общем случае , на этапах разработки, развития, поддержки. Соответствующие , курсы (по специальностям "Информатика" и близким к ней) называются у нас приблизительно так -"Архитектура современных приложений", "Разработка и проектирование конечно-пользовательских приложений". Насколько я знаю, подобные курсы есть во всех "классических" вузах общего плана.
Серж Андреев ( Пользователь )
Цитата (DIzer, 05.07.2011, 10:52) <{POST_SNAPBACK}>
Да, речь идет об обычном, достаточно сложном, конечно- пользовательском приложении (EUA) - используемый мною составной термин ( :) ) - всего навсего краткая характеристика того чем оно является в общем случае , на этапах разработки, развития, поддержки. Соответствующие , курсы (по специальностям "Информатика" и близким к ней) называются у нас приблизительно так -"Архитектура современных приложений", "Разработка и проектирование конечно-пользовательских приложений". Насколько я знаю, подобные курсы есть во всех "классических" вузах общего плана.


Просто я никогда не встречался с таким "вычурным" термином. На практике часто подобное называют (и, как не кажется, совершенно справедливо и правильно) GUI - Graphical user interface. Я вообще против какого бы то ни было усложнения простых понятий. Как я понял, речь шла именно о многокомпонентном построении графического интерфейса пользователя на основе объектной модели, где разнообразные элементы интерфейса являются многочисленными потомками одного или нескольких базовых классов (объектов).
Дмитрий Изергин ( Пользователь )
Нет, речь шла об описании (проектировании, программировании, сопровождении) систем в которые эти компоненты входят как подсистемы, точнее - о том, что таких задач нет у студентов 1 курса ( у нас - точно).
Евгений Багоцкий ( Пользователь )
Да, какой терминологии не придерживаться, можно называть многокомпонентные эволюционные системы, можно еще как. Да, слыщал и участвовал в подобном на основе технологий COM и ActiveX или просто технологий написания Delphi или Builder-компонент и их использовании
Но в этой теме я хотел остановиться на особенностях технологий разработки классов. Об особенностях их проектирования на разных языках о событиях как элемент класса и учебных примерах (несложных) подобных разработок. О способах хранения объектов таких классов. - Мне кажется все это, несмотря на обилие литературы и программистских сайтов изложено не достаточно ясно и в таком виде, конечно не очень пригодно для преподавания даже в избранных школах
Станислав Михалкович ( Пользователь )
Цитата (Евгений Багоцкий, 05.07.2011, 14:51) <{POST_SNAPBACK}>
Да, какой терминологии не придерживаться, можно называть многокомпонентные эволюционные системы, можно еще как.

Только вот какое отношение имеют многокомпонентные эволюционирующие системы к преподаванию ООП и простым примерам его использования - ума не приложу.

Хотя словосочетание круто звучит.
Серж Андреев ( Пользователь )
Цитата (Евгений Багоцкий, 05.07.2011, 15:51) <{POST_SNAPBACK}>
Но в этой теме я хотел остановиться на особенностях технологий разработки классов. Об особенностях их проектирования на разных языках о событиях как элемент класса и учебных примерах (несложных) подобных разработок. О способах хранения объектов таких классов. - Мне кажется все это, несмотря на обилие литературы и программистских сайтов изложено не достаточно ясно и в таком виде, конечно не очень пригодно для преподавания даже в избранных школах


А мне кажется, что там все достаточно просто и понятно. Есть некоторый базовый класс, имеющий свойства и методы. У класса обычно есть коструктор и деструктор, которые, соответственно, инициализируют или удаляют свойства объекта (выделяют/освобождают память, вызывают конструкторы/деструкторы других объектов, которые являются его свойтвами). Для полиморфизма используются виртуальные методы, которые определяются для объекта базового типа. Для наследования есть возможность вызвать код предка (inherited).

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

Вообще, создавать разнообразные объекты в принципе интересно. Например, создать объект, который ведет себя определенным образом. Если учитель создаст базовый класс, который будет способен отображать объект в той или иной среде, то ученик на его основе сможет смоделировать достаточно многое. И когда у ученика получится сделать простое, то, возможно, у него родится интерес к более сложному, например, к построению базового класса. Все зависит от того, как вы подадите материал ученикам.
Евгений Багоцкий ( Пользователь )
Цитата (Серж Андреев, 08.07.2011, 16:36) <{POST_SNAPBACK}>
А мне кажется, что там все достаточно просто и понятно. Есть некоторый базовый класс, имеющий свойства и методы. У класса обычно есть коструктор и деструктор, которые, соответственно, инициализируют или удаляют свойства объекта (выделяют/освобождают память, вызывают конструкторы/деструкторы других объектов, которые являются его свойтвами). Для полиморфизма используются виртуальные методы, которые определяются для объекта базового типа. Для наследования есть возможность вызвать код предка (inherited).

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

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

Да наследование-мощная вещь но стоит ли идти по проторенной Дельфийской дорожке? - обучать создавать компоненты - да ,красиво смотрятся и пр. На эту тему-многолетний опыт - насоздавали (чтобы не соврать) тысячи компонент, из которых может 2-5% как-то применяются, остальные с успехом забыты
А если по другому взглянуть на вещи? Объект класса - носитель некоей информации. Отличается от структуры наличием методов. И рассмотрите примеры когда по модели надо создавать и хранить множество таких объектов. Какой вы путь выберете - традиционный -запихнуть все в файл и базу данных (то что называлось даталогическая модель) и доставать наборы по запросу. А попробуйте обосновать когда и для каких задач все же преимущество модели будет именно от создания объектов класса. Сразу тогда возникнут дополнительные вопросы о хранении таких объектов в БД. Ведь методики проектирования на основе UML очень сильно отличаются от даталогической модели. Надо дать почувствовать разницу .
В этом по-моему и есть суть проектирования - тонко чувствовать модель, не скатываться к упрощенке.
Уметь пользоваться ООП - это не только владение приемами написания класса а еще и умение разработать инфологическую модель, даже не на языке а пусть хотя бы на BPWin. Архитектор, CASE-аналитик (помните в 90-е было повальное увлечение CASE) мне кажется не менее востребован чем программист.
Вульгарное представление об информатике - это мешанина всяких технологий и направлений - от теоретической информатики (кодироваине и пр) до обзорно-классификационной, разных практических навыков- изгот. презентаций , рисование рис, игры с Flash...все бегом и по верхам...
И если в информатике нельзя объять необъятного, то мне кажется Case -проектирование (технологии работы с данными)ближе к сути информатики чем программирование. Пусть ребята учатся программировать, но это не информатика.
Станислав Михалкович ( Пользователь )
Цитата (Евгений Багоцкий, 08.07.2011, 21:23) <{POST_SNAPBACK}>
Пусть ребята учатся программировать, но это не информатика.

Правильно. Программирование - это средство решения задач информатики.


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

У Ученика важными являются такие-то свойства и методы, у учителя - другие. Выделим общие. Нарисуем на картинке.

Ученики объединяются в Класс. Нарисуем на картинке.

Учитель имеет Журнал. Журнал связан с Классом. Журнал содержит Оценки. Нарисуем на картинке.

Еще есть Урок, который связан с Предметом, по Предмету могут выставляться Оценки в Журнале.

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

После построения минимального каркаса системы количество алгоритмов, которое можно впихнуть в запросы, безгранично. Типа определить ученика с максимальным средним баллом в каждом классе.

При должном изложении в учебнике основ графического языка (малое подмножество UML) и языка описания классов средний учитель вполне справится с задачей. Нужна лишь политическая воля и понимание того, что это нужно. Пока в этой ветке подавляющее большинство отписывалось, говоря, что это не нужно в современной слабой школе и даже (!) в ВУЗе, т.к. студенты очень слабы.

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

То есть, еще долгое время в школьном программировании будут преподаваться алгоритмики, алгоритмы, а для особо одаренных - алгоритмища. Для решения задач будут использоваться примитивнейшие структуры данных типа массивов и будет эскалироваться мнение, что использование чего-то более высокоуровневого - зло. Кроме того, ввиду мнимой сложности злом будут считаться и элементы проектирования.
Олег Деревенец ( Пользователь )
Цитата (Михалкович Станислав, 09.07.2011, 10:18) <{POST_SNAPBACK}>
По поводу ООП. Мне кажется, можно начать с попытки простого описания какой-нибудь системы...

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


Осмысления не произошло и не произойдет, как не происходит ничего само собой. Вы, Станислав, высказываете интересные, дельные мысли по методике преподавания ООП. Мне, по крайней мере, они нравятся. Чувствую, что Вам по силам смастерить какой-то учебный материал на их основе. У Вас получится, надо работать. Не ждать же нам, что кто-то сверху что-то решит!
Основной массе учеников такой курс вряд ли потребуется, но для тех, кто всерьез нацелен на программирование, это будет находка, что залатает зияющую прореху в их нынешнем образовании.


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