mes,  В обоих ваших примерах нельзя определить несколько свойств одного типа, правда, в некоторых случаях можно вывернуться - для линии использовать pair<point,point>, для полигона - vector<point>.
И регистрировать в мутаторе лучше не объект, а геттер и сеттер.

Исходя из назначения (разводка печатных плат, как я понял), объекты делятся на две категории: примитивы (point, rect, line. circle, arc, polyline, polygon, path, text) - новые понадобятся редко, если нужно что-то новой формы - есть path.
Вешать на них интерфейсы, мутаторы и т.д. - не рационально, всё это займёт больше места, чем сам примитив.
Но если новые примитивы добавляются редко, можно применить visitor.
Компоненты высокого уроня: component, connection, lay
Новые компоненты создаются в редакторе компонентов, как правило, без создания новых классов C++ - здесь как раз мутаторы уместны. Но нужно иметь возможность динамического добавления свойств.

в QI нельзя получить два одинаковых интерфейса .. все зависит от задачи 
нужнен массив точек,определите такое свойство.. 


у геттера/сеттера нет типа.. нужен отдельный геттер/сеттер сделайте такой микс.. 

Добавлено через 1 минуту и 17 секунд

экономичность это следущий шаг.. пока я лишь показал какие еще варианты бывают 
чтоб не было зацикливания на imoveable 

Можно сделать так:

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

о каком типе идет речь ? я о том который вытупает в роли идентификара свойства/интерфейса

Вот такие типы:

это не позволяет определенно и однозначно соотнести тип к методу..

а тс. чего то не видно.. или это я такой нетерпеливый.. 

Это сообщение отредактировал(а) mes - 17.11.2011, 18:49

mes, вот определяется (добавить недостающие куски из Вашего примера):

Без typedef можно обойтись.

ну и ? увсех сеттеров типа void (*)(figure&,const int&), а их множество, будет один и тот же тип.. 
про ограничения на кол-во аргументов мы промолчим .. 
во вторых как будет выглядить пользователем получение это сеттера.. 
да и вообще зачем нам эти сеттеры ?   интерфейсы (мутаторы) намного более симпатичны.. на один ид  отражены сразу все необходимые методы в удобном и привычном виде..
 

Так и в Вашем примере для одного типа возможен один мутатор - устранение этого ограничения аналогично.


Ну вот нужно установить центр Rect. Поля Point center нет, а есть левый верхний угол. А если и есть, всё равно нужно сделать перерасчёт
левого верхнего угла, а если хранить и остальные углы -  то и их.

Чтобы уйти от сеттеров можно использовать паттерн Observer - это рентабельно, если будем его применять для объектов высокого уровня



Это сообщение отредактировал(а) math64 - 17.11.2011, 20:45

да, только как относится наблюдатель к нашей задачи по динамическому описанию любого типа фигуры ?
или вы уже следующую решаете ?


один мутатор/интерфейс про ид.. или множество про один ид  


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


Это сообщение отредактировал(а) mes - 17.11.2011, 23:56

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

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

не совсем так, возможно как хранение даных и/или воздействие тад ними, так и проксирование действия...  все зависит от выбранной модели.. 



ну я  вроде бы и написал:


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


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

Доброе утро.

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

Это сообщение отредактировал(а) azesmcar - 30.11.2011, 09:31