Чтение онлайн

на главную - закладки

Жанры

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

Мейер Бертран

Шрифт:

Расширяемость

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

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

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

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

Возможность повторного использования

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

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

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

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

Совместимость

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

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

Объектно-ориентированное конструирование ПО

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

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

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

не на одной или нескольких функциях, которые она должна предоставлять).

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

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

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

Спроси, кто в системе это делает!

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

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

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

Вопросы

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

[x]. Как находить релевантные типы объектов?

[x]. Как описывать типы объектов?

[x]. Как описывать взаимоотношения типов объектов и их близость?

[x]. Как использовать типы объектов для структурирования ПО?

Оставшаяся часть этой книги будет посвящена ответам на эти вопросы. Давайте рассмотрим предварительно некоторые ответы.

Выявление типов объектов

Вопрос "как мы будем находить объекты?" вначале может выглядеть пугающим. В лекции 4 курса "Основы объектно-ориентированного проектирования" мы рассмотрим его более подробно, но здесь полезно рассеять некоторые из возникающих страхов. Этот вопрос может не отнять много времени у опытных ОО-разработчиков, в частности, благодаря доступности трех источников для ответа:

Поделиться:
Популярные книги

Пышка и Герцог

Ордина Ирина
Фантастика:
юмористическое фэнтези
историческое фэнтези
фэнтези
5.00
рейтинг книги
Пышка и Герцог

Война

Валериев Игорь
7. Ермак
Фантастика:
боевая фантастика
альтернативная история
5.25
рейтинг книги
Война

Замуж с осложнениями. Трилогия

Жукова Юлия Борисовна
Замуж с осложнениями
Фантастика:
фэнтези
юмористическая фантастика
космическая фантастика
9.33
рейтинг книги
Замуж с осложнениями. Трилогия

Седьмой Рубеж VI

Бор Жорж
6. 5000 лет темноты
Фантастика:
фэнтези
попаданцы
5.00
рейтинг книги
Седьмой Рубеж VI

Путь Шедара

Кораблев Родион
4. Другая сторона
Фантастика:
боевая фантастика
6.83
рейтинг книги
Путь Шедара

Имя нам Легион. Том 9

Дорничев Дмитрий
9. Меж двух миров
Фантастика:
боевая фантастика
рпг
аниме
5.00
рейтинг книги
Имя нам Легион. Том 9

Беглец

Бубела Олег Николаевич
1. Совсем не герой
Фантастика:
фэнтези
попаданцы
8.94
рейтинг книги
Беглец

Старшина Империи. Часть вторая

Четвертнов Александр
3. Внутренняя сила
Фантастика:
боевая фантастика
космическая фантастика
5.25
рейтинг книги
Старшина Империи. Часть вторая

Прорвемся, опера! Книга 3

Киров Никита
3. Опер
Фантастика:
попаданцы
альтернативная история
5.00
рейтинг книги
Прорвемся, опера! Книга 3

Доктора вызывали? или Трудовые будни попаданки

Марей Соня
Фантастика:
юмористическая фантастика
попаданцы
5.00
рейтинг книги
Доктора вызывали? или Трудовые будни попаданки

Проданная невеста

Wolf Lita
Любовные романы:
любовно-фантастические романы
5.80
рейтинг книги
Проданная невеста

Полководец поневоле

Распопов Дмитрий Викторович
3. Фараон
Фантастика:
попаданцы
5.00
рейтинг книги
Полководец поневоле

Идеальный мир для Лекаря 15

Сапфир Олег
15. Лекарь
Фантастика:
боевая фантастика
юмористическая фантастика
аниме
5.00
рейтинг книги
Идеальный мир для Лекаря 15

Имперец. Том 5

Романов Михаил Яковлевич
4. Имперец
Фантастика:
попаданцы
альтернативная история
аниме
6.00
рейтинг книги
Имперец. Том 5