Javaに関する様々な情報をご紹介します。

Javaに関する様々な情報をご紹介します。
評価

0

JPanelとJComponentの違いについて

JPanelとJComponentの違いをご教授して頂きたく投稿致しました。

双方の違いは以下のものだけと認識していますが、これ以外にもございましたら教えていただければ幸いです。

JPanelとJComponentの違い
・JPanelではPanel用の「Look & Feel」設定できる。

23

回答

9236

閲覧

23件の回答

評価

0

オブジェクト指向について勉強しましょう。
せめて、継承、拡張、多態性くらいについては、言葉だけでも知っておきましょう。

>双方の違いは以下のものだけ

んなアホな・・・。orz

今すぐ忘れなさい。
こんなもんを違いなどと認識していては、後々障りますよ。

評価

0

不良社員さん回答して頂きありがとうございます。
自分の言葉が足りなかったようです。申し訳ありません。

双方を継承したそれぞれのクラスをコンテナに追加した際の機能的な違いについてアドバイスを頂こうと思っていたのです。

JPanelがJComponentを継承していることは知っています。
しかし、JPanelで新たに追加されたメソッドが6つのみなので、JPanelでなくても充分なのではないかと思ったのです。

今のところ自分が発見した違いは
・JPanelではPanel用の「Look & Feel」設定できる。
・JComponentではsetBackground(Color color)メソッドを呼び出しても視覚的な変化は発生しない
ということだけで、JPanelを継承したクラスを設計する利点が分からないのです。

評価

0

とりあえず、俺の投稿はスルーされたということで。

評価

0

これだけとなんだから、いくつか書いておく。

スレ主さんは、継承というものを、
コードの再利用という観点からしか評価していないが、
オブジェクト指向においては、そんなものは些細なものなのだ。

API Documentの、JComponentの項の一番最初に、以下のようにある。

「トップレベルのコンテナを除く
すべてのSwing コンポーネントの基底クラスです。」

言い換えると、
「主要なSwingコンポーネント群における、Objectクラスのようなもの」
と、いうべきものだ。

機能の多寡など問題ではない。

評価

0

>・JComponentではsetBackground(Color color)メソッドを呼び出しても視覚的な変化は発生しない

あれ? JComponentは、抽象クラスのはずだが。

もしかして、
JPanelをJComponentにキャストしてから、setBackground()を叩いたのか?

評価

0

すいません。。。
まだここに慣れていなくて。。。

>せめて、継承、拡張、多態性くらいについては、言葉だけでも知っておきましょう。

JPanelがJComponentを継承していることは知っています。
しかし、自分の認識が正しいとは限らないので確認して頂けると嬉しいです。

継承は他のクラスの一部のメソッドとフィールドを受け継ぎ、メソッドをオーバーライドすることで継承元のクラスとは別の振る舞いをすることができる。
また、そのクラスでは処理を確定できないメソッドを抽象メソッドにすることで無理矢理に多態性を持たせることができる。
そのようなクラスを抽象クラスといい、振る舞いが決定していないメソッドがあるためにインスタンス生成が行えない。
例としては、ユーザの入力により処理されるメソッド内等で抽象メソッドを呼ぶことで、継承先クラスでは最低限のソースを書くだけで済む。
また、自作のライブラリを他人に使ってもらう時、記述するべき処理を明示的に知らせることができる。
インターフェースでは実装先のクラスで必須なメソッドを抽象メソッドとして宣言できる。
例としては、コンポネントのサイズが変更できることを記述したインターフェース「SizeChangable」作成をすると、SizeChangable型の変数には、継承的に無関係なクラスでも代入することができて便利。

だったということでお願いします。

評価

0

>もしかして、
JPanelをJComponentにキャストしてから、setBackground()を叩いたのか?

JComponentを継承したクラスのコンストラクタでsetBackground()を叩きました。
結果、背景色は変更されませんでした。
しかし、getBackground()を呼ぶと確かに、setBackground()で引数に渡したColorクラスが返ってくるんです。

評価

0

>機能の多寡など問題ではない。

全く持ってその通りだと思います。
ただ、参考書や参考サイトで「JFrame」に追加するコンポネントは「JPanel」と記されていることが多いのは何故かと気になってしまったのです。。。

評価

0

>JComponentを継承したクラスのコンストラクタでsetBackground()を叩きました。
>結果、背景色は変更されませんでした。

Swingのコンポーネントってのは、
JComponentをextendsしておしまい、じゃないんだよ。
モデルやレンダラなど多数のオブジェクトで構成されている。
JPanelも同様。
JComponentは、JPanelと比べると、
すっぴんなコンポーネントってわけだ。しかも、抽象クラス。

