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

Рассмотрим выбор критериев, позволяющих оценить объектную ориентированность системы (objectness).

Список, представленный ниже, включает все свойства, кажущиеся существенными для создания высококачественного ПО ОО-методом. Наш список может показаться бескомпромиссным и даже догматичным. Какие заключения следует делать, если среда удовлетворяет некоторым, но не всем этим критериям? Следует ли считать ее полностью неадекватной?

Только вы, мой читатель, можете ответить на этот вопрос применительно к собственному контексту. Вот несколько причин, по которым может быть необходим компромисс:

[x]. Быть ОО-системой - это не булево условие. Из двух сред А и В первая может быть более объектно-ориентированной, хотя и не является таковой на все 100%. Поэтому если внешние ограничения сводят ваш выбор только к А и В, следует выбрать А как наименьшее из двух зол.

[x]. Не каждому нужны всегда все свойства.

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

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

Набор критериев делится на три части:

[x]. Метод и язык (Method and Language) : эти два почти не различимые аспекта охватывают мыслительные процессы и нотацию, использующуюся для анализа, проектирования и программирования ПО. Заметьте, что (особенно в объектной технологии) термин "язык" относится не только к языку программирования в строгом смысле, но также и к языкам анализа и проектирования и используемой в них нотации, текстовой или графической.

[x]. Реализация (Implementation) и Среда (Environment) : критерии в этой категории описывают основные свойства инструментария, позволяющего разработчикам применять ОО-идеи.

[x]. Библиотеки (Libraries) : объектная технология основана на повторном использовании компонентов ПО. Критерии в этой категории описывают как наличие базовых библиотек, так и механизмы, необходимые для их использования и создания новых библиотек.

Такое деление удобно, но не абсолютно, поскольку некоторые критерии относятся к двум или трем категориям. Например критерий, помеченный "управление памятью", относится к категории языка, поскольку язык может поддерживать или не допускать автоматическую сборку мусора. Этот же критерий относится к категории реализации и среды.

Первый набор критериев относится к методу и поддерживающей его нотации.

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

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

Эти требования исключают два часто встречающихся случая - оба неудовлетворительных:

[x]. Использование ОО-концепций на этапе анализа и проектирования с такой нотацией, которая не может использоваться на этапе программирования.

[x]. Использование ОО-языка программирования, неподходящего для этапа анализа и проектирования.

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

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

Понятие класса должно быть центральной концепцией метода и языка.

Компоненты абстрактного типа данных имеют формально специфицированные свойства, отражаемые в соответствующих классах.

Утверждения - предусловия и постусловия программ класса и инварианты классов - играют эту роль.

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

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

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

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

Здесь опять велика роль классов. Класс описывает не только тип объектов, но и модульную единицу. В чистом ОО-подходе:

Классы должны быть единственным видом модулей.

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

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

Каждый тип должен быть основан на классе.

Даже базовые типы, такие как INTEGER и REAL, можно рассматривать как классы; обычно такие классы являются встроенными.

В ОО-вычислениях существует только один базовый вычислительный механизм. Есть некоторый объект, всегда являющийся (в силу предыдущего правила) экземпляром некоторого класса, и вычисление состоит в том, что данный объект вызывает некоторый компонент этого класса. Например, для показа окна на экране вызывается компонент display объекта, представляющего окно, - экземпляра класса WINDOW. Компоненты могут иметь аргументы: для увеличения зарплаты работника e на дату d, на n долларов, вызывается компонент raise объекта e, с аргументами n и d.

Базисные типы рассматриваются как предопределенные классы, и основные операции (например, сложение чисел) рассматриваются как специальные предопределенные случаи вызова компонентов - общий механизм вычислений:

Вызов компонента должен быть основным механизмом вычисления.

Класс, содержащий вызов компонента класса C, называют клиентом класса С .

Вызов компонента иногда называют передачей сообщения (message passing) ; по этой терминологии вышеприведенный вызов будет описываться как передача объекту e сообщения: "повысить вашу плату" с аргументами d и n.

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

Механизм, делающий определенные компоненты недоступными для клиентов, называется скрытием информации.

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

Создатели классов должны также иметь возможность избирательно экспортировать компоненты для избранных клиентов.

Автор класса должен иметь возможность указать, что компонент доступен: всем клиентам, ни одному клиенту или избранным клиентам.

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

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

Для создания надежного ПО необходимо иметь возможность восстановления нормального хода вычислений. Это является целью механизма обработки исключений.

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

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

Когда в системе происходит вызов некоторого компонента определенным объектом, как узнать, что объект способен обработать вызов? (В терминологии сообщений: как узнать, что объект может обработать сообщение?)

