1

Swingクラスはサイズが大きくなる傾向があります。特に、多くの機能を備えたページを作成する場合は、常に複雑なコード、メンテナンスの悪夢につながります。

今、私は、ビジネスロジックが分離された場合、それらのクラスの多くが大幅に縮小することを理解しています。

私が知りたいのは、スイング要素をコンポーネント化して、より単純なビルディングブロックでページを構築する方法です。すべてのページで多くのことを実行し、いくつかのクラスで数千行に達しないサンプルアプリケーションはありますか？UIコードを分割するために提案するテクニックはありますか？

4

2 に答える 2

2

Humble dialogboxの記事で説明されている手法は、最初はかなり適切であることがわかりました。また、テストを大幅に容易にしました。

于 2012-08-03T12:42:54.777 に答える
2

相反する要件を与えていることに気付きましたか?

  • すべてのページで多くのことを行います
  • 何千行にも及ばない

多くの機能がある場合、その機能を実行するために多くのコードが必要になりますか? 多くの場合、ユーザー インターフェースは簡単ではありません。

  • 美しく論理的なレイアウト
  • 現在の UI 状態に応じてコンポーネントを有効/無効にする
  • ユーザー入力を検証する
  • 舞台裏で一部のモデルとデータを交換する

これには当然、UI 要素ごとに数行、場合によっては多数のコードが必要です。(コード行は、ここでは文字どおりに解釈する必要はありません。XML などで動作するフレームワークを使用している場合は、ある種のメタコードである可能性もあります)。

抽象的に言えば、あなたができる唯一のことは、その混乱を論理的に整理することです。さまざまなタスクを明確に分離します。これは、動作全体を各 UI 要素に抽象化するか (通常、このアプローチは、各コンポーネントの特殊なサブクラスまたはコンポーネントと動作の複合体につながります)、または各懸念事項を個別のクラス (たとえば、すべてのコンポーネント、ただし有効化/無効化、検証、およびデータ バインディングは異なるクラスに分けられます)。

どちらのアプローチも実際にはコードの量を減らすわけではありませんが、1 つのクラスに入れるコードの量を制限します。

最後に、多くの場所で見つけた共通/類似のコードを除外します (既存のコードのメッシュが既にある場合の「救済」アプローチ)。

于 2012-08-03T13:02:20.920 に答える