2010-11-07 23:48 を読んで思うことだが。

スレ主さんは、コード記述上のお約束としての知識は持っているが、
オブジェクト指向そのものは理解していないんじゃないかな。
抽象クラスやインターフェースが、
なんか、オマケみたいな扱いだね・・・。

評価

0

>スレ主さんは、コード記述上のお約束としての知識は持っているが、
>オブジェクト指向そのものは理解していないんじゃないかな。

理解の足らないところを知り、より理解を深めたいを思っています。
差し支えなければ、自分が理解できていない部分を指摘して頂けると大変助かります。

評価

0

まず、それぞれのクラスがどういうものかは、ソースを見て理解するのではなくそのクラスの役割を考えるべきだということは分かってるんだろうか。
逆に言うと、ソースを見るのはそのクラスの役割を知るためではなく、あくまでその役割を実現するにあたって現時点でどうしているかを調べるためだけの話。

評価

0

足りないところを指摘する云々というレベルじゃなさそうだ。
コーディング時の、小手先のテクニックのことをいってるんじゃないよ。念のため。

掲示板のコメント欄で片付くようなことじゃないよ。
最初に戻って、オブジェクト指向について
勉強しましょう、ってことになる。

サイトでも本でも、いろんな人が書いているから、
まずはそれを読んでみましょう。
Wikipediaにも、項があるしね。
http://ja.wikipedia.org/wiki/オブジェクト指向

評価

30

> オブジェクト指向そのものは理解していないんじゃないかな。

ずいぶんと偉そうに書いているけど、不良社員さんも Java の継承、拡張、多態性について理解できていないのでは?

> もしかして、JPanelをJComponentにキャストしてから、
> setBackground()を叩いたのか?

C++/C# と異なり仮想関数しか存在しない Java では、どのようなアップキャストをおこなおうとも、実行時クラスが JPanel であれば、JPanel の setBackground() が呼ばれますよ。

背景色が変わらないというのは、JComponent を継承しただけの簡単な自作サブクラスのことだというのは考えればすぐに分かるはず。

> JPanelとJComponentの違い
> ・JPanelではPanel用の「Look & Feel」設定できる。

質問者の理解は概ね正しいと思うな。少なくとも不良社員さんよりは理解が深いと思える。

JPanel と JComponent の違いはまさにここでしょう。Look & Feel。JPanel と、そのサブクラスには既定で PanelUI が設定されます。そして、JComponent の paintComponent メソッドでは、設定されている UI に描画を委譲するようになっています。その結果、PanelUI が設定されている JPanel は背景色が描画されるのです。

getBackground() で背景色が取得されるのに描画されないというのは、UI が設定されていないからなんですね。

> JPanelで新たに追加されたメソッドが6つのみなので、
> JPanelでなくても充分なのではないかと思ったのです。

逆に言えば JPanel ってたいしたことをしていないから JPanel をスーパークラスとして選択したとしても、JComponent に比べて大きなオーバーヘッドはないとも言えます。

JPanel のサブクラスとして振舞わせたいかどうかが選択のポイントになるんじゃないでしょうか。PanelUI が設定されること、AccessibleRole.PANEL が設定されること。これらによって Look & Feel など外部から JPanel (もしくはそれに類するもの)と見なされて処理される場面があります。

クラス自身がオーバーライドしているメソッドだけでなく、クラスの型を判定して外部から様々な処理をおこなう Java の Look & Feel 構造にも目を向ける必要があると思います。

評価

0

>ずいぶんと偉そうに書いているけど、不良社員さんも Java の継承、拡張、多態性について理解できていないのでは?

俺の理解が足りないのは、
JavaのSwingモデルについてのものだろう。
正直、きちんとさらったこともないしな。:-D

>質問者の理解は概ね正しいと思うな。少なくとも不良社員さんよりは理解が深いと思える。

2010-11-07 23:48 を読んだ上での評価なのか?(・ω・)

>JPanel と JComponent の違いはまさにここでしょう。

先の投稿にも書いたとおり、そもそも俺は、
基底クラスと派生クラスを機能で比較すること
そのものに意義を認めていない。

まあ、俺などお呼びでないってんなら、あとは好きにやって。ノシ

評価

0

>まず、それぞれのクラスがどういうものかは、ソースを見て理解するのではなくそのクラスの役割を考えるべきだということは分かってるんだろうか。

