М. Бен-Ари - Языки программирования. Практический сравнительный анализ (2000) (1160781), страница 39

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 39)

(см. раздел 15.1).

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

// Некоторый файл

#include "Airplanes.h" // Содержит объявление класса

void Airplanes::new_airplane(const Airplane_Data & a, int & i)

{

…

}

void Airplanes::get_airplane(int i, Airplane_Data & a) const

{

….

}

int Airplanes::find_empty_entry()

{

…

}

Обратите внимание, что внутренняя подпрограмма find_empty_entry должна быть объявлена внутри (в закрытой части) класса так, чтобы она могла обра­щаться к приватным данным.

Пространство имен

Одним из последних добавлений к определению языка C++ была конструк­ция namespace (пространство имен), которая дает возможность программи­сту ограничить область действия других глобальных объектов так же, как это делается с помощью пакета в языке Ada. Конструкция, аналогичная use-пред­ложению в Ada, открывает пространство имен:

namespace N1 {

void proc(); //Процедура в пространстве имен

};

namespace N2 {

void proc(); // Другая процедура

};

N1:: proc(), //Операция разрешения контекста для доступа

using namespace N1 ;

proc(); // Правильно

using namespace N2;

proc(); //Теперь неоднозначно

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

13.6. Упражнения

1. Напишите главную программу на языке С, которая вызывает внешнюю функцию f с целочисленным параметром; в другом файле напишите функцию f с параметром с плавающей точкой, который она печатает. Откомпилируйте, скомпонуйте и выполните программу. Что она печата­ет? Попытайтесь откомпилировать, скомпоновать и выполнить ту же самую программу на языке C++ .

2. Напишите программу, реализующую абстрактный тип данных для оче­реди, и главную программу, которая объявляет и использует несколько очередей. Очередь должна быть реализована как массив, который объяв­лен в закрытой части пакета языка Ada или класса C++. Затем измените реализацию на связанный список; главная программа должна выпол­няться без изменений.

3. Что происходит, если вы пытаетесь присвоить одну очередь другой? Ре­шите проблему, используя ограниченный приватный тип в языке Ada или конструктор копий (copy-constructor) в C++.

4. В языках С и C++ в объявлении подпрограммы имена параметров не обязательны:

int func(int, float, char*);

Почему это так? Будут ли так или иначе использоваться имена парамет­ров? Почему в языке Ada требуется, чтобы в спецификации пакета при­сутствовали имена параметров?

5. В языке Ada есть конструкция для раздельной компиляции, которая не зависит от конструкции пакета:

procedure Main is

Global: Integer;

procedure R is separate; -- Раздельно компилируемая процедура

end Main;

separate(Main) --Другой файл

procedure R is

begin

Global := 4; -- Обычные правила области действия

end R:

Факт раздельной компиляции локального пакета или тела процедуры не влияет на область действия и видимость. Как это может быть реализова­но? Требуют ли изменения в раздельно компилируемой единице пере­компиляции родительской единицы? Почему? Обратный вопрос: как из­менения в родителе воздействуют на раздельно компилируемую единицу?

6. Раздельно компилируемая единица может содержать конструкцию, задающую контекст:

with Text_IO;

separate(Main)

procedure R is

…

end R;

Как это можно использовать?

7. Следующая программа на языке Ada не компилируется; почему?

package P is

type T is (А, В, С, D);

end Р;

with P;

procedure Main is

X: Р.Т;

begin

if X = P. A then ...end if;

end Main;

Существуют четыре способа решить проблему; каковы преимущества и недостатки каждого из них: а) use-конструкция, б) префиксная запись, в) renames (переименование), г) конструкция use type в языке Ada 95?

Глава 14

Объектно-ориентированное программирование

14.1. Объектно-ориентированное проектирование

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

При проектировании программы естественный подход должен состоять в том, чтобы исследовать требования в терминах функций или операций, то есть задать вопрос: что должна делать программа? Например, программное обеспечение для предварительной продажи билетов в авиакомпании должно выполнять такие функции:

1. Принять от кассира место назначения заказчика и дату отправления.

2. Отобразить на терминале кассира список доступных рейсов.

3. Принять от кассира предварительный заказ на конкретный рейс.

4. Подтвердить предварительный заказ и напечатать билет.

Эти требования, естественно, находят отражение в проекте, показанном на рис. 14.1, с модулем для каждой функции и «главным» модулем, который вызывает другие.

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

Но все мы знаем, что изменение программного обеспечения чревато внесением ошибок; не устойчивый к ошибкам проект приведет к тому, что поставленная программная система будет ненадежной и неустойчивой. Вы могли бы возразить, что персонал должен воздержаться от изменения про­граммного обеспечения, но весь смысл программного обеспечения состоит в том, что это именно программное обеспечение, а значит, его можно перепро­граммировать, изменить; иначе все прикладные программы было бы эффек­тивнее «зашить» подобно программе карманного калькулятора.

Программное обеспечение можно сделать намного устойчивее к ошибкам и надежнее, если изменить основные критерии, которыми мы руководствуем­ся при проектировании. Правильнее задать вопрос: над чем работает програм­мное обеспечение? Акцент делается не на функциональных возможностях, а на внешних устройствах, внутренних структурах данных и моделях реального мира, т. е. на том, что принято называть объектами (objects). Модуль должен быть создан для каждого «объекта» и содержать все данные и операции, необ­ходимые для реализации объекта. В нашем примере мы можем выделить не­сколько объектов, как показано на рис. 14.2.

Такие внешние устройства, как дисплейный терминал и принтер, иденти­фицированы как объекты, так же как и базы данных с информацией о рейсах и предварительных заказах. Кроме того, мы выделили объект Заказчик, на­значение которого — моделировать воображаемую форму, в которую кассир вводит данные до того, как подтвержден рейс и выдан билет. Этот проект ус­тойчив к ошибкам при внесении изменений:

• Изменения, которые вносят для того, чтобы использовать разные терми­налы, могут быть ограничены объектом Терминал. Программы этого объекта отображают данные заказчика на реальный дисплей и команды клавиатуры, так что объект Заказчик не должен изменяться, а только ото­бражаться на новые аппаратные средства.

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

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

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

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

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

В каждом объекте должно скрываться одно важное проектное решение.

Очень полезно бывает задать себе вопрос: «возможно ли, что это решение изменится за время жизни программы?»

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

В следующих разделах языковая поддержка ООП будет обсуждаться на при­мере двух языков: C++ и Ada 95. Сначала мы рассмотрим язык C++, который был разработан как добавление одной интегрированной конструкции для ООП к языку С, в котором нет поддержки даже для модулей. Затем мы увидим, как полное объектно-ориентированное программирование определено в язы­ке Ada 95 путем добавления нескольких небольших конструкций к языку Ada 83, который уже имел много свойств, частично поддерживающих ООП.

14.2. Объектно-ориентированное программирование на языке C++

Характеристики

Список файлов книги