Вызов методов приложения из класса фреймов wx

Question

Я начинаю с wxPython и прорабатываю каждый учебник и пример, который могу достать. Однако я столкнулся с небольшой проблемой, которая связана с wx.App, а не с wx.Frame, которая должна содержать конкретные методы. Почти все примеры, которые я видел, не выходят за рамки макетов / классификаторов и обработки событий, ни один из них не касается организации проекта wxPython.

Например, у меня есть метод, который получает список папок. Большинство примеров справятся с этим - прикрепить метод прямо в классе фрейма. Этот метод потенциально может быть использован в нескольких других частях приложения, поэтому было бы разумнее хранить его на уровне класса приложения.

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

UPDATE:

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

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

Answer 1

Я, наверное, должен был быть намного яснее с самого начала, но я нашел то, что искал:

http://wiki.wxpython.org/ModelViewController/

Покопавшись в wxpython wiki, я нашел несколько простых, конкретных примеров проектов MVC.

Answer 2

Как сказал Марк, вы должны создать новый класс, который будет обрабатывать подобные вещи.

Идеальной компоновкой кода при использовании чего-то вроде wxWidgets является контроллер представления модели, в котором класс wxFrame имеет только код, необходимый для отображения элементов, а все логические и бизнес-правила обрабатываются другим классом, взаимодействующим с wxFrame. Таким образом, вы можете изменить логику и бизнес-правила без необходимости менять интерфейс и менять (или менять) интерфейс без необходимости менять логику и бизнес-правила.

Answer 3

Ваши классы, которые наследуются от типов данных wxWidgets / wxPython, не должны реализовывать какую-либо бизнес-логику. wxWidgets - это библиотека GUI, поэтому любые подклассы wxApp или wxFrame должны оставаться сосредоточенными на GUI, то есть отображать интерфейс и реагировать на действия пользователя.

Код, который делает что-то полезное, должен быть отделен от wx, так как вы можете позже решить использовать его в каком-либо веб-приложении или консольном приложении, и вы не хотите создавать объект wxApp в таком случае. Позже вы также можете решить перенести некоторые вычисления в отдельные «рабочие потоки», в то время как ваш графический интерфейс будет реагировать на «основной поток» и перерисовываться должным образом во время длительных вычислений.

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

Хотя их разделение приводит к чистому коду, когда вы не смешиваете ошибки в логике с ошибками в графическом интерфейсе (обновление / макетирование / индикатор выполнения и т. Д.). У такого подхода есть еще одна приятная особенность - возможность распределять работу между людьми с графическим интерфейсом и людьми с логикой, которые могут выполнять свою работу без постоянных конфликтов.

Answer 4

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