オブジェクト指向は様々なインスタンス同士でやりとりをすることでプログラムを動作させる考え方。
まずクラスの役割を考えてから、その役割を果たすために必要な状態や振る舞いを設計するのであって、状態や振る舞いを考えてからクラスの役割を当てつけるのは違う。人のプログラムやライブラリを見る時も、どういう目的や役割で作られたクラスなのかを考えてから状態や振る舞いを確認するべき。しかし、ひとつのクラスの状態や振る舞いだけを見てクラスの役割を推測するのは違う。スポーツで言えば、選手そのものだけではなく、チーム内での選手の役割を考えていかないとチーム全体の特徴を把握できないということのようなものでしょうか?

評価

0

>クラス自身がオーバーライドしているメソッドだけでなく、クラスの型を判定して外部から様々な処理をおこなう Java の Look & Feel 構造にも目を向ける必要があると思います。

@さん、非常にわかりやすく参考になる意見をありがとうございます。Look & Feel 構造についての理解を深めたいと思います。

>まあ、俺などお呼びでないってんなら、あとは好きにやって。ノシ

不良社員さん、お呼びでないなんてことはないです。むしろ、相手の顔色を伺わずストレートに意見できることは尊敬できます。

>コーディング時の、小手先のテクニックのことをいってるんじゃないよ。

自分はオブジェクト指向をただの便利な小手先テクニックとしてしか捉えてない。もしろ、もっと理論的にオブジェクト指向の考え方自体を捉えるべきということでしょうか?

評価

0

>チーム内での選手の役割を考えていかないとチーム全体の特徴を把握できないということのようなものでしょうか?

ある選手の行動だけを見てチームの目的が分かるか?という話、かな。

評価

0

>ある選手の行動だけを見てチームの目的が分かるか?という話、かな。

ちょっと、例えがおかしかったです。申し訳ない。。。
選手単独で分析しても、その選手の良さは分からない。チーム内での選手の役割も含めて分析すれば、その選手の本当の良さがわかる。
クラスでも、ひとつのクラスだけを見ていてもそのクラスの存在意義は分からない。全てのクラスを見て、そのクラスの役割を考えることで初めてそのクラスが設計された意味がわかる。
ということなのかなと感じました。

評価

0

まあそれこそ、細かい表現はどうでもいいよ。
細部(この場合コード)を見て全体を推し量らないほうがいいということ。
もちろん、そのアプローチで正解にたどり着くことが絶対にできない、とは言わないけど。

評価

0

> 細部(この場合コード)を見て全体を推し量らないほうがいいということ。

まあ、ケースバイケースですね。単体クラスを見て単体クラスの役割を把握できるほうが本来は望ましい。それがカプセル化ということだし。

ただ、ソフトウエア設計・開発をおこなううえでは、言語仕様には出てこないクラスよりも大きな粒度のものが存在することがあるんです。それが、フレームワークと呼ばれるもの。

もちろん、Swing もフレームワーク。Swing フレームワークという全体設計の中で、各々のクラスに役割が与えられている。Swing フレームワークでは、外部からクラスの型に応じた処理をおこなうという場面もありますから、単体クラスだけでは全体を見通せないという結果になっています。(このSwingの設計が悪いとは思っていません。念のため。)

JPanel くらいのコード量なら自分で実装できる! とか勝手なことをやってしまうと、Swing フレームワーク(LaF)に PANEL と見なされなくなって不整合がおきたりします。たとえば、ある LaF が「すべての PANEL に対して A というエフェクトをほどこす」といったときに、自作のJComponent が、その対象から外れてしまったりするわけです。

評価

0

>JPanel くらいのコード量なら自分で実装できる! とか勝手なことをやってしまうと、Swing フレームワーク(LaF)に PANEL と見なされなくなって不整合がおきたりします。

確かに、実装によっては Java の利点である「プラットフォーム非依存性」、Swingのコンポネントやレイアウトをそのまま使用することで得られる「信頼性」等を損なってしまうリスクがあると考えられます。
ただ、ひとつだけ言ってしまうと。Swingのデザインださいんです。。。
それが気に食わないので、JComponentクラスを継承して勝手に独自コンポネントを作成したりということをしてしまいました。

評価

0

コンポーネントを作るよりLook&Feelを作ったほうがいいかもね。

評価

0

>コンポーネントを作るよりLook&Feelを作ったほうがいいかもね。

ホントですね!
javax.swing.plaf.basicのクラスを使って、独自デザインの実装ができました。
Swingにあるコンポネントを極力使用して、Swingに存在しないコンポネントは自分でJComponentから実装することにします。

回答していただいた皆さんありがとうございました。

質問から6ヶ月以上経過しているので、回答を書き込むことはできません。