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

Добавлено через 2 минуты и 49 секунд
мне самому жутко интересно, что же разрабатывается

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

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


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

тема постепенно превращаются в оффтопные мультимонологи   

на какой именно вопрос?


Я уже и не знаю о чем рассказать  
Как конечный пользователь будет использовать программу? Все что есть я описал.


Да


Да. А для тех, которые не поддерживают сгенерировать исключение.



Да.

Что еще нужно описать а не понимаю, Вы же все прекрасно понимаете.

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

Я же писал об этом несколько раз.


Вот оно.

mes

На Ваш предыдущий пост отвечу позже.

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

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

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

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

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

остальное отвечу позже

Это сообщение отредактировал(а) mes - 16.11.2011, 10:08

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

Добавлено @ 10:13
Я видимо очень плохо объясняю. Забудьте про интерпретаторы и команды.
Есть базовый класс geom, есть наследуемые от него разного рода геометрии. Есть predifined список операций, которые можно проводить с этими типами. Некоторые типы поддерживают все операции, некоторые нет. Например точка не поддерживает вращения, а полигон поддерживает.
Операции добавляются и изменяются чаще, чем сами типы, но необходимо оставить возможность добавлять новые типы, не изменяя исходников, так-как возможно добавление типов со стороны третьих лиц.
Все. Задача в этом, все остальное не важно. Вот все требования.

Это сообщение отредактировал(а) azesmcar - 16.11.2011, 10:14

есть разница какие интерфейсы требуются коммандеру, юзеру, или для отображения в меню.. 



Команда как действие у вас условно есть (то есть неважно физическое наличие, важно что мы знаем что команда может вызваться) и надо написать логику команды.. или так называемую связку, в которой как я и понимаю есть та загвоздка..

Добавлено @ 10:29

это была как раз не загружающая, а разгружающая деталь 

Добавлено @ 10:31

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

Добавлено @ 10:33
вот как раз три слоя и определились : 
коммандер, исполнитель, типы  ( условно C,B,A)

при этом концентрация на втором, с учетом третьего.. 


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

жду поправок 



Это сообщение отредактировал(а) mes - 16.11.2011, 10:54

Да.


Некоторые из них могут быть сохранены в текстовом виде, возможно в дальнейшем нужно будет добавить и другой формат. Насчет отрисовки - верно, но это нашей задачи не касается, отрисовкой мы не занимаемся, наша задача - editing.


Да.


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


Да.

Конкретно в приведенной мною реализации query interface мне не нравится один момент.
Придется заранее разбивать на мелкие интерфейсы, сгруппировать не получиться, так-как после группировки будет невозможно дальнейшее разделение.
Скажем я создал интерфейс i_editable - который поддерживает операции rotate и move, а потом у нас появился тип, который можно перемещать, но нельзя вращать и придется менять кучу кода, чтобы разделить rotate интерфейс от move-а. А в случае с наследованием интерфейсов можно разделить интерфейс на i_rotatable и i_movable, оставить интерфейс i_editable : i_rotatable, i_movable для поддержки старых реализаций.

Добавлено @ 11:24

EDA инструменты  

Это сообщение отредактировал(а) azesmcar - 16.11.2011, 11:25

А перекомпиляция исходников допускается? Если да, то описать все операции в виде класса с виртуальными методами (по 1 штуке на операцию) и телами, которые бросают исключение - 'not-implemented'. Отдать этот класс на растерзание пользователю, но унаследовать все ваши классы от него.

Да, это самое первое, что пришло на ум, но операций довольно таки много, интерфейс базового класса будет похож интерфейс класса std::string  
В общем-то решить можно по всякому, но разве это лучший из существующих вариантов?

azesmcar, вот теперь задача обрела очертания.. 

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

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

но это забегая вперед, а теперь вернемся к текущему : 


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

пример чуть позже.. 

это не понимание а телепатия 
я спросил про фрагмент if (is_reсtangle) cope_rectangle(); но в ответ получил то, что и так из этой строчки ясно

вот это понятно 


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

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

но это мелочи, обратимся к главной задаче: требуется независимо изменять набор типов и набор операций.
для этого надо сделать типы и операции независимыми, разделить их. концептуально это означает использовать visitor.
к сожалению, это ослабляет систему типов (мы используем внеязыковые средства), но упрощает разработку и сопровождение.
с академической точки зрения тут должен последовать совет о разработке проблемно-ориентированного языка, и в итоге для упрощения реализации мы придем к использованию пакета АОП, но я не столь жесток   
как реализовать?
возможность добавлять новые типы без перекомпиляции обеспечивает динамическая регистрация обработчика и карта(map) обработчиков. про это mes изложил подробно и разнообразно. в дополнение могу предложить перекладывание задачи регистрации на базовый интерфейс, типа

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

еще замечание. признаться, я не очень верю, что возможных команд очень много. с точки зрения пользователя может и много, но они наверняка классифицируются, и менеджер команд (о котором мы не говорим) в состоянии на выходе иметь ограниченный перечень.
так, например, команды преобразования move, scale, rotate etc суть одна функция transform, если для преобразований используются матрицы. тогда кстати и точку вполне можно вращать ;-)
далее, наверняка реализация команд для разных типов отличается, но этих отличий может быть не очень много и они, в свою очередь, тоже классифицируются. например, графический элемент может иметь ограничения на преобразования, связанные с его состоянием (заблокирован, "заморожен") и с состоянием связанных с ним объектов. с другой стороны, изменение элемента может повлечь изменение элементов, зависящих от него. тогда потребуется некая несложная архитектура выполнения команды типа
  


ясно. собственно на догадки меня навел пост, где присутствует команда move{0,2}, оч. похоже на всякие CADы


Это сообщение отредактировал(а) baldina - 16.11.2011, 17:09

Самое главное, что в этом базовом классе не будет ничего другого. Только интерфейсы. И их можно будет легко добавить, ничего больше не меняя

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

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


Пожалуй самый простой. Если устроит, то может и самый лучший   

ловите примеси  :
http://liveworkspace.org/code/98eac02abcba...b5316128ef8154a


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

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

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

кстати обратите внимание что самопонятие moveable (и ему подобные)  не являются типом и вообще исключены из рациона. 
и команда move реализуется на основе свойств.. 
Это позволяет минимизировать набор свойств и развязать руки при составлении команд.. 


вот одна из вариаций ручной ассоции типов :
http://liveworkspace.org/code/3b5206ae1eed...48112a18a4621b5

те части в которых произошли изменения :

другой подход можно позаимствовать из примера с коммандами (action_type ,  action_rawdata ( в роли идентификатора интерфейса )  )

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