Аннотация

Фундаментальный учебник по основам объектно-ориентированного программирования и инженерии программ. В книге подробно излагаются основные понятия объектной технологии – классы, объекты, управление памятью, типизация, наследование, универсализация. Большое внимание уделяется проектированию по контракту и обработке исключений, как механизмам, обеспечивающим корректность и устойчивость программных систем.
В книге Бертрана Мейера рассматриваются основы объектно-ориентированного программирования. Изложение начинается с рассмотрения критериев качества программных систем и обоснования того, как объектная технология разработки может обеспечить требуемое качество. Основные понятия объектной технологии и соответствующая нотация появляются как результат тщательного анализа и обсуждений. Подробно рассматривается понятие класса - центральное понятие объектной технологии. Рассматривается абстрактный тип данных, лежащий в основе класса, совмещение классом роли типа данных и модуля и другие аспекты построения класса. Столь же подробно рассматриваются объекты и проблемы управления памятью. Большая часть книги уделена отношениям между классами – наследованию, универсализации и их роли в построении программных систем. Важную часть книги составляет введение понятия контракта, описание технологии проектирования по контракту, как механизма, обеспечивающего корректность создаваемых программ. Не обойдены вниманием и другие важные темы объектного программирования – скрытие информации, статическая типизация, динамическое связывание и обработка исключений. Глубина охвата рассматриваемых тем делает книгу Бертрана Мейера незаменимой для понимания основ объектного программирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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