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

[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), сочетающий оба фактора.

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

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

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

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

Можно было бы ожидать, что эта лекция начнется с подробного описания того, как выглядит модуль. Но это не так, и для этого есть серьезные основания. Задача этой и двух следующих лекций - анализ свойств, которыми должна обладать надлежащим образом спроектированная модульная структура. Вопросом о виде модулей мы займемся в конце нашего обсуждения, а не в его начале. И пока мы не дойдем до этой точки, слово "модуль" будет означать компонент разбиения рассматриваемой системы. Если вы знакомы с не ОО-методами, то, вероятно, вспомните о подпрограммах, имеющихся в большинстве языков программирования и проектирования, или, быть может, о пакетах (packages) языка Ada и (правда, под другим названием) языка Modula. Наконец, в последующих лекциях наше обсуждение приведет к ОО-виду модуля - классу. Даже если вы уже знакомы с классами и ОО-методами, все же следует прочитать эту лекцию для понимания требований, предъявляемых к классам, - это поможет правильному их конструированию.

Метод проектирования, который можно называть "модульным", должен удовлетворять пяти основным требованиям:

[x].Декомпозиции (decomposability).

[x].Композиции (composability).

[x].Понятности (understandability).

[x].Непрерывности (continuity).

[x].Защищенности (protection).

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

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

Рис. 3.1. Декомпозиция