Читать онлайн «Основы объектно-ориентированного программирования». Страница 36

[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, и присоединим инвариант класса, точно определяющий природу отношения "быть клиентом". Так как инварианты классов выражаются с помощью логического языка, они покрывают намного больше различных отношений, чем может предложить подход сущность-связь или другие аналогичные подходы.

[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].

Метод проектирования сверху вниз отстаивается во многих книгах и статьях. Вирт [Wirth 1971] развил понятие пошагового уточнения.

Что касается других методов, то, по-видимому, наиболее близким является метод структурного проектирования Джексона JSD [Jackson 1983] и его расширение высокого уровня в [Jackson 1975]. См. также предложенный Варнье метод проектирования от данных [Orr 1977]. Для знакомства с методами, которые ОО-технология призвана заменить, смотрите книги по методу структурного проектирования Константина и Йордана [Yourdon 1979], по структурному анализу [DeMarco 1978], [Page-Jones 1980],[McMenamin 1984], [Yourdon 1989]; по методу Merise [Tardieu 1984], [Tabourier 1986].

Метод моделирования сущность-связь был введен Ченом [Chen 1976].

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

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

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

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

Это открыло мне глаза, я начал понимать, что значит использовать инструмент, называемый алгеброй. Черт возьми, никто никогда не говорил мне ничего подобного раньше. Мсье Дюпюи [учитель математики] произносил напыщенные фразы об этом предмете, но ни разу не сказал этих простых слов: это разделение труда, которое, как и всякое другое разделение труда производит чудеса и позволяет уму сконцентрировать все свои силы только на одной стороне объектов, только на одном из их качеств.

Насколько другим это предстало бы перед нами, если бы мсье Дюпюи сказал нам: "Этот сыр мягкий или твердый, он белый, он синий, он старый, он молодой, он твой, он мой, он легкий или он тяжелый. Из всех его многочисленных качеств давайте рассматривать только вес. Каким ни был этот вес, давайте назовем его A. А теперь, не думая больше о весе, давайте применять к А все, что мы знаем о количестве."