Тема 1. Классы

Лабораторная работа 1

Разработка и использование класса Планета.

Цели работы:

- создание программных объектов пользовательских типов с использованием классов;

- создание многофайловых проектов (заголовочный файл для класса, файл с определением методов класса и файл с main-функцией);

- ввод-вывод объектов пользовательских типов в файл;

- перегрузка операций потокового ввода-вывода (<< , >>), операций отношения (<,==) для пользовательских типов;

- перегрузка конструктора копирования и операции присваивания;

- сортировка массивов объектов пользовательских типов, хранящихся в файле, с использованием перегруженных операций.

Время выполнения работы – 12 час. (3 занятия).

Задание.

Лабораторная работа 1.1

1. Ознакомиться с приведенным ниже материалом (Введение и Пример 1).

2. Разработать класс «Планета» для планет солнечной системы (4 характеристики планет разного типа приведены в Приложении 1).Имя планеты должно иметь тип char*.

3. Создать многофайловый проект и отладить программу, которая создает один объект класса «Планета» и выводит значения его полей на экран. (Пример программы приведен в Приложении 3).

4. Добавить в программу ввод – вывод объекта класса «Планета» в текстовый файл.

Лабораторная работа 1.2 (продолжение лабораторной работы 1)

2.1. Ознакомиться с содержанием раздела «Перегрузка операций» и выполнить приведенный в нем пример 2.

2.2. Создать текстовый файл (в блокноте) с данными о планетах солнечной системы и сохранить его в папке проекта. Первоначально, для отладки, введите две записи.

2.3. Перегрузить операцию “ >> “ для класса «Планета» и istream и прочитать данные о планетах из файла в массив «Солнечная система» из объектов класса «Планета».

2.4. Перегрузить операцию “ << “ для классов «Планета» и ostream и вывести на экран данные из массива.

2.5. Перегрузить конструктор копирования, деструктор и оператор присваивания.

2.6. Вставьте в конструкторы и деструктор печать типа «Создание (Удаление) ID n » , где n - номер объекта, для которого они вызываются. (Для реализации этого пункта задания разберите и выполните пример из Приложения 2.).

Лабораторная работа 1.3 (продолжение лабораторной работы 1)

3.1. Перегрузить операции сравнения “ < и ==” для класса «Планета», использовав для этого значение одного из полей.

3.2. Отсортировать массив планет солнечной системы, хранящийся в файле, с использованием перегруженных операций.

3.3. Организовать интерфейс пользователя с программой в виде меню, позволяющего выполнять следующие действия:

- чтение БД «Солнечная система» из файла;

- запись БД «Солнечная система» в файл;

- сортировка БД;

- редактирование БД;

• вывод БД на экран.

3.4. Выполните следующий эксперимент.

• Измените функцию сравнения так, чтобы параметры передавались по значению (а не по ссылке). Выполните сортировку и определите максимальное число объектов типа Planeta в памяти и как изменился вызов конструктора копирования. Объясните результат.

• Исключите (временно) из класса Planeta деструктор. Выполните несколько раз сортировку и определите максимальное число объектов типа Planeta в памяти. Объясните результат.

• Восстановите исходную программу (передача параметров по ссылке и наличие деструктора).

Требования к отчету

1. По работам 1.1, 1.2 и 1.3 составляется один отчет.

2. Отчет должен содержать следующие разделы:

• «Постановка задачи», в котором на основании задания уточняются задачи, для решения которых предполагается использовать разрабатываемый класс.

• «Разработка интерфейса класса», в котором описываются и обосновываются состав полей и методов класса, прототипы методов. Интерфейс класса должен обеспечить решение всех предполагаемых задач. При разработке интерфейса класса надо руководствоваться принципом: второстепенные детали или детали реализации должны быть упрятаны (инкапсулированы) внутрь класса.

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

• «Анализ результатов», в котором приводятся разработка контрольных примеров, распечатки результатов выполнения программой контрольных примеров и анализ результатов.

Введение

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

