[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 1002] Re: Java と GUI





Katsuhiro MIHARA wrote:

> 三原@東工大です。
>
> BTRON1 と Java の GUI まわりを比べるのは面白いと思いますが、
> Java の設計をひとまず知ってからでないと
> 「流儀が違う」の一言で済まされてしまいます。
> 私は Aki さんより Java プログラミングの経験が少ないでしょうが、
> ちょっと小言を言ってみましょうか。

はぁ。(^_^;

>
>
> From: Hideaki Suzuki <h1suzuki@bridgew.edu>
> Subject: [b-free: 985] Java とGUI
> Date: Sat, 31 Jan 1998 00:42:44 -0500
>
> > Aki です。
>
> > たとえば、Console Windowを作るとします。で、その内部に線やら何やらを表示
> > するわけですが、扱いやすくするために、表示が累積するとします。ふつうの
> > Screen を再現するわけです。
>
> Java の Frame や Window にスクリーンの役割をさせるのが無茶です。
>
> Frame や Window も java.awt.Component ですから Graphics(描画領域)を持っ
> ていますが、本領はより上位の java.awt.Container によって実装されるコン
> テナとしての役割です。

ははは。そういわれてしまうと、こっちも、「Java って、なんて不便な」っと云うこ
とになってしまうのですけれど。3D Graphic と Mandelbroat と、ふたつの Java
applets を僕は書いたわけですが、調べてみたら 3D の方は Frame から派生させ、
Mandel. の方は Canvas から派生させていました。で、Canvas だの Frame だのという
のは、本領本分もあるでしょうが、結局は、どっちの方が継承しやすいかという話だと
思います。
たとえば、Frame を派生させて、ある種の Canvas' subclass を受け入れる sucket の
ような物を実装し、その sucket にはめる事の出来る多種多様な Canvas' subclass を
つくる場合(Mandel.) Canvas から派生させるとよいと思います。しかし、3D の場合
は、Screen は一つ(より正確には、一種類)と云うことなので、Frame が Window を
作ってくれるのですから、その上に直接 Screen の機能を上乗せした方が、文章の量
も、見た目も、スッキリするわけです。そう思いません?

Mandel:
  Frame  <---- WindowSocket  <==(はめ込み可能)==  MandelPlug
  Canvas <---- MandelPlug <---- DBM, FDBM, 他各種描画方法による。

3D:
  Frame <--(この一種として)-- Screen

で、なぜ、Screen なんているのかというもっと、当たり前の疑問があれば、それは必
要なわけで、たとえば、五分間利用者を待たせて最終的な絵を完成させるような場合に
は、途中経過を見せられれば断然いいわけです。だから、なぜ java には screen が無
いのか、僕にはとんと理解できないところではあります。

>
>
> このばあい、スクリーン向けクラスを別に作り(Canvas から継承するのがいい
> でしょうか)、Frame に add() してやるのが素直だと思います。そうすると、
> 表示領域の大きさを指定してインスタンスを作れるようになります。
>
> > たとえば、そんな Console Window を表示し、内部の矩形領域を選択可能としま
> > しょう。選択された矩形領域を、別の Window に等縮尺で表示しようとします。
> > すると、ウインドウの生成は表示領域の大きさではなく外寸法で指定するので、
> > いっぺんに困ってしまいます。
>
> Frame や Window は Container ですから、add() されたコンポーネントに合
> わせて作られます。描画領域のインスタンスを add() したあとで pack() し
> てやれば、描画領域を全て含んだうえで外側に枠をつけたちょうどいい頃合の
> Frame や Window ができますよ。

へぇ、これは知らなかった。> pack()
Window.pack() で、component の preferred size にしてくれるのね!
# Thanx alot! > 三原さん

もう、二ヶ月以上いじってなかったけど、Mandelbroat Set. の方は改造してみようか
なぁ。
暇な週末があれば。

>
>
> Java の場合、Window は動いている環境によるので勝手に決められません。
> 画面の広さも Window の枠の太さも分からないわけです。
> だから、pixel 単位の設定は極力排しています。
> 文字など大きさが変わりうるものは大きさを指定せず、
> 各コンポーネントは大体の位置を指定するにとどめ、
> LayoutManager が環境に合わせてレイアウトを決めます。
> それが Java の流儀です。
>
> 細かい指定ができないので、Java をベースにウィンドウマネージャを作るの
> はおかしいと思います。でも Java でアプリケーションを書くならそんなに苦
> 労はしません。

はい。そうなのでしょう。僕の希望は、Java を「標準的な」GUI 操作言語にして欲し
くないという話でした。
Applet (Window の内部の component)を書くにはいいのですが、実際に Window を多
数つくって普通のApplication のような物を書くとなると、どうも、大変な気がしま
す。個人的な見解なので、「Java で Window なんて激簡単!」っていう人もいるのか
もしれませんけど。

>
>
> >                          それでも、多重継承が使えないという重大な不満事
> > 項があります。それを補うためか Inner Class はあからさまに OOP の考え方を
> > 無視した ad hoc な付け足しに見えますし、
>
> Inner Class は friend class の代替であって、
> 多重継承がないことの補償では"ない"からです。
>
> friend class(これも OOP の原則から外れた代物)の代わりだから上位クラス
> の変数がそのまま見えると同時に、OOP としての体系を崩さないように有効ス
> コープが変数と同じ規則になっていて狭いのです。
> "friend class より安全な friend class" です。

そうだったんですか。ある時、非常に多重継承で苦しんで、そこに、JDK 1.1 になって
Inner Class が出てきたので「これで、何とかなるのか?でも、なんじゃこりゃ」と思
ってしまったわけですが。 ただ、C++ の friend と違うのは、C++ では、friend は
access-ship とでも云うような物なのに対し、Inner Class は、必ず、自分の一部とし
て所有しなければならないところでしょうか。

class A {
  friend class B;
};
class B {
  int a;
};

としたとき、
void A::func(B b) { b.a = 3; };

というように、A は B を所有しなくていいわけです。
結構この違いは大きい?!

>
>
> Inner Class が一つのクラスだから他のクラスから継承できるので、
> あたかも多重継承を実装できるかのように見えますが、それは副作用です。
>
> Java のアプリケーションの作り方を勉強するにはどうしたらいいんだろう。
> やっぱりあれこれ本を読んでみるか、生きた教材として HotJava を使ってみ
> ることでしょうか。
>

HotJava っておもしろい?なんか、重たそうなんだけどなぁ。
でも、おもしろいんなら、今度試してみたい気もする。

> 参考
> 100% Pure Java Cookbook
> http://www.sun.co.jp/tech/whitepapers/PJava2/docs/cookbook.html
>
> --
>   三原  克大  (Katsuhiro MIHARA)
> 東京工業大学理学部情報科学科
>  mailto:mihara@is.titech.ac.jp
>  http://www.is.titech.ac.jp/%7Emihara/index-j.html



 - Aki.