Бертран Мейер - Основы объектно-ориентированного программирования

Двумя наиболее известными книгами по "образцам ( шаблонам) проектов" являются [Gamma 1995] и [Pree 1994].

Работа [Weiser 1987] является призывом к распространению ПО в виде исходных текстов. Однако в этой статье недооценивается необходимость абстракции; как было показано в этой лекции, при необходимости можно сохранить возможность доступа к исходному тексту, но применить его высокоуровневую форму в качестве документации по умолчанию для пользователей модуля. Из других соображений Ричард Сталлман (Richard Stallman), создатель Лиги Сторонников Свободы Программирования (League for Programming Freedom), утверждал, что представление в виде исходного текста всегда должно быть доступно; смотрите [Stallman 1992].

В работе [Cox 1992] описывается идея суперпоставки (superdistribution) Некоторая разновидность перегрузки имелась в языке Algol 68 [van Wijngaarden 1975]; в языках Ada (в котором это распространено на подпрограммы), C++ и Java, которые будут рассмотрены в последующих лекциях, этот механизм широко используется.

Универсальность или полиморфизм (genericity) появляется в языках Ada и CLU, и в ранней версии языка спецификаций Z [Abrial 1980]; в этой версии синтаксис Z близок к используемому для представления универсальности в этой книге. Язык LPG [Bert 1983], был явно предназначен для исследования универсальности. (Название этого языка является аббревиатурой из начальных букв "Language for Programming Generically".)

Работа, цитированная в начале этой лекции в качестве основной ссылки на табличный поиск, это [Knuth 1973]. Среди многих пособий по алгоритмам и структурам данных, которые освещают этот вопрос, стоит обратить внимание на [Aho 1974], [Aho 1983] или [M 1978].

Две книги автора данной книги содержат дальнейший анализ вопроса повторного использования. Книга Reusable Software[M 1994a], полностью посвященная этой теме, представляет принципы разработки и реализации для создания высококачественных библиотек, и полную спецификацию множества базисных библиотек. В книге Object Success[M 1995] обсуждаются организационные аспекты проблемы повторного использования, особенно те сферы деятельности, в которых должна прилагать усилия фирма, заинтересованная в повторном использовании, и области, в которых такие усилия будут, по-видимому, бесполезными (например, рекомендации повторного использования разработчикам приложений, или поощрение осуществления ими повторного использования). Смотрите также короткую статью на эту тему, [M 1996].

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

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

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

Чтобы верно ответить на него, нужно сравнить соперничающих кандидатов.

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

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

Рис. 5.1. Три силы вычисления

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

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

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

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

Таким образом, остаются действия и объекты. Дуализм между действиями и объектами - тем, что система делает, и тем, с чем она это делает - это популярная тема в разработке ПО.

[x].Замечание о терминологии. Для обозначения каждого из этих двух аспектов имеются соответствующие синонимы: слово данныебудет использоваться как синоним слова объекты, а вместо слова действиемы, следуя обычной практике, будем говорить о функцияхсистемы.

[x].Термин "функция" также не лишен недостатков, поскольку при обсуждении ПО он используется по крайней мере в двух смыслах: математическом и в смысле ПО как подпрограмма, возвращающая некоторый результат. Но, не боясь неоднозначности, мы будем использовать фразу "функции системы", требуемую здесь.

[x].Причина, по которой мы используем это слово, а не "действие" - чисто грамматическое удобство от использования соответствующего прилагательного, например во фразе "функциональная декомпозиция". Слово "действие" не имеет соответствующего производного прилагательного. Другим термином, чье значение в нашем обсуждении эквивалентно значению слова "действие", является слово "операция".