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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[x]. Отношение "быть клиентом" достаточно широкое и покрывает многие виды зависимостей. Примерами таких зависимостей является отношение, часто называемое агрегацией (присутствие в каждом объекте типа B подобъекта типа A ), а также зависимость по ссылке и родовая зависимость.

[x]. Отношение наследования покрывает многочисленные формы специализации.

[x]. Многие зависимости можно выразить в общем виде другими способами. Например, для описания зависимости "от 1-го до n " (каждый объект типа B связан с не менее чем одним и не более чем с n объектами типа A ) укажем, что B является клиентом A , и присоединим инвариант класса , точно определяющий природу отношения "быть клиентом". Так как инварианты классов выражаются с помощью логического языка, они покрывают намного больше различных отношений, чем может предложить подход сущность-связь или другие аналогичные подходы.