8

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

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

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

GUI を主要なモジュールにし、ツールバー ルーチン、メニュー ルーチンなどに個別のモジュールを用意することを検討しましたが、その時点で、OOP の利点のほとんどを失い、すべてを参照するすべてのシナリオになってしまうと思います。 .

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

編集私

わかりましたので、すべての MVC に関するポイントを取り上げました。私のコードには MVC の大まかな概算がありますが、モデルとコントローラーをさらに分離することで、ある程度の距離を稼ぐことができることは確かです。しかし、私は python-gtkmvc のドキュメントを読んでいます (ちなみに、これは素晴らしい発見です。参照していただきありがとうございます)。私のアプリケーションは 1 つのグレード ファイルで、通常は 1 つのウィンドウです。したがって、モジュールの MVC ロールをどれだけ厳密に定義しても、1 つのコントローラー モジュールでほとんどすべてを実行することになります。確かに、私は適切な MVC の実装について少し曖昧であり、調査を続けますが、そうではありません。

ウィンドウの個別のセクション (ツールバー、メニューなど) に対して個別のコントローラー/ビューのペアを検討する必要がありますか? おそらくそれが私がここで見逃していることです。これは、S. Lott が 2 番目の箇条書きで言及していることのようです。

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

4

6 に答える 6

7

プロジェクトWaderではpython gtkmvcを使用しています。これにより、pygtkとglade を使用するときに MVC パターンを適用するのがはるかに簡単になります。プロジェクトのファイル構成はsvn リポジトリで確認できます。

wader/
  cli/
  common/
  contrib/
  gtk/
    controllers/
    models/
    views/
  test/
  utils/
于 2008-10-19T07:39:33.587 に答える
2

遅く答えてすみません。Kiwiは、gtkmvcよりもはるかに優れたソリューションのように思えます。これは、pygtkプロジェクトに対する私の最初の依存関係です。

于 2008-10-31T01:31:40.560 に答える
2

これはおそらく PyGTK とは何の関係もありませんが、一般的なコード構成の問題です。いくつかの MVC (Model-View-Controller) 設計パターンを適用すると、おそらくメリットがあります。たとえば、デザイン パターンを参照してください。

于 2008-10-19T06:15:00.607 に答える
2

「主要なアプリケーション クラス (ほとんどの機能ルーチン) を保持します」

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

1つのクラスですべてを実行するという設計が機能していないことに、私は驚きません。それは私がオブジェクト指向と呼ぶものではないかもしれません。機能が単一のクラスに積み上げられている場合、典型的な MVC 設計パターンに従っているようには思えません。

この大規模なクラスには何がありますか？おそらくこれをバラバラにリファクタリングできることをお勧めします。アプリケーション クラスをリファクタリングするための 2 つの候補ディメンションがあります。確かに、すべてを 1 つのクラスにまとめたことが正しいと推測した場合です。

  1. 他のことを行う前に、実世界のエンティティと同等のコンポーネントにリファクタリングします。「state.py」の内容は明確ではありません。これが現実世界のエンティティの適切なモデルなのか、それとも永続ストレージとアプリケーション内のあいまいなデータ構造との間の単なるマッピングなのか。ほとんどの場合、処理をアプリケーションからモデル (おそらく state.py、適切なモデルである新しいモジュール) に移動します。

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

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

于 2008-10-19T12:53:42.110 に答える
0

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

myapp/
  application/
  gui/
  command/
  state/

各ディレクトリには独自の__init__.py. 例として、任意の python アプリまたは標準ライブラリ モジュールを見ることができます。

于 2008-10-19T06:41:46.667 に答える
0

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

(さらに、今まで MVC スタイルでコーディングされた Python アプリケーションを 1 つも見たことがなかったことを考えると、別のアーキテクチャを選択する必要があるように思われますが、多くの Python アプリケーションは、私が説明した正確な問題を抱えている傾向があります。その上。）

于 2008-10-20T20:15:32.567 に答える