Подход к дизайну в программе со многими экранами GUI - PullRequest
Новая
       22

Подход к дизайну в программе со многими экранами GUI

1 голос
/ 23 марта 2011

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

В двух словах:

1) Существует много графических экранов (окон), каждый экран - это класс, определенный в своем собственном .cpp с сопровождающим заголовком .h с общедоступными и частными замедлениями.

2) Я использую инструментарий FLTK GUI, поэтому, когда я покидаю экран, я вызываю на нем «hide ()», который, как я предполагаю, выполняет сборку мусора, а затем я создаю новый экземпляр любого экрана, которому нужно следовать .

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

т. Псеводокод для экрана A 

#include "screenb.h"

ScreenB* screenb_ptr; // global

...
Bunch of Code, constructors, deconstructors, etc
...

void ScreenA::exit_and_make_screen_b()
{
    ScreenA.hide();
    screenb_ptr = new ScreenB();
}

Это лучший подход? Я чувствую, что это небрежно (и утечка памяти?), И у меня должно быть что-то вроде фиктивного .cpp / .h, который отслеживает кучу внешних квалифицированных указателей; тем более, что иногда мне приходится переходить назад / вперед на экраны (т. е. можно переходить к экрану главного меню с нескольких других экранов). Любой совет приветствуется!

Ответы [ 2 ]

2 голосов
/ 23 марта 2011

Вот несколько предложений:

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

Например: 

screenManager->NavigateScreen( SCREEN_USER_PROFILE );

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

1 голос
/ 23 марта 2011

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

Хорошим методом для графического интерфейса является архитектура Model-View-Controller.где у вас есть контроллер для управления графическим интерфейсом по мере необходимости.

Это будет проявляться в следующем виде: 

WindowManager wm;

void ScreenA::exit()
{
        wm.registerExit(screenb_ptr);
        wm.actOnExit();
}

Или что-то подобное, чтобы иметь центральный оркестратор окон.Это позволяет:

  • Сменные интерфейсы
  • Лучшая организация
  • Защита от ошибок
...