プロパティへのアクセス
プロパティの定義方法はここまでに学んだので、次は、それらプロパティへの外部からのアクセス方法を学ぶ。文字列&リフレクションベースのアクセス方法が、どのように変わったかに注目してほしい。
まずはインスタンスのプロパティへのアクセス方法から。公開されているドキュメントでは、「.」演算子を用いた、フィールドへのアクセスと同様の文法でプロパティにアクセスすることが想定されている。
リスト2:インスタンスのプロパティへのアクセス
MyBean bean = new MyBean();
bean.name3 = bean.name2;
以前のドラフトでは「->」(アロー)演算子を用いるという案もあったが、決めかねているということだろうか。
プロパティオブジェクトの取得
以前、プロパティの情報はjava.beans.PropertyDescriptorのインスタンスに格納され、プロパティの名称やプロパティへのアクセスメソッドなどが格納されていた。PropertyDescriptorを取得するにはjava.beansパッケージのAPIを多少なりとも取り扱える必要があった。
今回のドラフトで提案されている方法は、言語自体にその仕組みを取り入れるというものだ。具体的には「#」演算子を追加し、「クラス名#プロパティ名」でプロパティの情報を取得できるようにする。プロパティの情報は、java.lang.Property(もしくはjava.lang.reflect.Property)で表される。Propertyクラスにはset()やget()といったメソッドがあり、プロパティの読み書きを非常に簡単に行える。
リスト3:「#」演算子を用いたプロパティの取得とその利用
public class Author {
property String name;
property String lastname;
…
}
…
Author author = new Author("joe", "forax");
Property<Author, String> name = Author#name; // 「#」演算子でプロパティ取得
name.set(author, "remi"); // Propertyクラスのsetメソッドで、プロパティに値セット
String myname= Author#lastname.get(author);
java.beansパッケージを利用するのと比べ、非常にすっきりとしたコードになる。
switch文の拡張
プロパティの種類によって分岐するようなコードを書く場合、今までのように文字列比較を行っていては、コンパイル時のチェックが働かないため、言語仕様の変更も威力半減となる。
ということで、switch文を拡張して、そうしたコードに対してもコンパイル時のチェックを行えるようにする、という方法が考案されている。
プロパティの種類で分岐する必要が頻繁に生じるのは、前述したバウンドプロパティにより、プロパティ変更時のイベントハンドリングを行う場合だ。
「bound」キーワードを付与されたプロパティは、
<T> void propertyChanged(Property<beanType, ?> prop, T oldValue, T newValue)
というイベントハンドラがクラス内に見つからないとコンパイル時にエラーとなる(そのメソッドは親クラスから継承していてもよい)。
リスト3:拡張されたswitch文によるプロパティの種類による分岐
public class Person {
// 以下はバウンドプロパティ
public property String name bound;
public property int age bound;
// プロパティ変更時のイベントハンドラ
public <T> void propertyChanged(Property<Person, T> prop, T oldValue, T newValue) {
// プロパティの種類で分岐
switch(prop) {
case name:
System.out.println((String)newValue);
break;
case age:
System.out.println((int)newValue);
break;
}
}
}
以上が、現在のドラフトにおけるプロパティの仕様だが、いかがだっただろうか。
筆者はJavaにおけるこれ以上の文法変更に懐疑的な方ではあったのだが、やはり新しい文法を目の当たりにしてみるとその魅力は如何ともしがたいものがある。
ツールが進化し、アクセッサメソッドはIDEがほとんど自動生成してくれる時代だとはいえ、やはりsetter/getterメソッドで埋め尽くされたコードは可読性にも欠け、メンテナンス性も落ちるのは間違いない。そうした問題を一気に解決しようとする試みはやはり歓迎すべきだろう。