Существенная черта промышленной программы — ее сложность: один разработчик не в состоянии охватить все аспекты системы, поэтому в ее создании участвует целый коллектив. Следовательно, к первичной сложности самой задачи, выте­кающей из предметной области, добавляется управление процессом разработки с учетом необходимости координации действий в команде разработчиков.

Так как сложные системы разрабатываются в расчете на длительную эксплуатацию, то появляются еще две проблемы: сопровождение системы (устранение обнару­женных ошибок) и ее модификация, поскольку у заказчика постоянно появляются новые требования и пожелания. Иногда затраты на сопровождение и модифика­цию сопоставимы с затратами на собственно разработку системы.

Способ управления сложными системами был известен еще в древности — разделяй и властвуй. То есть выход — в декомпозиции системы на все меньшие и меньшие подсистемы, каждую из которых можно совершенствовать независимо.

В рамках структурного подхода декомпозиция понимается как разбиение алгорит­ма, когда каждый из модулей системы выполняет один из этапов общего процес­са.

Объектно-ориентированная программа строится в терминах объектов (типа «класс») и их взаимосвязей, а декомпозиция представляет собой иерархию классов, при которой потомки наследуют свойства своих предков, могут их изменять и добавлять новые. Свойства при наследовании повторно не описываются, что сокращает объем программы. Иерарархия должна строиться таким образом, чтобы классы, стоящие выше в иерархии, содержали бы общие свойства классов – потомков.

Откуда же берутся классы? Исключительно из головы программиста, который, анализируя предметную область, вычленяет из нее отдельные объекты. Для каж­дого из этих объектов определяются свойства, существенные для решения зада­чи. Затем каждому реальному объекту предметной области ставится в соответст­вие программный объект.

Почему объектно-ориентированная декомпозиция оказалась более эффективным средством борьбы со сложностью процессов проектирования и сопровождения программных систем, чем функциональная декомпозиция? Тому есть много при­чин.

Оценка качества декомпозиции проекта

Со сложностью приложения трудно что-либо сделать — она определяется целью создания программы. А вот сложность реализации можно попытаться контроли­ровать. Первый вопрос, возникающий при декомпозиции: на какие компоненты (модули, функции, классы) нужно разбить программу? Очевидно, что с ростом числа компонентов сложность программы растет, поскольку необходима коопе­рация, координация и коммуникация между компонентами. Особенно негатив­ны последствия неоправданного разбиения на компоненты, когда оказываются разделенными действия, по сути тесно связанные между собой.

Вторая проблема связана с организацией взаимодействия между компонента­ми. Взаимодействие упрощается и его легче взять под контроль, если каждый компонент рассматривается как некий «черный ящик», внутреннее устройство которого неизвестно, но известны выполняемые им функции, а также «входы» и «выходы» этого ящика. Вход компонента позволяет ввести в него значение не­которой входной переменной, а выход — получить значение некоторой выходной переменной. В программировании совокупность входов и выходов черного ящика определяет интерфейс компонента. Интерфейс реализуется как набор некоторых функций (или запросов к компоненту), вызывая которые клиент либо получает какую-то информацию, либо меняет состояние компонента.

Слово «клиент» означает просто-напросто компонент, которо­му понадобились услуги другого компонента, исполняющего в этом случае роль сервера. Взаимоотношение клиент/сервер на самом деле очень старо и использо­валось уже в рамках структурного программирования, когда функция-клиент пользовалась услугами функции-сервера путем ее вызова.

Подытожим сказанное о проблемах разбиения программы на компоненты и ор­ганизации их взаимодействия. Для оценки качества программного проекта нуж­но учитывать, кроме всех прочих, следующие два показателя:

• Сцепление внутри компонента — показатель, характеризующий степень взаимосвязи отдельных его частей. Простой пример: если внутри компонента решаются две подзадачи, которые легко можно разделить, то компонент обладает слабым (плохим) сцеплением.