Чтобы гарантировать корректное выполнение, язык должен быть типизирован. Это означает, что он отвечает нескольким правилам совместимости:

[x]. Каждая сущность (entity) объявляется явным образом с указанием определенного типа, порожденного классом. Под сущностью понимается имя, используемое в тексте ПО для ссылки на объекты времени выполнения.

[x]. Каждый вызов компонента - это вызов доступного компонента соответствующего класса.

[x]. Присваивание и передача аргументов подчиняются правилам согласования, требующим совместимости исходного типа и целевого типа.

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

Хорошо определенная система типов гарантирует безопасность работы с объектами во время выполнения программной системы.

Для того чтобы типизация была практичной, необходимо иметь возможность определять классы с параметрами, задающими тип. Такие классы известны как родовые. Родовой класс LIST [G] описывает списки элементов произвольного типа G - "формальным родовым параметром".

Классы, задающие специальные списки, будут его производными, например LIST [INTEGER] и LIST [WINDOW] используют типы INTEGER и WINDOW в качестве "фактических родовых параметров". Все производные классы разделяют один и тот же текст родового класса.

Должна существовать возможность создания классов с формальными родовыми параметрами, представляющими произвольные типы.

Эта форма параметризации типа называется неограниченной универсальностью. Дополнительной возможностью, описанной ниже, является ограниченная универсальность, использующая понятие наследования.

Разработка ПО включает создание большого числа классов, многие из которых являются вариантами ранее созданных классов. Для управления потенциальной сложностью такой системы необходим механизм классификации, известный как наследование. Класс A будет наследником (heir) класса B, если он встраивает (наследует) компоненты класса B в дополнение к своим собственным. Потомок (descendant)- это прямой или непрямой наследник; обратное понятие - предок (ancestor).

Должно быть возможным объявить класс наследником другого класса.

Наследование - одно из центральных понятий ОО-метода; оно оказывает большое влияние на процесс разработки ПО.

Часто необходимо сочетать различные абстракции. Рассмотрим класс, моделирующий понятие "младенец". Его можно рассматривать как класс "человек" с компонентами, связанными с этим классом. Его же можно рассматривать и более прозаично - как класс "элемент, подлежащий налогообложению", которому положены скидки при начислении налогов. Наследование оправдано в обоих случаях. Множественное наследование (multiple inheritance) - это гарантия того, что класс может быть наследником не только одного класса, но многих, если это концептуально оправдано.

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

Класс должен иметь возможность быть наследником нескольких классов.

Конфликты имен при наследовании разрешаются адекватным механизмом.

Решение, разработанное в этой книге, основано на переименовании конфликтующих компонентов у класса наследника.

При множественном наследовании возникает ситуация дублируемого наследования (repeated inheritance), когда некоторый класс многократно становится наследником одного и того же класса, проходя по разным ветвям наследования:

Рис. 2.1.  Дублируемое наследование

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

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

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

