OSTRACISM CO.

C#とObjective-CとJavaと...

GUIの構築

.NET

 Visual C#では(多分.NETの他の言語も)独立アプリを新規作成すると空っぽのフレームを持つプログラムが自動生成される。MFCに慣れた身にはなんともVisual Basic臭さを感じる。実際C#でのプログラミングはVisual Basicなみにお手軽であることは事実だ。とはいえVB6等に慣れた開発者にとってVB.NETは全く新しくなってしまったが故にお手軽には移行できないもののようだ。確かにC++やJava由来の概念や全く新しい概念があるので簡単にとはいかないとは思う。
 Visual C#でフレームにGUI部品を貼付けるとバリバリソースコードを書き換えられる。お馴染みだったダイアログリソースやメニューリソースはなくなってしまった。
 例えばGGG4W.csの InitializeComponent である。このメソッドはVisual C#により自動的にメンテナンスされ、開発者が触る部分ではない(実際にはリファクタリングで触ったりするけど)。GUI構築に必要な情報は全てこのなかに表現されており、ここを正しく書き換えるとちゃんとVisual C#のビジュアルなフレーム表示に反映される。
 デフォルトではメニュー文字列なんかもソースコードに入ってしまい、なんでだよと思ったのだが、フレームのLocalizableをTrueにすると文字列が全て.resxというファイルに追い出された。リソースはローカライズという文脈でのみ意味を持っているということらしい。
 GUI部品のプロパティ一覧をイベントに変更して各種アクションに対応するコールバックの枠を自動生成させることができる。GUI部品のダブルクリックでも自動生成される。
 GUI部品がウィンドウの変形によってどう追随するかはプロパティで設定できる。これもソースコードになる。

Cocoa

 Xcodeにおいて独立アプリを新規作成すると空っぽのウィンドウと色々余計なものが入ったメニューが自動生成される。この実体は.nibファイルで、Interface Builderで編集する。
 Cocoaは.NETと比べ逆を突っ走っており、Interface Builderで作ったGUIがどんなふうにプログラム内でオブジェクトとして有効になる(インスタンス化する)かが全く見えない。アプリが起動するともうそこには用意したオブジェクトがいるのである。少なくともウィンドウやダイアログをリソースからロードして表示していた旧来の開発者は不安に思うだろう。でも.nibのやり方もNeXT時代からあるわけで、歴史的に安定しているといえる。
 Carbonで新規作成をすると、.nibファイルを読み込むコードがあらかじめ用意され何をやっているか多少はわかり、Objective-Cでも NSApplicationMain で似たようなことをしていると想像できる。
 .NETではメインのクラスはメインのフォームのクラスそのものだっったが、Cocoaではそうはしないのが流儀のようだ。NSObjectを継承する制御クラスをInterface Builderで用意して、そのクラスとGUIとの結びつきを矢印で結びながら作り込むことになる。GUI部品の変数はOutletとして、GUI部品へのアクションのコールバックはActionとして作り込む。
 Interface BuilderでOutletとActionを決めたクラスをソースコードとして保存するのだが、一度保存したら今後の同期は基本的に手作業だ。.nibファイルは変数名やコールバック名も記録されたリソースだと考えてよいかもしれない。.nibと矛盾しないようソースコードにも同じ変数等を用意するのはかつてダイアログのアイテム番号を扱っていた頃に比べれば大分楽だと思う。
 GUI部品がウィンドウの変形によってどう追随するかはインスペクターで設定できる。

Swing

 NetBeansにおいては最初にJFrameを継承してmainメソッドを持つクラスをウィザードに従って作ることで.NETやCocoaと同じスタートラインに立つことができる。
 NetBeansでも.NETと同じようにGUI表現は全てJavaソースコードで表現される。
 例えばGGG4J.javaの initComponents である。このメソッドはNetBeansにより自動的にメンテナンスされ、開発者が触る部分ではない。勝手なリファクタリングも禁止。GUI構築情報は.formファイルに記録され、NetBeansはソースコードの変更を解釈してはくれない。書き換えるなら.formファイルの方である。この.formファイルは実行には使わない。
 Eclipseでは.formファイルのようなものは作らず、ソースコードを解釈してGUI表現を再生している。よってかけ離れた記述をすると破綻することもあり、基本的には開発者が触る部分ではない。.NETやNetBeansが自動生成部分をメソッド一つに集約するのに対し、Eclipseでは部品ごとにバリバリ生成メソッドを作ってしまうという問題がある。かなりソースコードが冗長なコードで占められることだろう。このNetBeansとEclipseの方法はどちらも一長一短なところだ。NetBeansが.formファイルを使わなければ良いのにとは思う。
 NetBeansではGUI部品のダブルクリックでアクションのコールバックが自動生成される。
 GUI部品がウィンドウの変形によってどう追随するかはJPanelのレイアウトマネージャを駆使して作り込む必要がある。ソースコードを書かなくとも作り込めるのだがこれがなかなか大変なのだ。

2005.07.04
2005.09.18
「インデックス」へ戻る

OSTRACISM CO.
OSTRA / Takeshi Yoneki