0

各要素がラベル付きの JPanel の形式で視覚的表現 (ビュー) を持つデータ (モデル) のコレクションがあります。GUI ページを更新するメソッドは次のとおりです。

public void updateGUIPage(){
    guiPage.removeAll();
    for(MyElement element: myCollection) {
        guiPage.add(new VisualElementWhichExtendsJPanel(element);
        guiPage.add(Box.createVerticalStrut(10);
    }
}

updateGUIPage() は、コレクションが変更されるたびに呼び出されます。ご覧のとおり、既に作成されたビジュアル要素は削除され (書籍で知っているように、後でガベージ コレクターによって破棄されます)、コレクション内の各要素に対して新しいビジュアル要素が作成されます。この方法はあまり効果的ではありませんが、一般的にアプリケーションを非常に単純化します (多くの GUIPage があり、それらの多くは同じ要素を表示するため、2 番目の GUIPage に追加すると、最初の GUIPage から削除されます。それが Swing の仕組みです) では、問題は、アプリケーションでそのようなアプローチを許可するか、それとも追加の計算を行い、新しいオブジェクトの過剰な作成を避ける方がよいか (コレクションの平均サイズが 100 メンバーを超えることはめったにないことを考慮して) です。

4

2 に答える 2

2

assylias に完全に同意します。UI開発の経験 (GWT で 2 年以上) からも同じことがわかります。シンプルさを求めますが、パフォーマンスを測定して、アプローチの限界を確認してください。

于 2012-08-28T09:47:30.093 に答える
1

問題は、アプリケーションでそのようなアプローチを許可するか、または追加の計算を行い、新しいオブジェクトの過剰な作成を避ける方がよいか (コレクションの平均サイズが 100 メンバーを超えることはめったにないことを考慮して) です。

その答えは、新しいオブジェクトを作成するための相対的なコストとそれらを更新するためのコストによって異なります。そして、これらのコストが何であるかを確実に知る唯一の方法は、それらを測定することです。（そして関連する質問は、絶対的なパフォーマンスが「ヒット」するかどうかです。これをより遅い方法で行うことは、実際の違いを生むのに十分です...）

ただし、これは時期尚早の最適化のケースのように思えます。アプリケーションをより簡単な方法で実装し、そのパフォーマンスを確認する方がよいと思います。遅すぎる場合は、プロファイリングして、実際のパフォーマンスのボトルネックがどこにあるかを判断します。プロファイリングにより、このメソッドが重大なボトルネックであることがわかった場合は、それについて何かを行うことを検討してください。それ以外の場合は、そのままにしておきます。

于 2012-08-28T09:51:09.033 に答える