Re: Вопрос по дизайну класса - C/C++

Пишу класс — менеджер визуальных свойств контрола. Этот класс будет хранить информацию о шрифте, цвете текста, цвете фона и подобных вещах. В приложении есть несколько контролов (одного типа), но с разными свойствами. Как лучше написать интерфейс для доступа и установки свойств ?

Example 1.

class ViewManager
{
public:

   COLORREF GetColorForControl_1 ();
   void     SetColorForControl_1 ();
    ...

   COLORREF GetColorForControl_N ();
   void     SetColorForControl_N ();

private;

  COLORREF m_crControl_1;
  ...
  COLORREF m_crControl_N;
}

Example 2.

class ViewManager
{
public:

   enum ControlType {e_1, e_2...e_N, e_Last};   

   COLORREF GetColorForControl_N (ControlType e);
   void     SetColorForControl_N (ControlType e);

private;

  COLORREF m_crControls [e_Last];
}

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

Спасибо

Здравствуйте, Аноним, Вы писали:
А почему нельзя сделать по-простому:

class ViewManager
{
public:

   COLORREF GetColorForControl ();
   void     SetColorForControl ();

private;

  COLORREF m_crControl;
}

и создать N объектов класса.

Здравствуйте, Аноним, Вы писали:

А>Пишу класс — менеджер визуальных свойств контрола. Этот класс будет хранить информацию о шрифте, цвете текста, цвете фона и подобных вещах. В приложении есть несколько контролов (одного типа), но с разными свойствами. Как лучше написать интерфейс для доступа и установки свойств ?

А>Example 1.

А>

А>class ViewManager
А>{
А>public:

А>   COLORREF GetColorForControl_1 ();
А>   void     SetColorForControl_1 ();
А>    ...

А>   COLORREF GetColorForControl_N ();
А>   void     SetColorForControl_N ();

А>private;

А>  COLORREF m_crControl_1;
А>  ...
А>  COLORREF m_crControl_N;
А>}
А>

А>Example 2.

А>

А>class ViewManager
А>{
А>public:

А>   enum ControlType {e_1, e_2...e_N, e_Last};   

А>   COLORREF GetColorForControl_N (ControlType e);
А>   void     SetColorForControl_N (ControlType e);

А>private;

А>  COLORREF m_crControls [e_Last];
А>}
А>

А>То есть в первом случае для каждого контрола свой отдельный интерфейс, во втором все делается через идентификатор. В первом более понятно, во втором надо иметь дело с enum и не забывать для какого контрола (идентификатора) выставляешь или запрашиваешь свойства.

А>Спасибо

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

Здравствуйте, Аноним, Вы писали:

А> COLORREF m_crControl;
А>}
А>[/ccode]
А>и создать N объектов класса.

Ситауция такая. Настройки все хранятся в базе данных. При загрузке программы менеджер читает все настройки, для всех видов контролов и читает один раз. Затем просто разные части программы запрашивают у него свои настройки.

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

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

А так , менеджер представления — Singleton паттерн. Когда запускается очередной диалог, но у этого менеджера запросит свои настройки и все.

Здравствуйте, Аноним, Вы писали:

Тогда использовать 2-й пример

class ViewManager
{
public:

   enum ControlType {e_1, e_2...e_N, e_Last};   

   COLORREF GetColorForControl_N (ControlType e);
   void     SetColorForControl_N (ControlType e);

private;

  COLORREF m_crControls [e_Last];
}

Но вместо enum'ов идентифицировать контролы по их хэндлам.
И не делать статического массива m_crControls, а добавить спец. фунции для динамического добавления/удаления контролов.

Здравствуйте, Аноним, Вы писали:

А>Пишу класс — менеджер визуальных свойств контрола. Этот класс будет хранить информацию о шрифте, цвете текста, цвете фона и подобных вещах. В приложении есть несколько контролов (одного типа), но с разными свойствами. Как лучше написать интерфейс для доступа и установки свойств ?

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

Здравствуйте, Centaur, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

А>>Пишу класс — менеджер визуальных свойств контрола. Этот класс будет хранить информацию о шрифте, цвете текста, цвете фона и подобных вещах. В приложении есть несколько контролов (одного типа), но с разными свойствами. Как лучше написать интерфейс для доступа и установки свойств ?

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

Бред!!! Всегда должна быть возможность настраивать те или иные параметры контрола, например то же шрифт.

Здравствуйте, megawatt, Вы писали:

M>Бред!!! Всегда должна быть возможность настраивать те или иные параметры контрола, например то же шрифт.

об этом и речь

контрол самописный, полностью конфигурируемый

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>> COLORREF m_crControl;
А>>}
А>>[/ccode]
А>>и создать N объектов класса.

А>Ситауция такая. Настройки все хранятся в базе данных. При загрузке программы менеджер читает все настройки, для всех видов контролов и читает один раз. Затем просто разные части программы запрашивают у него свои настройки.

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

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

