私は以下の方法の使用を提案したことで、何度か批判を受けました。
setPreferredSize()setMinimumSize()setMaximumSize()
コンポーネントについてSwing。表示されるコンポーネント間の比率を定義したい場合、これ以外の使用法は見当たりません。私は次のように言われました。
レイアウトに関しては答えは常に同じです。適切なものを使用してください。レイアウトマネージャー。
ウェブで検索しましたが、このテーマに関する包括的な分析は見つかりませんでした。そこで、次のような質問があります。
- これらの方法の使用を完全に避けるべきでしょうか?
- メソッドが定義されたのには理由があります。では、いつ使用すればよいのでしょうか? どのようなコンテキストで、どのような目的で使用すればよいのでしょうか?
- これらの方法を使用することで、具体的にどのような悪影響があるのでしょうか? (画面解像度が異なるシステム間での移植性が向上することしか考えられません)。
- どの LayoutManager も、必要なレイアウトのニーズをすべて満たすことはできないと思います。レイアウトの小さな変化ごとに、本当に新しい LayoutManager を実装する必要があるのでしょうか?
- 4 の答えが「はい」の場合、LayoutManager クラスが急増し、保守が困難になるのではないでしょうか。
- コンポーネントの子間の比率を定義する必要がある状況 (たとえば、child1 はスペースの 10%、child2 は 40%、child3 は 50% を使用する) では、カスタム LayoutManager を実装せずにそれを実現することは可能ですか?
ベストアンサー1
-
これらの方法の使用を完全に避けるべきでしょうか?
アプリケーション コードの場合は、はい。
-
メソッドが定義されたのには理由があります。では、いつ使用すればよいのでしょうか? どのようなコンテキストで、どのような目的で使用すればよいのでしょうか?
わかりません。個人的には、これは API 設計上の事故だと考えています。複合コンポーネントが子のサイズについて特別な考えを持っているため、多少強制されています。「少し」というのは、カスタム LayoutManager を使用してニーズを実装する必要があったためです。
-
これらの方法を使用すると、具体的にどのような悪影響があるのでしょうか? (画面解像度が異なるシステム間での移植性が向上することしか考えられません。)
いくつかの（不完全で、残念ながらSwingLabsからjava.netへの移行によりリンクが壊れている）技術的な理由については、例えばルール（笑）またはリンク@bendicottはコメントで私の答え社会的には、コードを保守し、壊れたレイアウトを追跡しなければならない不幸な仲間に、大量の作業を押し付けることになります。
-
どの LayoutManager も、必要なレイアウトのニーズをすべて満たすことはできないと思います。レイアウトの小さな変化ごとに、本当に新しい LayoutManager を実装する必要があるのでしょうか?
はい、「すべてのレイアウト ニーズ」に非常に近いものを満たすのに十分な強力な LayoutManager があります。主な 3 つは、JGoodies の FormLayout、MigLayout、DesignGridLayout です。したがって、実際には、単純で高度に特殊化された環境を除いて、LayoutManager を作成することはほとんどありません。
-
4 の答えが「はい」の場合、LayoutManager クラスが急増し、保守が困難になるのではないでしょうか。
（4の答えは「いいえ」です。）
-
コンポーネントの子間の比率を定義する必要がある場合 (たとえば、子 1 はスペースの 10%、子 2 は 40%、子 3 は 50% を使用する)、カスタム LayoutManager を実装せずにそれを実現することは可能ですか?
ビッグ スリーのいずれも、GridBag さえもできません (実際に習得しようとしたことがなく、パワーが足りないのに手間がかかりすぎます)。