Нужен совет по организации классов

>Компановщик
Иерархия три уровня - плохая, негодная иерархия.

соединения между объектами

Равноправный объект из набора

«Иерархия три уровня - плохая, негодная иерархия.» а чтобы вы посоветовали? что не так?

Да. На С++ интерфейсы недоступны, вот и приходиться извращаться с множественным наследованием... :)

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

1. Классы объектов - путь проиходят от одного суперкласса (абстрактный класс или интерфейс) // 2 уровня
2. Разделяйте обязанности - рисуют одни объекты (draw), форму хранят - другие. С геометрией работают (isinsidepoint) - третьи.

Навскидку получится:
CAbstractFigure <- (CEllipse, CRect, CLine, CComposite)
^
CAbstractDraw <- (CEllipseDraw, CRectDraw, CLineDraw)

Ну и там еще по мелочи.

Так можно иметь фигуру, к которой можно на клик мыши подцеплять «на лету» слегка другой AbstractDraw, который будет играть роль маркера...

Как только придет понимание того факта, что ключевое слово interface по сути - class без состояния с одними лишь абстрактными методами, тогда
на С++ интерфейсы внезапно станут доступны.

// Заметь, я не утверждаю _полную_ бесполезность множественного наследования. Им _можно_ пользоваться, коль ты _не пионер_.

и, да - у ТС на картинке везде одиночное...

>Хотел бы услышать какие-то советы: как организовать маркеры

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

Компановщик

Это не паттерн, а поттерн.

//wfrr

Книжка есть, почитаю... Спасибо

Компановщик

Это не паттерн, а поттерн.

это стёб?

>это стёб?

не это я так к совести модераторов из бана взываю.

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

//wfrr

В книжке «„Приёмы объектно-ориентирванного проектирования. паттерны проектирования“ Гамма, Хелм, Джонсон, Влиссидес в переводе издательства Питер, 2001г. на стр. 115 описана организация необходимых вам классов с применением паттерна Factory Method.

и, да - у ТС на картинке везде одиночное...

При одиночном наследовании без интефейсов легко отнаследовать слона от бегемота. :))

> форму хранят - другие. С геометрией работают (isinsidepoint) - третьи.

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

s/приходиться/приходится

Совет: забудь про паттерны-поттерны. Они только мешают думать.

Маркеры можно отрисовывать в Draw, но тогда где-то нужно еще обрабатывать мышиные сигналы.

Соединения можно рассматривать как ребра графа, состоящего из элементов. А тут уже есть варианты по представлению такого графа.

Одного isInsidePoint может быть мало. Нужно еще по прямоугольной области. Плюс для эффективной работы нужно возвращать прямоугольные границы. Это позволит делать разбиение пространства для быстрого нахождения пересечения заданной прямоугольной области с элементами. А поскольку границы элемента зависят от его координат, то нужно уметь обрабатывать событие «Границы изменились» и перестраивать разбиение. За это лучше браться потом, но следует подготовить почву заранее.

> Иерархия три уровня - плохая, негодная иерархия.

Уровней иерархии должно быть столько, сколько требуется, а не эксплицитно «2 и точка». man ООД.

И что? Вот, человек нарисовал «столько, сколько требуется» - man OOD помогло? Пусть уж лучше учатся «2 и точку» рисовать (и одиночным наследованием обходиться).

>man ООД
Приведешь иерархию, такую, чтобы в ней 4-5 уровней было, и, самое главное, все эти уровни были именно «столько, сколько требуется» ?