Как связно организовать модули для настольного приложения PyGTK?

Question

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

• application.py - содержит основной класс приложения (большинство функциональных подпрограмм)
• gui.py - содержит слабосвязанную реализацию графического интерфейса GTK. Обрабатывает обратные вызовы и т. Д.
• command.py - содержит функции автоматизации командной строки, не зависящие от данных в классе приложения
• state.py - содержит класс сохраняемости данных состояния

Пока это довольно неплохо, но на этом этапе application.py начинает работать довольно долго. Я рассмотрел множество других приложений PyGTK, и у них, похоже, есть схожие структурные проблемы. В определенный момент первичный модуль начинает становиться очень длинным, и нет очевидного способа разбить код на более узкие модули без ущерба для ясности и ориентации объекта.

Я рассмотрел вопрос о том, чтобы сделать GUI основным модулем и иметь отдельные модули для подпрограмм панели инструментов, подпрограмм меню и т. Д., Но в этот момент я верю, что потеряю большинство преимуществ ООП и получу ссылки на все все сценарий.

Стоит ли мне иметь дело с очень длинным центральным модулем или есть лучший способ структурировать проект, чтобы мне не пришлось так сильно полагаться на браузер классов?

РЕДАКТИРОВАТЬ I

Хорошо, так что точка взята относительно всего материала MVC. У меня есть грубая аппроксимация MVC в моем коде, но по общему признанию я, вероятно, мог бы получить некоторое расстояние, дополнительно разделив модель и контроллер. Тем не менее, я читаю документацию по python-gtkmvc (кстати, это отличная находка, спасибо за ссылку), и у меня сложилось впечатление, что она не решит мою проблему, а лишь формализует ее. Мое приложение представляет собой один файл glade, как правило, одно окно. Поэтому независимо от того, насколько точно я определяю роли MVC модулей, у меня все равно будет один контроллерный модуль, выполняющий почти все, что в значительной степени и сейчас. По общему признанию я немного неясен относительно правильной реализации MVC, и я собираюсь продолжать исследовать, но мне не кажется, что эта архитектура извлечет больше материала из моего основного файла, просто переименует это файл в controller.py.

Стоит ли думать об отдельных парах Контроллер / Просмотр для отдельных частей окна (панель инструментов, меню и т. Д.)? Возможно, это то, что мне здесь не хватает. Похоже, именно об этом говорит С. Лотт в своей второй статье.

Спасибо за ответы.

Answer 1

В проекте Wader мы используем python gtkmvc , что значительно упрощает применение шаблонов MVC при использовании pygtk и glade, вы можете увидеть организацию файлов нашего проекта в svn репозиторий :

wader/
  cli/
  common/
  contrib/
  gtk/
    controllers/
    models/
    views/
  test/
  utils/

Answer 2

Извините, что отвечаю так поздно. Kiwi кажется мне гораздо лучшим решением, чем gtkmvc. Это моя первая зависимость для любого проекта pygtk.

Answer 3

"содержит основной класс приложения (большинство функциональных подпрограмм)"

Как в единственном числе - один класс?

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

Что в этом огромном классе? Я полагаю, что вы, вероятно, можете сделать это по частям. У вас есть два варианта измерения для рефакторинга вашего класса приложения - если я действительно правильно понял, что вы поместили все в один класс.

1. Прежде чем делать что-либо еще, сделайте рефакторинг в компоненты, которые параллельны сущностям реального мира. Непонятно, что находится в вашем «state.py» - если это правильная модель сущностей реального мира, или просто сопоставления между постоянным хранилищем и некоторой мутной структурой данных в приложении. Скорее всего, вы перенесете обработку из вашего приложения в вашу модель (возможно, state.py, возможно, новый модуль, который является подходящей моделью).

   Разбейте свою модель на кусочки. Это поможет организовать элементы управления и просмотра. Самая распространенная ошибка MVC - слишком много контролировать и ничего не менять в модели.

2. Позже, когда ваша модель выполнит большую часть работы, вы сможете рассмотреть рефакторинг в виде компонентов, параллельных представлению в графическом интерфейсе. Например, различные фреймы верхнего уровня должны иметь отдельные объекты. Непонятно, что находится в «GUI.py» - это может быть правильным представлением. Похоже, что отсутствует компонент управления.

Answer 4

Скорее всего, это не имеет ничего общего с PyGTK, а скорее является общей проблемой организации кода. Вы, вероятно, выиграете от применения некоторых шаблонов проектирования MVC (Model-View-Controller). См., Например, Шаблоны проектирования .

Answer 5

Так что, не услышав о моей правке на исходный вопрос, я провел еще несколько исследований и пришел к выводу, что да , я должен разбить интерфейс на несколько представлений каждый со своим контроллером. Python-gtkmvc предоставляет такую ​​возможность, предоставляя параметр glade_top_widget_name конструктору View. Все это, кажется, имеет большой смысл, хотя для этого потребуется большой рефакторинг моей существующей кодовой базы, который я могу или не могу предпринять в ближайшем будущем (я знаю, я знаю, я должен .) Кроме того, у меня остается вопрос, должен ли у меня быть только один объект Model (мое приложение довольно простое - не более двадцати пяти переменных состояния) или мне следует разбить его на несколько моделей и получить иметь дело с контроллерами, наблюдающими за несколькими моделями и связывающими между собой уведомления. (Опять же, я знаю, что на самом деле должен сделать последнее.) Если у кого-то есть дальнейшее понимание, я все еще не чувствую, что получил ответ на первоначальный вопрос, хотя у меня есть направление сейчас же.

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

Answer 6

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

myapp/
  application/
  gui/
  command/
  state/

Где каждый каталог имеет свой собственный __init__.py. Вы можете взглянуть на любое приложение python или даже стандартные библиотечные модули для примеров.