• Связанность) между компонентами — показатель, описывающий интерфейс между компонентом-клиентом и компонентом-сервером. Общее число входов и выходов сервера есть мера связанности. Чем меньше связанность между двумя компонентами, тем проще понять и отслеживать в будущем их взаимодействие. А так как в больших проектах эти компоненты часто разрабатываются разными людьми, то очень важно уменьшать связанность между компонентами.

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

Что принесло с собой ООП

Первым бросающимся в глаза отличием ООП от структурного программирова­ния является использование классов. Класс — это тип, определяемый програм­мистом, в котором объединяются структуры данных и функции их обработки. Конкретные переменные типа данных «класс» называются экземплярами класса, или объектами. Программы, разрабатываемые на основе концепций ООП, реа­лизуют алгоритмы, описывающие взаимодействие между объектами.

Класс содержит константы и переменные, называемые полями, а также выпол­няемые над ними операции и функции. Функции класса называются методами. Предполагается, что доступ к полям класса возможен только через вызов соответ­ствующих методов. Поля и методы являются элементами, или компонентами класса.

Эффективным механизмом ослабления связанности между компонентами в случае объектно-ориентированной декомпозиции является так называемая инкапсуляция.

Инкапсуляция — это ограничение доступа к данным и их объединение с метода­ми, обрабатывающими эти данные. Доступ к отдельным частям класса регулиру­ется с помощью специальных ключевых слов: public (открытая часть), private (закрытая часть) и protected (защищенная часть).

Методы, расположенные в открытой части, формируют интерфейс класса и могут свободно вызываться клиентом через соответствующий объект класса. Доступ к закрытой секции класса возможен только из его собственных методов, а к за­щищенной — из его собственных методов, а также из методов классов-потомков. Инкапсуляция повышает надежность программ, предотвращая непреднамерен­ный ошибочный доступ к полям объекта. Кроме этого, программу легче модифи­цировать, поскольку при сохранении интерфейса класса можно менять его реа­лизацию, и это не затронет внешний программный код (код клиента).

С понятием инкапсуляции тесно связано понятие сокрытия информации. С дру­гой стороны, понятие сокрытия информации соприкасается с понятием разделе­ния ответственности между клиентом и сервером. Клиент не обязан знать, как реализованы те или иные методы в сервере. Для него достаточно знать, что дела­ет данный метод и как к нему обратиться. При хорошем проектировании имена методов обычно отражают суть выполняемой ими работы, поэтому чтение кода клиента для сопровождающего программиста превращается просто в удовольст­вие, если не сказать — в наслаждение.

Заметим, что класс одаривает своего программиста-разработчика надежным «ук­рытием», обеспечивая локальную (в пределах класса) область видимости имен. Теперь можно сократить штат бригады программистов: специалист, отвечающий за согласование имен функций и имен глобальных структур данных между чле­нами бригады, стал не нужен. В разных классах методы, реализующие схожие подзадачи, могут преспокойно иметь одинаковые имена. То же относится и к по­лям разных классов.

С ООП связаны еще два инструмента, грамотное использование которых повы­шает качество проектов: наследование классов и полиморфизм.

Наследование — механизм получения нового класса из существующего. Произ­водный класс создается путем дополнения или изменения существующего клас­са. Благодаря этому реализуется концепция повторного использования кода. С помощью наследования может быть создана иерархия родственных типов, ко­торые совместно используют код и интерфейсы.

Полиморфизм дает возможность создавать множественные определения для опе­раций и функций. Какое именно определение будет использоваться, зависит от контекста программы. Вы уже знакомы с одной из разновидностей полиморфизма в языке C++ — перегрузкой функций.

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

От структуры — к классу

Прообразом класса в C++ является структура в С. В то же время в C++ структу­ра обрела новые свойства и теперь является частным видом класса, все элементы которого по умолчанию являются открытыми. Со структурой struct в C++ мож­но делать все, что можно делать с классом. Тем не менее в C++ структуры обыч­но используют лишь для удобства работы с небольшими наборами данных без какого-либо собственного поведения.