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

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

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

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

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

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

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

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

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

Чтобы глубоко понять концепции, предпочтительно читать эту книгу последовательно, однако читатели, желающие дополнить данный теоретический обзор, могут, прежде чем идти дальше, посмотреть, как работает метод на практическом примере. Для этого следует обратиться к лекции 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, также является общим ресурсом объектной технологии и вопросов, обсуждаемых в этой книге.

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

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

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

Рене Декарт, "Рассуждения о методе" (1637)

Чтобы обеспечить расширяемость (extendibility) и повторное использование (reusability), двух основных факторов качества, предложенных в лекции 1, необходима система с гибкой архитектурой, состоящая из автономных программных компонент. Именно поэтому в лекции 1 введен термин модульность (modularity), сочетающий оба фактора.

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