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

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

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

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

Пять критериев

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

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

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

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

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

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

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

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

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

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

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

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

Декомпозиция

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

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

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