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

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

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

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

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

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

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

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

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

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

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

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

[x].Вычисление включает три вида ингредиентов: процессоры (или потоки управления), действия (или функции) и данные (или объекты).

[x].Архитектуру системы можно получить исходя из функций или из типов объектов.

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

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

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

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

[x].При ОО-конструировании ПО структура системы основывается на типах объектов, с которыми она работает.

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

[x].Чтобы проектируемое ПО было расширяемым и допускало повторное использование, ОО-конструирование должно выводить архитектуру из достаточно абстрактных описаний объектов.

[x].Между типами объектов могут существовать два вида отношений: "быть клиентом" и наследование.

Вопрос об ОО-декомпозиции рассматривается с использованием различных аргументов в [Cox 1990] (первоначально в 1986), [Goldberg 1981], [Goldberg 1985], [Page-Jones 1995] и [M 1978], [M 1979], [M 1983], [M 1987], [M 1988].