Интернет-журнал "Домашняя лаборатория", 2007 №6
Шрифт:
#include "CJournal.h"
// Конструктор
CJournal::CJournal: CPublication
{
// Ввод номера журнала
cout << "Number: ";
cin >> m_nNumber;
}
// Деструктор
CJournal::~CJournal
{
}
// Вывод описания журнала
void СJournal::Display
{
cout << "Journal: " << endl;
cout << "Title: " << m_nTitle << endl;
cout << "Year: " << m_nYear << endl;
cout << "Number: " << m_nNumber << endl;
}
И,
// Книги и журналы (объектно-ориентированное программирование)
#include <iostream.h>
#include "CBook.h"
#include "CJournal.h"
#define MAX_ID 100 // максимальное число изданий
void main
{
int nMenu, flag = 1;
int nNewID =0; // индекс нового издания
CPublication* aCPublication[MAX_ID]; // массив изданий
while(nNewID < MAX_ID && flag)
{
// Вывод пунктов меню
cout << "Новое издание. Введите: "<< endl;
cout << " 1 для книги,\n 2 для журнала\n 3 — выход" << endl;
// Выбор пункта меню
cin >> nMenu;
switch (nMenu)
{ case 1: aCPublication[nNewID++] = new CBook; break;
case 2: aCPublication[nNewID++] = new CJournal; break;
default: flag = 0; break;
}
}
// Вывод описаний изданий
for (int id = 0; id < nNewID; id++)
{
aCPublication[id]->Display;
delete aCPublication[id];
}
}
В данном примере демонстрируется использование основных принципов объектно-ориентированного программирования
• Инкапсуляция
Инкапсуляция означает сокрытие от пользователя класса его внутренней кухни. Данные и функции (методы) хранятся вместе, доступ к данным (которые следует размещать в защищенной секции protected или private) доступен только с помощью методов класса. Это позволяет разработчику класса менять код класса не изменяя код использующих его приложений (если только не были изменены сигнатуры методов).
• Наследование реализации
Цель механизма наследования — повторное использование кода. Класс в, наследующий класс а, наследует его данные и методы.
• Полиморфизм
Так как и класс CBоок, и класс CJournal происходят от одного базового класса CPublication, а метод Display в базовом классе является виртуальным, все производные от этого базового класса классы могут переопределить этот метод. Таким образом, мы имеем возможность вызывать метод Display для любого объекта любого класса порожденного от CPublication и не беспокоиться при этом о выяснении типа объекта.
Таким образом, ООП преодолевает проблемы, возникающие при использовании процедурного подхода. Но имеются и проблемы не решаемые ООП:
• Повторное использование кода
Это одна из целей ООП. Возможны два подхода:
? Распространение библиотек классов в виде исходного кода (' белый ящик")
Этот способ часто используется, т. к. библиотека будет компилироваться на машине клиента и, следовательно, не будет проблем с несовместимостью различных компиляторов.
Но с этим способом связаны следующие проблемы:
— Многие программисты предпочитают писать свой код, а не изучать чужой.
— После изучения кода библиотеки часто возникает соблазн его модификации, адаптации под конкретное приложение. В результате принцип повторного использования кода нарушается, т. к. приложение не сможет использовать новые версии этой библиотеки.
— Код библиотеки включается в код всех использующих ее приложений,
? Упаковка класса в динамически компонуемую библиотеку (DLL)
При этом мы избавляемся от проблем, возникающих при распространении классов в виде исходного кода. Но, естественно, возникают новые проблемы:
— Отсутствие двоичного стандарта для C++
Различные компиляторы с C++ по разному решают вопросы реализации отдельных языковых особенностей языка C++ и некоторые вопросы компоновки. В связи с этим, в общем случае нельзя гарантировать, что DLL, подготовленная на одном компиляторе, будет работать с клиентом, подготовленным с помощью другого компилятора.
— Проблема версий DLL
C++ поддерживает синтаксическую инкапсуляцию, но не двоичную. Иными словами, от клиента скрыта реализация класса на уровне языка, что позволяет менять реализацию класса не меняя кода клиента. Но при этом перекомпиляция клиента в общем случае необходима. Это связано с тем, что именно клиент отводит память под все данные экземпляра класса. Это делается ради повышения эффективности. В результате, если при изменении реализации класса был изменен состав (иили порядок) данных класса, то клиент не будет работать с новей версией DLL без перекомпиляции. Установив новую версию DLL, мы погубим все приложения, которые были скомпилированы для работы со старой версией.
• Не решены вопросы разработки распределенных приложений
Собственно, такая задача и не ставилась при разработке ООП. Однако в современных условиях распределенность приложений становится необходимым требованием.
Компонентное программирование
В данном разделе будет дано только очень короткое введение в проблематику компонентного программирования. Подробнее — в последующих главах.
Компонентное программирование — попытка решить те проблемы, которые возникают при использовании ООП. Основная идея — распространение классов в бинарном виде (т. е. не в виде исходного кода) и предоставление доступа к методам класса через строго определенные интерфейсы, что позволяет снять проблему несовместимости компиляторов и обеспечивает смену версий классов без перекомпиляции использующих их приложений.
Здесь стоит отметить, что роль интерфейсов в СОМ значительно более важная, чем роль посредника. Все в СОМ начинается с интерфейсов. Они определяются первыми и задают семантику некоторого сервиса. Различные классы могут реализовывать заданный интерфейс, обеспечивая тем самым полиморфизм на новом уровне.
Имеются различные технологии, реализующие парадигму компонентного программирования. Среди них COM (DCOM, СОМ+), С ORB A, Net.
Для определенности остановимся на подходе, используемом в СОМ.