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

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

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

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

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

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

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

Мы рассмотрели ранее ( лекция 4) типичный пример: поиск в таблице. Начав с, казалось бы, естественного кандидата на повторное использование - процедуры поиска, мы поняли, что ее нельзя повторно использовать отдельно от других операций, применяемых к таблице, таких как вставка и удаление.

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

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

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

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

У нас уже накоплено достаточно оснований, чтобы попытаться определить ОО-конструирование ПО. Это будет лишь первый набросок, более конкретное определение последует в следующей лекции.

ОО-конструирование ПО (определение 1)

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

Содержательная характеристика этого подхода может служить лозунгом ОО-проектировщика:

Объектный девиз

Не спрашивай вначале, что система делает.