менеджер объектов

довольно часто встречуются задачи, в которых объект представляет собой лишь хранилище данных, а все действия должен производить менеджер. у меня нет чёткого представления о типичных методах их решения.
пример. нужно программно сгенерировать ШИМ сигналы на пинах контроллера.

Код (Text):

1. class CPwmPin
2. {
3. private:
4.   float m_val;
5.   uint *m_p_port;
6.   uint  m_pin;
7.  
8.   friend class CPwmManager;
9.  
10. public:
11.   void set_value(float val) {m_value = val;}
12. };

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

Код (Text):

1. class CPwmManager
2. {
3. private:
4.   CPwmPin *m_a_p_pins[10];
5.   uint m_current_pin;
6.  
7. public:
8.   CPwmManager()
9.   {
10.     init_timer(..);
11.   }
12.  
13.   void on_timer_event()
14.   {
15.    *m_a_p_pins[m_current_pin]->m_p_port |= m_a_p_pins[m_current_pin]->m_pin;
16.    m_current_pin ++;
17.   }
18. };

в подробности реализации не вдаюсь, думаю суть понятна.
вобщем мне никак не дают покоя детали реализации. понятно, что без PwmManager'a не обойтись, а вот стоит ли вообще создавать CPwmPin? ведь сам по себе объект ничего не представляет и конструкция, типа

CPwmPin *p_pin = new CPwmPin(..);

вообще косячная, т.к. реально никакого Pwm'a создано не будет (точнее не будет добавлено в менеджер, а, значит и работать не будет).

может быть лучше сделать что-то типа uint CPwmManager::create_pin(uint *p_port, uint pin) {..} который будет возвращать хендл созданного пина?

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

вобщем вариантов много, какой лучше - не знаю.

 

Это не объект, а просто кусок д...анных )

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

 

CPwmPin тут обычная структура. если ее использовать только в одном классе, всегда и только таким образом

то и оформлять ее именно так нужды нет.

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

класс, думаю, тут использован только заради

 

а объект это не кусок данных? вообще, не суть важно - объект это или структура.

и как тогда, интересно, поступить в данной ситуации?

вообще пример максимально упрощён. понятно что в реальности там будет не один member. тем не менее, для генерации шима нужен таймер, который генерирует шимы сразу на все пины. т.е. оснавная функциональность получается как-бы вынесена из самого CPwmPin'a в менеджер. с другой стороны CPwmPin всё-таки нужен - ведь он представаляет собой реальную сущность. именно ему нужно назначать конкретное значение, а не менеджеру.

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

 

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

На самом деле не обязательно все сущности отражать в объектной моделе. Вспомните идеи товарища Оккама

И при этом

Код (Text):

1. *m_a_p_pins[m_current_pin]->m_p_port |= m_a_p_pins[m_current_pin]->m_pin;

сразу же этот private нарушает ))

Собственно, к чему все и идет: физическая работа пина - CPwmPin (если имеются разные пины, напр, под разное оборудование), координация работы пинов - через менеджер