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

Question

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

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

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

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

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

EDIT Я

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

myapp/ 
    application/ 
    gui/ 
    command/ 
    state/ 

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

Answer 6

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