Родовой класс SORTABLE_LIST описывает списки; он содержит компонент sort, сортирующий элементы списка в соответствии с заданным отношением порядка. Параметр этого родового класса задает тип элементов списка. Но этот тип не может быть произвольным: он должен поддерживать отношение порядка. Фактический родовой параметр должен быть потомком библиотечного класса COMPARABLE, описывающего объекты, снабженные отношением порядка. Ограниченная универсальность позволяет объявить наш родовой класс следующим образом: SORTABLE_LIST [G -" COMPARABLE] .

Механизм универсальности должен поддерживать форму ограниченной универсальности.

Когда класс является наследником другого класса, может потребоваться изменить реализацию или другие свойства некоторых наследованных компонент. Класс SESSION, управляющий сеансами пользователей в операционной системе, может иметь компонент terminate, выполняющий чистку в конце сеанса. Его наследником может быть класс REMOTE_SESSION, управляющий сеансом удаленного компьютера в сети.

Если завершение удаленного сеанса требует дополнительных действий, таких как, например, уведомление удаленного компьютера, класс REMOTE_SESSION переопределит компонент terminate.

Переопределение может повлиять на реализацию компонента, его сигнатуру (тип аргументов и результата) и спецификацию.

Должно быть возможным переопределить спецификацию, сигнатуру и реализацию наследованного компонента.

При наследовании, требование статической типизации, о котором говорилось выше, становится ограничивающим, если бы оно означало, что каждая сущность типа C может быть связана только с объектом точно такого же типа С. Например в системе управления навигацией сущность типа BOAT нельзя было бы использовать для объектов класса MERCHANT_SHIP или SPORTS_BOAT, хотя оба класса являются потомками класса BOAT.

Полиморфизм (polymorphism) - способность присоединять к сущности объекты различных возможных типов. В статически типизированной среде полиморфизм не будет произвольным, а будет контролироваться наследованием.

Должна иметься возможность в период выполнения присоединять к сущности объекты различных возможных типов под управлением наследования.

Сочетание последних двух механизмов, переопределения и полиморфизма, непосредственно предполагает следующий механизм. Допустим, есть вызов, целью которого является полиморфная сущность, например сущность типа BOAT вызывает компонент turn. Различные потомки класса BOAT, возможно, переопределили этот компонент различными способами. Ясно, что должен существовать автоматический механизм, гарантирующий, что версия turn всегда соответствует фактическому типу объекта, вне зависимости от того, как объявлена сущность. Эта возможность называется динамическим связыванием (dynamic binding).

Вызов сущностью компонента всегда должен запускать тот компонент, который соответствует типу присоединенного объекта, а не типу сущности.

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

Динамическое связывание оказывает большое влияние на структуру ОО-приложения, поскольку дает возможность разработчикам писать простые вызовы, например объект my_boat вызывает компонент turn. В действительности, данный вызов означает несколько возможных вызовов, зависящих от соответствующих ситуаций времени выполнения. Это упраздняет необходимость многих повторных проверок (является ли объект merchant_ship? Является ли он sports_boat?), наводняющих программные продукты, создаваемые при обычных подходах.

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

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

Операция попытка присваивания (assignment attempt) удовлетворяет этим требованиям. Это условная операция: она пытается присоединить объект к сущности; если при выполнении операции тип объекта соответствует типу сущности, то она действует как нормальное присваивание; в противном случае сущность получает специальное значение void. Итак, можно управлять объектами, тип которых не известен наверняка, не нарушая безопасности системы типов.

Необходимо иметь возможность определять во время выполнения, соответствует ли тип объекта статически заданному типу.

В некоторых случаях, для которых динамическое связывание дает элегантное решение, устраняя необходимость явных проверок, не существует начальной версии компонента, подлежащего переопределению. Например, класс BOAT может быть настолько общим, что не может обеспечить реализацию turn по умолчанию. Все же, мы хотим иметь возможность вызвать компонент turn сущностью типа BOAT, если мы уверены, что во время выполнения она будет получать значение объектов таких полностью определенных типов как, например, MERCHANT_SHIP и SPORTS_BOAT.

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

Необходимо иметь возможность написания класса или компонента как отложенного, то есть специфицированного, но не полностью реализованного.

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

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

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

Автоматическая сборка мусора - это проблема языка, так же как и реализации. Если язык явно не спроектирован для автоматического управления памятью, то зачастую реализация становится невозможной. Это справедливо для языков, где, например, указатель на объект определенного типа может быть преобразован (используя кастинг - cast) в указатель другого типа или даже в целое число, - такие средства делают невозможным создание надежного сборщика мусора.

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

Мы подошли к важным свойствам среды разработки, поддерживающей создание ОО-ПО.

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

При выполнении такого обновления важно иметь гарантию, что полученная в результате система будет согласованной. Например, если вы меняете некоторый компонент f класса C, то вы должны быть уверены, что любой потомок C, который не переопределяет f, получит новую версию f, и что каждое обращение к f клиента C или потомка C будет запускать эту новую версию.

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

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

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

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

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

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

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

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

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

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

Разработчики классов и систем должны обеспечивать руководство, заказчиков и других разработчиков ясными высокоуровневыми описаниями создаваемого ПО. Им необходим инструментарий, помогающий в этой работе. Большая часть документации должна автоматически создаваться на основе текстов ПО. Утверждения, как уже отмечено, помогают сделать такие документы, извлекаемые из ПО, точными и информативными.

Должны быть в наличии инструментальные средства для автоматического получения документации о классах и системах.

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

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

Средства интерактивного просмотра должны давать возможность разработчикам ПО быстро и удобно прослеживать зависимости между классами и компонентами.

Один из характерных аспектов разработки ПО ОО-способом - возможность создавать его на основе существующих библиотек. ОО-среда должна обеспечивать хорошие библиотеки и механизмы создания новых библиотек.

Изначально в информатике изучаются фундаментальные структуры данных - множества, списки, деревья, стеки; связанные с ними алгоритмы - сортировки, поиска, обхода, сопоставления с образцом. Эти структуры и алгоритмы вездесущи в разработках ПО. Нередко, когда в своей системе очередной разработчик повторно их реализует. Это не только расточительно, но и пагубно отражается на качестве ПО, поскольку вряд ли отдельный разработчик, реализующий структуру данных не как цель саму по себе, а в качестве компонента некоторого приложения, достигнет оптимальной надежности и производительности.

ОО-среда разработки должна обеспечить повторно используемые классы, удовлетворяющие общим потребностям.

Должны быть доступны повторно используемые классы, реализующие фундаментальные структуры данных и алгоритмы.

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

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

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

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

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

Библиотечные классы должны быть снабжены индексирующей информацией, допускающей поиск, основанный на свойствах.

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

Изучение этой лекции в основном самодостаточно, так что вы сможете понять решение, не читая промежуточные лекции. Но если вы заглянете туда, то должны обещать вернуться назад, чтобы продолжить изучения материала последовательно, начиная с лекции 3.

Введение в ОО-критерии - это то место, где стоит привести список работ, дающих хорошие введения в объектную технологию в целом.

[Walden 1995] обсуждает самые важные проблемы объектной технологии, обращая особое внимание на анализ и проектирование, эта книга является, вероятно, лучшим справочным руководством по этому вопросу.

[Page-Jones 1995] дает отличный обзор метода.

[Cox 1990] (первое издание относится к 1986 году) основывается на несколько другом взгляде на объектную технологию; книга послужила распространению ОО-концепций среди широкой публики.

[Henderson-Sellers 1991] (второе издание готовится) дает краткий обзор ОО-идей. Книга предназначена для людей, которых их компания просит "пойти и посмотреть, что это такое объектное программирование", содержит готовые для копирования диапозитивные оригиналы, в некоторых случаях очень ценные. Еще один обзор - это [Eliens 1995].

Словарь Объектной Технологии [Firesmith 1995] дает обширный справочный материал по многим аспектам метода.

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

Книга [M 1995] выросла из лекции, первоначально предназначенной для данной книги, и стала полноправной книгой, в которой объектная технология обсуждается с позиций управляющего персонала. Она начинается небольшой технической презентацией, использующей профессиональные термины, и далее дает анализ вопросов менеджмента (жизненный цикл, управление проектами, политика повторного использования). Еще одна книга с управленческим уклоном, [Goldberg 1995], дает дополнительную перспективу многих важных тем. [Baudoin 1996] делает акцент на вопросах жизненного цикла и важности стандартов.

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

[x]. Simula BEGIN [Birtwistle 1973] (еще два автора являются создателями языка - Nygaard и Dahl.)

[x]. Smalltalk-80: Язык и его реализация [Goldberg 1983].

[x]. Язык программирования C++, второе издание [Stroustrup 1991].

Совсем недавно некоторые начальные учебники по программированию стали использовать ОО-идеи с самого начала, поскольку нет причин позволять "онтогенезу повторять филогенез". Нет необходимости, чтобы бедные студенты, как их предшественники, прошли через всю историю колебаний и ошибок, пока не доберутся до правильных идей. Первый такой текст (насколько я знаю) был [Rist 1995]. Другая хорошая книга, отвечающая тем же потребностям - это [Wiener 1996]. На следующем уровне - учебники для второго курса по программированию. Обсуждение структур данных и алгоритмов, основанное на нотации этой книги - вы найдете в [Gore 1996] и [Wiener 1997]; [Jezequel 1996] представляет принципы ОО-инженерии ПО. Преподавание технологии обсуждается также в лекции 11 курса "Основы объектно-ориентированного проектирования".

Группа новостей Usenet comp.object, на нескольких сайтах сети, является естественной площадкой обсуждения многих вопросов объектной технологии. Как и все подобные форумы, это смесь хорошего, плохого и ужасного. Раздел Объектной Технологии в Computer (IEEE), который я редактирую с его начала в 1995 году, часто помещает колонки ведущих экспертов.

Журналы, посвященные Объектной Технологии:

[x]. Journal of Object-Oriented Programming (первый журнал в этой области, в центре которого технические обсуждения, но они предназначены для широкой публики), Object Magazine (более общего диапазона, с некоторыми статьями для менеджеров), Objekt Spektrum (на немецком языке), Object Currents (онлайн), адрес http://www.sigs.com.

[x]. Theory and Practice of Object Systems, архивный журнал.

[x]. L'OBJET (на французском языке), адрес http://www.tools.com/lobjet.

Основные международные конференции по объектному ориентированию:

OOPSLA (ежегодная, USA или Canada, см. http://www.acm.org); Object Expo (различное время и разные места, см. http://www.sigs.com); и TOOLS (Технология ОО-языков и систем), организуемая ISE три раза в год (USA, Europe, Pacific), см. материалы по адресу: http://www.tools.com, также является общим ресурсом объектной технологии и вопросов, обсуждаемых в этой книге.