Методические указания Ухта 2006 удк 681 06(076) г 23
| Вид материала | Методические указания |
- Методические указания Санкт Петербург 2006 удк 947, 435.39kb.
- Методические указания Санкт-Петербург 2011 удк 541. 1(076., 289.58kb.
- Методические указания по выполнению и оформлению курсовой работы по дисциплине «бухгалтерский, 1337.13kb.
- Методические указания Новосибирск 2003 удк ббк т3(2), 342.37kb.
- Методические указания Санкт-Петербург 2009 удк 947, 1006.45kb.
- Удк 340. 6+681. 327+681 015 Д. В. Ландэ, В. Н. Фурашев, 450.24kb.
- Удк 681 053: 681. 32: 007, 134.3kb.
- Администрация, 29.13kb.
- Методические указания Санкт-Петербург 2010 удк 947, 1278.52kb.
- Методические указания для студентов и аспирантов Сыктывкар 2006, 119.19kb.
Федеральное агентство по образованию
Ухтинский государственный технический университет
Технология программирования
Курсовой проект
Методические указания
Ухта 2006
УДК 681.3.06(076)
Г 23
Гатин, Г.Н. Технология программирования. Курсовой проект [Текст]: Методические указания / Г.Н. Гатин. – Ухта: УГТУ, 2006. – 57 с.: ил.
Методические указания предназначены для студентов дневного и заочного обучения по направлению 654700 «Информационные системы» (специальности 230201 «Информационные системы и технологии») изучающих дисциплину «Технология программирования»
Содержание указаний соответствует рабочей учебной программе.
Методические указания рассмотрены и одобрены кафедрой ИСТ пр. № 4 от 11.11.05 г. и предложены для издания Советом направления 654700 от 11.11.05 г. пр. № 3.
Рецензент старший преподаватель кафедры ИСТ Ф.В.Маракасов
Редактор Л.В. Тебердеева
План 2005 г., позиция 62.
Подписано в печать 28.12.2005 г. Компьютерный набор.
Объем 57 с. Тираж 70 экз. Заказ № 196.
© Ухтинский государственный технический университет, 2005
169300, г. Ухта, ул. Первомайская,13.
Отдел оперативной полиграфии УГТУ
169300, г. Ухта, ул. Октябрьская,13.
Содержание
Введение 5
Простой класс: MyString 8
Постановка 9
Выбор способа представления абстрактных типов 11
Реализация конструкторов 14
Реализация “простых” методов 17
Реализация необходимых функций 18
Класс Address 28
Список литературы 39
Приложение 1. Текст заголовка класса MyString (файл MyString.h) 40
Приложение 2. Тексты членов – функций класса MyString (файл MyString.cpp) 42
Приложение 3. Текст тестирующей класс MyString программы 46
Приложение 4. Текст заголовка класса Address (файл Address.h) 49
Приложение 5. Тексты членов – функций класса Address (файл Address.cpp) 54
Приложение 6. Текст тестирующей класс Address программы 56
Введение
Обычно, студент второго курса специальности ИСТ знает Pascal, который он осваивал в парадигме процедурного программирования. Алгоримизация, выделение действий, рассмотрение процедуры решения задачи, как последовательности действий, естественным образом воспринимается студентами. Именно так мы поступаем, выполняя какую - либо работу. Да и в школьной математике, и в инженерных курсах математики не особенно заостряется внимание на данных и их типах. Поэтому, когда студент сталкивается с объектно-ориентированным подходом в программировании (везде далее объектно-ориентированное программирование - ООП), он испытывает определённые трудности, связанные с перестроением собственного мышления. С одной стороны, человек воспринимает мир как множество объектов, с которыми можно выполнять определённые действия, с другой стороны, выполняя работу человек, чаще всего, достаточно сильно абстрагируется от данных. Точнее: стадия определения данных и их типов прошла в глубоком детстве. Большинство уже знает, что такое стол, стул и т.п. Таким образом, стадия определения объектов, как таковых, присутствует неявным образом, и большинство не осознаёт её.
Однако использование ООП требует сознательного использование стадии определения объектов и их типов. Студенту приходится снова "вернуться в детство": сначала определить, какие объекты имеются в наличии, как их представить в машине, затем понять какие действия могут совершать сами объекты и какие действия можно выполнять с объектами и только потом, при реализации методов класса, выполнять процедурную абстракцию. Более того, выполняемая процедурная абстракция вовсе не похожа на обычную – используемую при алгоритмическом подходе. Программы, реализующие методы, часто очень короткие и возникает законный вопрос о необходимости наличия этих программ, не проще ли отказаться, например, от инкапсуляции, тогда все методы Get и Set не понадобятся. Внимание сосредотачивается на совершенно обыденных вещах - операциях. Выясняется, что даже обычное присвоение ("="), необходимо реализовывать самому и т.д.
Всё это, вместе взятое, приводит нас к выводу, что ООП сложнее процедурного программирования. Гради Буч [1] подчёркивает это, ссылаясь на Ф. Брукса [2]. Однако он же указывает, что сложность эта присуща программированию вообще, а не только ООП, и от этой сложности не избавиться в принципе. С другой стороны, ООП позволяет [1] быстрее реализовать, лучше отладить, легче сопровождать программные комплексы. Кроме того, эти программные комплексы могут быть сложнее и больше программ, реализуемых методом процедурной абстракции. Другими словами: ООП существенно увеличивает производительность труда программиста.
Именно последнее переводит программирование в русло ООП. Нет, процедурное программирование никуда не денется - ООП "стоит на его плечах", но грамотный программист обязан легко ориентироваться в различных технологиях. Он должен знать как достоинства этих технологий, так и их недостатки и ограничения. Знания эти приведут к пониманию ООП, а понимание ООП приведёт к более глубокому пониманию программирования, сути программирования как такового.
Следует различать собственно объектно-ориентированное программирование и программирование на основе абстрактных типов. Хотя, для большинства программистов-практиков это чисто теоретическое различие. Всё дело в том, что чаще всего программисту попадает постановка задачи, выполненной в стиле процедурной декомпозиции, что естественно, поскольку постановку делает не программист. Сроки на реализацию постановки не предполагают ещё и объектно-ориентированной декомпозиции. Поэтому программист-практик просто использует классы для создания собственных типов и объектов, используя полученные абстракции при решении задачи. Чаще всего эти классы весьма конкретны и применяются только при решении поставленной задачи. Программист стремится решить поставленную задачу, не особенно задумываясь о степени общности получаемых типов. И хотя, косвенно программист всё-таки выполняет стихийную объектно-ориентированную декомпозицию задачи, степень общности получаемого решения, возможности повторного использования классов весьма ограниченны.
Наши текущие задачи значительно скромнее. Заметим, что и ООП, и программирование на основе абстрактных типов требует умения писать собственные классы и навыков использования этих классов. Технологию создания класса продемонстрируем на примере двух классов: одного простого – тип MyString - "моя строка" и другого, более абстрактного класса - Address - "адрес". Все примеры выполнены на языке C++ в C++Builder 6 под Windows. Во-первых, C++ стал фактическим стандартом в программировании и, с нашей точки зрения, программист просто обязан знать C++. Во-вторых, технология ООП наиболее последовательно проводится именно в C++.
Выбор среды программирования менее категоричен. Принципиально вы можете "прогнать" эти примеры в любом трансляторе C++ (Borland 5.02, например), изменив тестирующую программу (см. ниже), но там вы будете лишены преимуществ визуального программирования. Выбор C++Builder обусловлен тем, что эта среда значительно естественней Visual C++, гораздо проще в освоении, не требует ничего кроме знания собственно C++ и начальных знаний по визуальному программированию.