2. Взаємодія об’єктів. Конкретизація алгоритмів і міжоб’єктних зв’язків.

Собственно, через взаимодействие и моделируется процесс решения задачи.

Каждый объект в модели существует и активен независимо от остальных объектов. Он реализует свой алгоритм обработки своих данных.

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

В нашем примере взаимодействие объектов происходит так:

Автомобиль создает пустой объект Граф путей и пустой объект Трасса.

Затем Автомобиль несколько раз вызывает метод Логики прокладки курса под названием Сформировать_Участок(G, i1, i2 ), где G - объект , а i1 и i2 - номера контрольных пунктов, между которыми прокладывается очередной участок трассы.

Логика прокладки курса при каждом вызове добавляет в Граф путей новые участки, обращаясь к объекту Карта за данными о местности и к объекту Автомобиль за параметрами машины. Если в авторалли участвуют несколько автомобилей, то Логика прокладки курса обслуживает каждого из них.

Когда Граф путей сформирован, Автомобиль вызывает его метод Проложить_путь( F, Трасса ), где F - ограничение на расход топлива.

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

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

3. Поняття алгоритмів і даних в інтерпретації об’єктної моделі.

Таким образом, понятие алгоритмов и данных в ООП заметно отличается от принятых в структурном программировании.

Теперь переменные и функции не «рассыпаны» по всей программе. Они объединены по принципу «близости» и «спрятаны» в объектах. Это реализация идеи модульности и инкапсуляции данных.

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

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

Заметим, что при реализации каждого отдельного алгоритма отдельного метода могут (и должны!) применятся принципы структурного программирования.

4. Принципи побудови об’єктної моделі.

Главный принцип, это рациональная группировка данных и методов.

Он реализуется на основе идеи уменьшения связи между элементами программы и разумного распределения ответственности между объектами.

Цитата:

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

Рассмотрим распределение ответственности на примере из жизни: отношения между менеджером и программистом.

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

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

Хотя пример описывает крайность, программисты очень часто допускают подобные ошибки при написании программ. Инкапсуляцию можно сравнить с умелым менеджером. Как и в жизни, знания и ответственность могут быть делегированы тому, кто знает, как выполнить работу наилучшим образом. Многие программисты структурируют свою программу подобно тому, как чересчур властные начальники обращаются со своими подчиненными.

Второй принцип - иерархическое построение модели.

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

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

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

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

Т ак, базовый класс «Движущийся объект» может включать в себя все, что касается собственно движения. Это текущие координаты, вектор скорости, ускорения, вид траектории (по прямой или по дуге с заданным центром), масса объекта и, возможно, ограничения на эти параметры. А также конструкторы, функции для доступа к этим параметрам, функции вычисления координат через заданный промежуток времени и т.п.

П роизводный класс «Наземный движущийся объект» отражает взгляд на движущиеся объекты, как «привязанные» к некоторой поверхности. Они могут произвольно изменять только координаты X и Y. Значение координаты Z при этом вычисляется в соответствии с рельефом поверхности и текущими координатами.

Производный класс «Автомобиль» отражает взгляд на наземные движущиеся объекты как на средства передвижения по дорогам, имеющие двигатель и управляемые водителем.

Производный класс «Грузовой автомобиль» отражает взгляд на автомобили как на средство перевозки грузов.

5