私は顧客管理ソフトウェアを作っています。多くのコンテンツを含むJPanelがいくつかあり、データベースと常に通信しています。データベースには、顧客データ、製品などがあります。
データベースデータにすばやくアクセスするために、最初にすべてを独自のArrayListにロードしますArrayList<Customer>
。ユーザーがこのデータを変更する場合は、クラスとデータベースの両方で変更する必要があります。
JPanelView
は非常に「フル」に見えるので(他のJPanelとJTabbedPanesで詰め込まれ、CardLayoutで切り替えます)、すべての「メイン」JPanelに対して独自のクラスを作成し、それらすべてをにリンクする方がよいと思いましたView
。
たとえば、JPanelの独自のクラスではCustomer
、すべての顧客データを表示および編集できます。製品などでも同じです。
意味がありますか、それとも不便ですか?私は、コードをアウトソーシングし、クラスをより明確にするために、特にそうすることだけを望んでいますView
。
この問題に対処するデザインパターンのようなものはありますか?
2 に答える
では、プログラムはJPanelをサブクラス化し、UIで使用される他のすべてのコンポーネントへの参照を含む単一のクラスで構成されていますか?そして、そのUIの一部を他のクラスに分割する必要があるかどうかを知りたいと思います。
要するにはい。コードの一部を新しいクラスに移動することで、任意のクラスをいつでも集約クラスに分解でき、元のクラスに新しいクラスへの参照を含めることができます。これは、委任または抽出クラスリファクタリングと呼ばれます。この手法については、MartinFowlerのリファクタリングの本で読むことができます。
CustomerPanelのように、UI全体の一部である他のUIを作成することは、それについて考える良い方法です。これを行うことで、UIの一部を切り離すこともできます。これらの小さなクラスを作成して、すべての依存関係を新しいクラスに移動する場合は注意が必要です。メインUIへの参照を集約されたクラスに戻したい場合は、クラスを完全に分離していない可能性があります。これは、抽出するクラスに十分な責任を与えていないか、共有する必要のある他の依存関係があることを示しているはずです。
基本的に、クラスを抽出する場合、そのクラスを含むクラスへの参照を含めるべきではないという規則があります。参照は、グラフというよりもツリーである必要があります。モデルクラスを共有することは問題ありませんが、ビュー間にサイクルを作成することはできません。
あなたはおそらくこれが面白いと思うでしょう: スイングのためのGUIガイドライン
あなたの意図を理解したかどうかはわかりませんが、特定のUIコンポーネントを外部委託して再利用できるレベルの分解を実現したいと考えているようです。基本的に、可能な限り低い結合を実現します。@chubbardが言ったこととは別に、MVPパターンを調べて、コンポーネントを参照するのではなく、コンポーネント間のイベントベースの相互作用を使用することをお勧めします。これにより、不要な依存関係を排除し、再利用性を高めることができます。