PyGTKデスクトップアプリケーションのモジュールを一貫して整理するにはどうすればよいですか？

StackOverflow https://stackoverflow.com/questions/216093

質問

私はPyGTKでデスクトップアプリケーションに取り組んでいますが、ファイル構成の制限に突き当たっているようです。これまで、プロジェクトを次のように構成しました。

  • application.py-主要なアプリケーションクラス（ほとんどの機能ルーチン）を保持します
  • gui.py-疎結合のGTK gui実装を保持します。シグナルコールバックなどを処理します。
  • command.py-アプリケーションクラスのデータに依存しないコマンドライン自動化機能を保持します
  • state.py-状態データ永続性クラスを保持します

これはこれまでのところかなりうまく機能しましたが、この時点でapplication.pyはかなり長くなり始めています。私は他の多くのPyGTKアプリケーションを見てきましたが、それらは同様の構造的な問題を抱えているようです。ある時点で、プライマリモジュールは非常に長くなり始め、明確さとオブジェクトの方向を犠牲にすることなく、コードをより狭いモジュールに分割する明白な方法はありません。

GUIをプライマリモジュールにし、ツールバールーチン、メニュールーチンなどに個別のモジュールを使用することを検討しましたが、その時点で、OOPの利点のほとんどが失われ、すべての参照が得られると考えています-すべてのシナリオ。

非常に長い中央モジュールを持つことに対処する必要がありますか、それともクラスブラウザにそれほど依存する必要がないようにプロジェクトを構造化するより良い方法がありますか？

編集

わかりましたので、MVCのすべての点に関して注意が必要です。コードにはMVCの大まかな近似がありますが、モデルとコントローラーをさらに分離することで、おそらくある程度のマイレージを得ることができます。しかし、私はpython-gtkmvcのドキュメントを読んでいます（これは素晴らしい発見です、それを参照してくれてありがとう）、私の印象はそれを単に形式化するほど問題を解決しないだろうということです。私のアプリケーションは、単一のgladeファイル、通常は単一のウィンドウです。したがって、モジュールのMVCの役割をどれだけ厳密に定義しても、ほとんどすべてを実行する1つのコントローラーモジュールを使用することになります。確かに、MVCの適切な実装については少し曖昧であり、調査を続けますが、このアーキテクチャがメインファイルから他のものを取得するようには見えません。ファイルをcontroller.pyに追加します。

ウィンドウの別々のセクション（ツールバー、メニューなど）に別々のコントローラー/ビューのペアを考える必要がありますか？おそらくそれがここで欠けているものです。これがS. Lottが2番目の箇条書きで言及していることのようです。

これまでの回答に感謝します。

役に立ちましたか？

解決

プロジェクトウェーダーでは、 python gtkmvc を使用すると、pygtkとgladeを使用するときにMVCパターンを簡単に適用できます。プロジェクトのファイル構成は svnリポジトリ：

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

他のヒント

これはおそらくPyGTKとは関係なく、一般的なコード編成の問題です。おそらく、いくつかのMVC（Model-View-Controller）デザインパターンを適用することで恩恵を受けるでしょう。たとえば、デザインパターンを参照してください。

＆quot;プライマリアプリケーションクラス（ほとんどの機能ルーチン）を保持します＆quot;

単数形のように-1つのクラス？

One Class Does Everything のデザインが機能していなくても驚かない。私がオブジェクト指向と呼ぶものではないかもしれません。機能が1つのクラスに積み上げられている場合、典型的なMVCデザインパターンに従うようには聞こえません。

この大規模なクラスには何がありますか？おそらくこれを断片にリファクタリングできることをお勧めします。アプリケーションクラスをリファクタリングするための2つの次元の候補があります。実際、すべてを単一のクラスに入れたことが正しいと推測した場合。

  1. 他の作業を行う前に、Real Worldエンティティに対応するコンポーネントにリファクタリングします。あなたの＆quot; state.py＆quot;に何が含まれているかは明確ではありません。 -これが実世界のエンティティの適切なモデルであるか、またはアプリケーション内の永続ストレージと一部の曖昧なデータ構造との間の単なるマッピングであるかどうか。ほとんどの場合、処理をアプリケーションからモデル（おそらくstate.py、適切なモデルである新しいモジュール）に移動します。

    モデルを分割します。コントロールとビューの要素を整理するのに役立ちます。最も一般的なMVCの間違いは、モデルにコントロールを入れすぎて何もしないことです。

  2. その後、モデルがほとんどの作業を行ったら、GUIプレゼンテーションに対応するコンポーネントのリファクタリングを検討できます。たとえば、さまざまなトップレベルフレームには、おそらく個別の制御オブジェクトが必要です。 「GUI.py」の内容が明確ではありません。 -これは適切なビューかもしれません。欠落しているように見えるのは、コントロールコンポーネントです。

ご回答が遅くなり申し訳ありません。 Kiwi は、gtkmvcよりもはるかに優れたソリューションのようです。これは、pygtkプロジェクトの最初の依存関係です。

Python 2.6は明示的な相対インポート。以前のバージョンよりもさらに簡単にパッケージを使用できます。 アプリをパッケージ内の小さなモジュールに分割することをお勧めします。 次のようにアプリケーションを整理できます。

myapp/
  application/
  gui/
  command/
  state/

各ディレクトリに独自の __ init __。py がある場所。どんなPythonアプリでも、例として標準ライブラリモジュールを見ることができます。

元の質問の編集についての返信がなかったため、さらに調査を行ったところ、結論ははいで、インターフェースをいくつかに分割する必要がありますそれぞれが独自のコントローラーを持つビュー。 Python-gtkmvcは、Viewコンストラクターに glade_top_widget_name パラメーターを提供することにより、この機能を提供します。これはかなり理にかなっているように思えますが、既存のコードベースの大規模なリファクタリングが必要になるため、近いうちに着手することもしないかもしれません（私は知っています、私は知っているべきです）。さらに、単一のModelオブジェクト（アプリケーションは非常に単純です。25個以下の状態変数）だけが必要なのか、それを複数のモデルに分割して、複数のモデルを監視し、それらの間で通知をチェーン化するコントローラーを処理する必要があります。 （繰り返しますが、私は本当に後者を行うべきです する必要があります。）さらなる洞察が得られたとしても、私はまだ元の質問に答えを得たとは感じません。今から向かう方向。

（さらに、今までMVCスタイルでコーディングされた単一のPythonアプリケーションを見たことがなかったので、彼らは他のアーキテクチャ上の選択肢であるように思われますが、多くのPythonアプリケーションには正確な問題がある傾向があります上記で説明しました。）

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top