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

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

Вопросы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При ответе на него следует руководствоваться двумя требованиями:

[x]. Нужно добиваться независимости описаний от представлений, чтобы не потерять главное преимущество проектирования сверху вниз: абстрактность.

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

В следующей лекции развивается методика описания объектов, позволяющая достичь обе эти цели.

Описание отношений и структурирование ПО

Другой вопрос связан с тем, какие отношения допустимы между типами объектов. В рафинированной объектной технологии имеются только два отношения: "быть клиентом" и наследование. Они соответствуют различным видам возможных зависимостей между двумя типами объектов A и B :

B является клиентом A , если каждый объект типа B содержит информацию об одном или нескольких объектах типа A .

B является наследником A, если B представляет специализированную версию A .

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