Ради одних преимуществ, Вы абсолютно потеряли другие, а ведь ничто не мешало пользоваться и тем и другим.

Начнем с того что Ваш_метод :
1. открывает приватные переменные и разрешает кому угодно что угодно с ними делать.
2. ведет к потери индивидуальности каждого класса
3. и при всем этом не предоставляет разделение операций от субъектов.


да использование внешних функций/функторов как прообраз операции это хорошо. Однако Ваш_метод затрудняет написание и поощряет опечатки.. 

Согласен, но, я писал этот код наспех, и использовал кругом структуры, тупо ради того, что-бы не писать private, protected, public в самих классах и при наследовании. Ну и поскольку это просто набросок, я не думал о том, какие переменные должны быть закрытыми, а какие нет, я просто сделал все открытым, что-бы мне было проще это все писать.


Что под этим имеется ввиду? Да, все классы будут сгенерированы компилятором,  то как они бдут работать можно настроить. А можно просто отнаследовать свой класс от Body, и сделать их него настоящую индивидуальность  


Совсем не сложно сделать метод draw - функцией, или реализовать тот-же самый паттерн visitor, но только для всего объекта, а не для его частей.


привиди пример, как бы ты это сделал, может я чего-то не понимаю...?

нее... Я не о том, что все через public написано.. это понятно что демонстрационное, а о том что все функции оперируют внутренним состоянием фигуры



вобщем возмущения 
 из за typedef :



из за пользования приватными знаниями :


опять из за typedef, что приведет к затруднению перегрузки:


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






оставить возможности Body только для сериализации и ей подобной.
получать типы фигур не typedef, a наследованием.
тайпдефить fusion::vector внутри класса фигуры, которой он принадлежит
и разгружать ее данные через функции.

т.е так 

ну а Inputer может быть привязан не к самим фигурам , а к их составляющем; но без допуска к внутренностям объекта.
например так:



Это сообщение отредактировал(а) mes - 20.3.2009, 21:37

я немного поковырял этот код, улучшил его, но не так как говорил mes  
в общем, я вынес всю шаблонную магию в отдельный класс, от которого можно наследовать
ф-ии DrawCircle, и DrawLine, теперь не получают ссылку на sequence, вместо этого они принимают обычный набор параметров, пользователь теперь может писать такие функции:

получать переменные класса можно так-же как и у boost::fusion::vector, с помощью at_c
класс GenericBody теперь выглядит намного проще

весь код я решил не выкладывать, вместо этого, код можно получить из моего репозитория на bitbucket - composite_object

Добавлено через 3 минуты и 17 секунд
ps
еще можно сделать так, что-бы конструктор composite_object-a принимал не ForwardSequence, а обычный набор параметров, а потом запаковывал его в последовательность
в идеале, пользователь класса не дожен вообще уметь пользоваться boost::fusion

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



в шаблонной магии тоже ничего не режет глаз, однако main.cc все так же и остался полон зависимостей и ограничений.
(не буду повторяться какие, потому что основные замечания описаны в предыдущем посте) 

Это сообщение отредактировал(а) mes - 22.3.2009, 00:55

эти ограничения не на пустом месте появились, за все нужно платить
в принципе, можно порождать новые классы с помощью наследования, а не typedef 

но писанины больше...


я не вижу каких-либо проблемм с typedef  

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

Добавлено через 33 секунды
зы
обновил код в репозитории, хотя изменений там мало

о производительности тут речи не шло  шло лишь об удобстве пользователя.



Наш спор в основном вызван тем, что Ваш_метод мы рассматриваем применительно к иерархии фигур. 
Дело в том что у примитивов фигур очень мало действительно общего, и обобщение на уровне их состояния (приватных данных) только вызывает путаницу.


да каркас класса придется писать ручками, но лично я считаю это, применительно к выше-обсуждаемой задаче, преимуществом.
Очень неудобно работать с одним и тем же интерфейсом с Линией, Углом, Трапецией и Кубом. 
Но это не мешает нам комбинировать их функции. Для этого достаточно разбить на двa условных уровня :
 функции/функторы и классы их использующее (как в принципе у Вас и обстоит дела с рисованием)



проблема не с typedef,  а с абсолютной унификацией (потерей индивидуальности) интерфейса (опять же оговорюсж, что лишь применительно к нашей задаче)


ну а как иначе.. просто из двух зол выбирают меньшее 

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

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

Как понял с помощью BodyAccessora ? ну и что вернет Ваш функтор применительно к окружности ?! ;)

это просто не удачный пример, вот и все

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

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

ну а  в общем мне кажется, что мы уже в принципе пришли к "общему знаменателю" по этой ветке темы



Это сообщение отредактировал(а) mes - 22.3.2009, 16:51