Javaのgetter,setterメソッドは(特に)GUI部品のための規格だった話

こんな記事があった。

getter/setterとはなんだったのか」- プログラマーの脳みそ

JavaBeansはGUIなどで再利用可能なコンポーネントを提供する際の規格のようなもので(僕もあまり詳しくない)2000年ぐらいにGUIのコンポーネントを作るときに意識したような、どうでもよかったような、イマイチ恩恵が実感できなかった代物だった

JBuilder2とか3の頃のJava開発といえば、AWTやSwingといったGUIアプリケーションを作ることがまだ当たり前だった時代。「部品」といえば、GUI部品のことを指していました。GUI部品といえば、ペタペタツールの存在を忘れてはなりません。当時のJava IDEは、こぞってVisual Basicの開発環境に追いつけ追い越せという状況だったんです。

それらのIDEが目指したもの、それは「コーディングなしでGUI画面を作れるようにすること」でした。当時の代表的なIDEの画面を探してみました。

JBuilder

fig1Visual Cafe

clip_image016

Visual Age

form_window

GUI部品のパレットと、各GUI部品を設定して見た目や動作を調整するためのパネルがどのIDEにもありました。つまり、GUI部品を共通の仕様で記述することによって、IDEが持つリッチなGUI構築機能に載せられるようにしたのです。特に、GUIでは部品を適切に配置するためのレイアウトマネージャの存在が大きく、決まった仕様がないと、レイアウトマネージャは各GUI部品を適切に扱えません。

そこで、JavaBeans仕様が生み出されました。各GUI部品のプロパティは、読み出しのみであればgetterのみを、読み書き可能であればgetterとsetterの両方を作成することで定義できます。IDEは、JavaBeans仕様に沿ったクラスであれば、それが持つプロパティをJavaBeans仕様に則って見つけ出し、IDEのGUI構築機能の中で値の設定を可能にします(最終的にそれがコードとして自動生成されます)。GUI部品のプロパティ値をIDEから設定することは、setterメソッドを呼び出すコードを書くことと同じ意味です。

そして、JavaBeans仕様に基づき、遂には「コーディングを全くしない(=したくてもできない)GUIアプリケーション開発環境」も登場しました。

Java Studio

jstudio

各種制御構文(jfやforなど)も部品として定義し、部品間の入出力を結線していくことでプログラミングが可能でした。簡単なもの(アニメーションをON/OFFする、など)であれば、本当に数分かからず作れました。まぁ、それ以上のものを作ろうとすると、かえってコスト高になるのはご想像の通りですが。

GUI部品は、それ単体が多くの属性値を持つ特徴があります。表示文字列、大きさ、色、形、レイアウトマネージャへ提供する情報、Enable/disable、フォント、等々、プロパティの塊です。そして、それが非常に動作に重要な影響を与えるものです。JavaBeans仕様は、7つしかパッケージがないJDK1.0.2が全盛だった時代に考え出されたものであり、当時の言語仕様のままで、IDEサポートが可能なGUI部品を定義するために考え出されたものと言っても過言ではないでしょう。GUI部品ですので、getterメソッドは値を返すだけとしても、setterメソッドについては、単にインスタンスフィールドの値更新だけではなく、GUI部品としての見た目の更新やイベントの発火など、いくつかの処理が実行されることがほとんどです。つまり、

「少なくともsetterメソッドについては、それが通常のメソッドであることが重要だったし都合が良かったことだった」

と言うことができるでしょう。

とはいえ、JavaBeansは最初からGUIに特化した仕様にせず汎用的な仕様として規定されましたので、今でもJavaの世界の中で根幹部分を構成するための仕様として君臨しています。ただ、MVCやドメインモデルなどでは、情報を持つだけのクラスを作ることも今日では多く(POJOという言葉が流行った時代にそれが加速されましたね)、そのためだけにJavaBeans仕様を適用してしまうと、確かに「なんでわざわざgetter, setter作るの?」という疑問が出てくるのも仕方のないことかと思います。今では「GUI部品を作るためにだなぁ・・・」なんてことを言っても、「はぃはぃ昔話ね」ってなってしまうでしょうし。やっぱり適材適所な新しい概念や機構が日々導入されるべきで、そういう意味ではJavaの進化は亀の足的に遅く、LL言語のウサギ並みの速さと比べられて今まで厳しかったな、ってことなんじゃないかと思います。Java8になっても解決されない問題というか、標準仕様での解決策は未だ検討中な段階でしょうし。lombokしかり。

今の若い人にはこんな背景知ってなくてもいい話かもしれませんが、ちょっと気になったので、エントリを書いてみました。昔話として楽しく読んで「へぇ」ってだけ思ってくれれば十分です。

このエントリーをはてなブックマークに追加

関連記事

2023年のRemap

Remapにファームウェアビルド機能を追加しました

Google I/O 2023でのウェブ関連のトピック

2022年を振り返って

現在のRemapと今後のRemapについて