Здравствуйте, adontz, Вы писали:
A>Здравствуйте, maugli71, Вы писали:
M>>Чем например хуже объект который может сам себя записать/считать в поток/файл, прорисоваться используя определенную реализацию графики и наконец реализует метод типа PtInObject для перетаскиваний? Не могу я так быстро поменять свою точку зрения )))
A>Ничем. Просто есть такое понятие — инкапсуляция. Всё что тебе не нужно — тебе не должно быть видно. A>В принципе объекты унаследованные от visual_object_base вполне могут реализовывать методы draw и is_point_in_object, но только чтобы пользоватся этими объектами совершенно не объязательно о них знать. и объект line тоже может реализовывать методы read(istream &) write (ostream &), но они не нужны visual_object. A>Я просто отделил данные от представления. Код в конечном итоге станет чище. A>Подумай сам, если графика векторная, то рано или поздно ты столкнёшься с группой объектов. Для группы is_point_in_object это логическое или над вызовами is_point_in_object для каждого члена группы. Всю эту логику вполне можно скрыть в draw_manager.is_point_in_object который сам разберётся object это группа или простой объект или ещё что-то, а не вываливать её наружу.
а что здесь наружу вываливается? Группа — это классический composite, а вот draw_manager тут совсем непричем...
И всетаки непонятно где хранить атрибуты фигуры. Инкапсуляция, полиморфизм это все конечно красивые и умные слова. А вот напрмер в функции API ExtCreatePen куча параметров и где их хранить? в самой фигуре? Тогда нарушается абстракция — фигура зависить будет от реализации.
Здравствуйте, loki1000, Вы писали:
L>А данные фигур хранить в самих фигурах (инкапсуляция, понимаешь ли )
Ну нифига. Так делать нельзя и вот почему.
Механизм перерисовки для пары тройки фигур будет отрабатывать идеально. Проблемы начнутся, когда в редакторе будут несколько десятков-сотен фигур. Проблемы будут недецкие:
1) Отжирание памяти при создании очередной новой фигуры.
2) Медленность процесса отрисовки каждой отдельной фигуры.
Лучше использовать паттерн Flyweight (Приспособленец), когда фигура одна, а отрисовывается по-разному с помощью параметров, находящихся в твоём хранилище — рисунке.
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, loki1000, Вы писали:
L>>А данные фигур хранить в самих фигурах (инкапсуляция, понимаешь ли ) ZEN>Ну нифига. Так делать нельзя и вот почему. ZEN>Механизм перерисовки для пары тройки фигур будет отрабатывать идеально. Проблемы начнутся, когда в редакторе будут несколько десятков-сотен фигур. Проблемы будут недецкие: ZEN>1) Отжирание памяти при создании очередной новой фигуры. ZEN>2) Медленность процесса отрисовки каждой отдельной фигуры.
ZEN>Лучше использовать паттерн Flyweight (Приспособленец), когда фигура одна, а отрисовывается по-разному с помощью параметров, находящихся в твоём хранилище — рисунке.
Но если параметры фигуры хранить в объектах то никакой выгоды не получу от Приспособленца. Будет столько же объектов сколько и фигур + приспособленцы добавятся. Другое дело если данные хранить в обычных структурах. Так получается? И отжирание памяти и медленность прорисовки будут в случае объектов а в случае структур нет?
Поставил эксперимент.
В первом случае использую шаблон Приспособленец. Shape родитель, Line и Rect потомки. При прорисовке параметрами им передаются указатели на структуры. В итоге создается N структур и 2 приспособленца.
Во втором случае использую просто объекты. Все данные находятся в самих объектах. В итоге создается N объектов. Имеем:
10 000 100 000
Flyweight <1сек <10сек
Объекты <1сек <10сек
Здравствуйте, maugli71, Вы писали:
M>И всетаки непонятно где хранить атрибуты фигуры. Инкапсуляция, полиморфизм это все конечно красивые и умные слова. А вот напрмер в функции API ExtCreatePen куча параметров и где их хранить? в самой фигуре? Тогда нарушается абстракция — фигура зависить будет от реализации.
Насколько я понимаю, тебе эти параметры предлагают действительно хранить в фигуре. Но, в фигуре являющейся визуальным объектом. А не в той фигуре которая, является частью исходной модели (рисунка). Если я правильно понял, о чем тебе говорит adontz. Как вариант, можно об этом чуть-чуть подробнее посмотреть в документации на Stingray Studio (в разделе 8.4.2, кажется)(Кажется документация у них доступна http://www.roguewave.com/support/docs/stingray/sflug.pdf).
)
