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

Несколько слов об индексировании компонентов

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

Принцип Самодокументирования говорит о том, что вся информация о модуле, включая индексирующую информацию и другие виды документации, - должна содержаться в самом модуле. Это важное требование учтено при разработке нотации классов, развиваемой в лекциях 7-18 этого курса. Механизм предусматривает возможность подключения данных индексирования к каждому компоненту.

'Самодокументирование', лекция 3.

Описание соответствующей синтаксической структуры не вызывает затруднений. В начале текста модуля предлагается написать предложение индексирования (indexing clause) в виде

Indexing
index_word1: value, value, value ...
index_word2: value, value, value ...
...
... Стандартное описание модуля (см. лекции 7-18) ...

Здесь каждое index_word (то есть - индексное слово) это идентификатор; каждое value (то есть - значение) это константа (целая, вещественная и т. д.), идентификатор, или какой либо другой стандартный лексический элемент. (Более подробно см. 'Операторы индексирования', лекция 8 курса 'Основы объектно-ориентированного проектирования')

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

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

Форматы для распространения повторно используемых компонентов

Еще одной задачей, охватывающей как технические, так и организационные проблемы, является выбор представления для распространения: исходный текст или двоичный формат? Это спорный вопрос, и мы ограничимся рассмотрением только нескольких доводов с обеих сторон.

Разработчики коммерческого ПО часто распространяют лишь описание интерфейса (соответствующая краткая форма (short form) рассматривается в одной из последующих лекций) и исполняемый код. Тем самым разработчики защищают секреты производства и свои инвестиции. ('Использование утверждений (assertions) для документирования: сокращенная форма класса', лекция 11)

Двоичный код и в самом деле является предпочтительной формой распространения коммерческих прикладных программ, операционных систем и других инструментальных средств, в том числе компиляторов, интерпретаторов и сред разработки для ОО-языков. Несмотря на непрекращающиеся нападки на такую концепцию, исходящие, в частности, от группы, называющейся Лигой Сторонников Свободного Программирования (League for Programming Freedom), маловероятно, что от такого способа распространения коммерческого ПО откажутся в ближайшем будущем. Но наше обсуждение относится не к обычным инструментальным средствам или прикладным программам: здесь рассматриваются библиотеки повторно используемых компонентов. В этом случае также могут быть найдены некоторые доводы в пользу распространения исходных текстов.

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

Некоторые компиляторы создают вначале промежуточный код, который уже затем транслируется или интерпретируется на конкретной платформе. Это позволяет обеспечить мобильность ПО без полного доступа к исходному тексту. Если, как это часто бывает сейчас, в компиляторе формируется промежуточный код с использованием языка C, то вместо двоичного кода обычно можно поставлять переносимый код на языке C.4.2) Этот прием использовался на разных этапах истории создания ПО, начиная с языка UNCOL (UNiversal COmputing Language - универсальный язык программирования), предложенного в конце пятидесятых годов 20-го века. Для него был определен формат команд, интерпретируемых на любой платформе, и представляющих промежуточный код, создаваемый компилятором. В связи с этой проблематикой в 1988 г. был сформирован консорциум компаний по компьютерным техническим средствам и программному обеспечению (Advanced computer environment (ACE) consortium). Вместе с языком Java появилась понятие байт-кода Java-компилятора, для которого были разработаны интерпретаторы на многих платформах. Но для производителей компонентов вначале это привело к дополнительным трудозатратам. Необходима двойная гарантия того, что новый формат пригоден на любой платформе, представляющей практический интерес, и что не происходит потери эффективности выполнения промежуточного кода в сравнении с платформо-специфическим решением. Без этих гарантий нельзя будет отказаться от старой технологии и придется просто добавить новый формат кода к тем форматам, которые поддерживались ранее. Таким образом, решение, которое рекламируется как завершающее все проблемы переносимости, фактически на некоторое время порождает дополнительные проблемы переносимости.

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