Агрегация

Другим основным видом отношений между классами и объектами является агрегация. Она означает, что один класс содержит в себе в качестве агрегатов (составных частей, подсистем) другие классы. Так автомобиль состоит из кузова, двигателя, трансмиссии и т. п., а в состав приемопередающего устройства входят передатчик, приемник и антенно-фидерное устройство. В UML агрегации обозначаются в виде линии с закрашенным ромбом на конце. Агрегация имеет кратность. Так автомобиль обычно содержит один двигатель, который в свою очередь может принадлежать только одному автомобилю. Автомобиль может обычно содержать от двух до пяти дверей. В свою очередь каждая дверь может принадлежать лишь одному автомобилю.

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

Пусть объект Е имеет методы f 1 () и f 2 () (рис. 2). Чтобы воспользоваться ими, надо сначала получить указатель на корневой объект А, затем на объект С, что в объектно-ориентированном программировании обычно записывается следующим образом: А.С

Далее получаем указатель на D, так как он является агрегатом С, и, наконец, вызываем требуемые методы f 1 () и f 2 ():

A.C.D.f1 ()

A.C.D.f2 ()

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

Рис. 2. Иерархическое представление вложенных объектов

Апология ооп

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

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

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

Рассмотрим принципиальные отличия реализации такой подсистемы с использованием методов структурного и объектно-ориентированного программирования. Кроме того, проанализируем трудоемкость расширения функциональности нашей подсистемы для случая структурного и объектно-ориентированного программирования. Рассмотрение начнем со случая использования структурной технологии.