А>А так , менеджер представления — Singleton паттерн. Когда запускается очередной диалог, но у этого менеджера запросит свои настройки и все.

По-моему в данном случае лучше подойдет паттерн flyweight. В классике GoF этот паттерн иллюстрируется примером текстового редактора.

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

См. подробнее здесь

Здравствуйте, Аноним, Вы писали:

M>>Бред!!! Всегда должна быть возможность настраивать те или иные параметры контрола, например то же шрифт.

Шрифт — может быть, в редких случаях.

А>об этом и речь

контрол самописный, полностью конфигурируемый

Если контрол самописный, он должен определиться, на какой стандартный контрол он хочет быть похож, и брать цвета с него. Не так много контролов, которые нельзя свести к прототипам «окно» или «кнопка».

Здравствуйте, Centaur, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

M>>>Бред!!! Всегда должна быть возможность настраивать те или иные параметры контрола, например то же шрифт.

C>Шрифт — может быть, в редких случаях.

А>>об этом и речь

контрол самописный, полностью конфигурируемый

C>Если контрол самописный, он должен определиться, на какой стандартный контрол он хочет быть похож, и брать цвета с него. Не так много контролов, которые нельзя свести к прототипам «окно» или «кнопка».

да не надо привязыватся на слово control. Это область, со своими параметрами. Параметры хранятся в базе данных. Таких областей несколько и у всех разне параметры. Кроме шрифта хранится еще расположение окна на экране, звуковые параметры (alerts) и много чего еще.

Здравствуйте, Аноним, Вы писали:

А>Пишу класс — менеджер визуальных свойств контрола. Этот класс будет хранить информацию о шрифте, цвете текста, цвете фона и подобных вещах. В приложении есть несколько контролов (одного типа), но с разными свойствами. Как лучше написать интерфейс для доступа и установки свойств ?

А>Example 1.

А>

А>class ViewManager
А>{
А>public:

А>   COLORREF GetColorForControl_1 ();
А>   void     SetColorForControl_1 ();
А>    ...

А>   COLORREF GetColorForControl_N ();
А>   void     SetColorForControl_N ();

А>private;

А>  COLORREF m_crControl_1;
А>  ...
А>  COLORREF m_crControl_N;
А>}
А>

А>Example 2.

А>

А>class ViewManager
А>{
А>public:

А>   enum ControlType {e_1, e_2...e_N, e_Last};   

А>   COLORREF GetColorForControl_N (ControlType e);
А>   void     SetColorForControl_N (ControlType e);

А>private;

А>  COLORREF m_crControls [e_Last];
А>}
А>

А>То есть в первом случае для каждого контрола свой отдельный интерфейс, во втором все делается через идентификатор. В первом более понятно, во втором надо иметь дело с enum и не забывать для какого контрола (идентификатора) выставляешь или запрашиваешь свойства.

А>Спасибо

Может хватит списка обьектов COLORREF(Ближе ко второму варианту)?

Здравствуйте, Аноним, Вы писали:

А>То есть в первом случае для каждого контрола свой отдельный интерфейс, во втором все делается через идентификатор. В первом более понятно, во втором надо иметь дело с enum и не забывать для какого контрола (идентификатора) выставляешь или запрашиваешь свойства.

Example 2.1

struct ViewManager
{
    COLORREF Color(const std::string & str);
    void     Color(const std::string & str, COLORREF clr);
private:
    std::map<std::string, COLORREF> m_colors;
};

+ Легче поддерживать, безопасность, расширяемость
— оверхэд

Здравствуйте, Pavel Chikulaev, Вы писали:

PC>Example 2.1

PC>

PC>struct ViewManager
PC>{
PC>    COLORREF Color(const std::string & str);
PC>    void     Color(const std::string & str, COLORREF clr);
PC>private:
PC>    std::map<std::string, COLORREF> m_colors;
PC>};
PC>

PC>+ Легче поддерживать, безопасность, расширяемость
PC>- оверхэд

Только я бы предложил ещё больше абстрагироваться.

Завести абстрактное хранилище свойств контрола, в котором будут методы Set/Get для любого нужного свойства, и которое умеет себя сохранять/считывать в/из строки БД.

Ну а во ViewManager просто предоставлять доступ к этому объекту по строке.

С уваженеим, Erop

	От:	Аноним
	Дата:	05.11.05 14:22
	Оценка:

	От:	Аноним
	Дата:	05.11.05 14:44
	Оценка:

От:	megawatt	http://ruby.inuse.ru
Дата:	05.11.05 15:25
Оценка:	+1

	От:	Аноним
	Дата:	05.11.05 15:28
	Оценка:

	От:	Аноним
	Дата:	05.11.05 15:44
	Оценка:

	От:	Pavel Chikulaev
	Дата:	06.11.05 11:52
	Оценка:	1 (1)