Должна ли логика программы находиться внутри класса объектов GUI или быть внешней по отношению к классу? - PullRequest
Новая
       13

Должна ли логика программы находиться внутри класса объектов GUI или быть внешней по отношению к классу?

4 голосов
/ 22 февраля 2011

У меня вопрос о том, как структурировать код относительно объектов GUI.Предположим, у меня есть диалоговое окно, в котором есть элемент управления списком, содержащий набор имен, полученных из базы данных.Пользователь может редактировать имена.Находится ли логика внутри этого диалогового класса или она должна быть снаружи.Чтобы проиллюстрировать, что я имею в виду, вот некоторый псевдокод, показывающий структуру кода, когда логика обрабатывается вне класса диалога: 

NamesDialog : wxDialog
{
  Private:
    ..stuff..
  Public:
    ...
    SetNames(wxStringArray names);
    wxStringArray GetNames();
    ..stuff..
}

Таким образом, пользователь класса будет делать что-то вроде: 

wxStringArray names = DatabaseManager::Get()->GetNames();
names.Sort();
NamesDialogObject.SetNames(names);
NamesDialogObject.ShowModal();
wxStringArray modified_names = NamesDialogObject.GetNames();
AddToDatabase(modified_names); //or something like this.

С другой стороны, логика базы данных может находиться внутри самого класса NamesDialog.В методе show я могу запросить в базе данных имена, и, когда пользователь взаимодействует с элементами управления (в данном случае это элемент управления списком), база данных может обновляться из обработчиков событий.В результате класс NamesDialog имеет только метод Show (), поскольку нет необходимости использовать SetNames или GetNames () и т. Д.

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

Ответы [ 3 ]

3 голосов
/ 22 февраля 2011

Попробуйте MVC для размера.

2 голосов
/ 22 февраля 2011

Существует несколько похожих подходов при разработке графической программы:

Хорошо, последний шутка.

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

0 голосов
/ 22 февраля 2011

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

  • Декоррелируя действие, вы можете использовать его повторно. Несколько элементов управления могут повторно использовать одно и то же действие (например, «Сохранить»: «CTRL + S», «Файл»> «Сохранить», «Файл»> «Сохранить как»), и его также можно запускать из командной строки / сценариев.
  • Графический интерфейс должен быть отзывчивым, вы не хотите, чтобы он зависал, потому что он что-то передает в / из базы данных, поэтому вы хотите выполнить «действия» в другом потоке.

Общий способ программирования - передача сообщений / обработка событий. Графический интерфейс отправляет и получает события / сообщения, и работа фактически выполняется одним (или несколькими) фоновыми потоками.

Типичной моделью является MVC (Model-View-Controller), но есть и другие подходящие альтернативы, поэтому не зацикливайтесь на этом.

...