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

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы

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

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

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

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

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

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

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

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

[x]. Многие объекты лежат на поверхности. Они непосредственно моделируют объекты физической реальности, к которой применяется ПО. ОО-технология является мощным средством моделирования, использующим типы программных объектов (классы) для моделирования типов физических объектов и отношения между типами объектов (клиент, наследование) для моделирования отношений между типами физических объектов таких, как агрегирование и специализация. Разработчику ПО не требуется изучать трактаты по ОО-анализу, чтобы в системе мониторинга для телекоммуникаций использовать класс CALL (ВЫЗОВ) и класс LINE (ЛИНИЯ), а в системе обработки документов - класс DOCUMENT (ДОКУМЕНТ), класс PARAGRAPH (АБЗАЦ) и класс FONT (ШРИФТ).

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

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

Мы лучше поймем эти и другие методы выделения объектов, когда приобретем более глубокое понимание сути понятия "объект" в программировании - не надо смешивать его с обыденным значением этого слова.

Описания типов и объектов

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