このエントリはJava Advent Calender 2011の第14日目です。
OOPで最も重要なテクニックは何でしょうか。色々な考え方があるでしょうが、ボクはImmutable Objectがまず最初に浮かびます。
かなり前にJava World誌に書いていたJavaデザインノートという連載でも、第1回のテーマはImmutable Objectでした。
Immutable Object(不変オブジェクト)は、生成時に属性を設定した後、属性値を変更することができないオブジェクトです。Javaの場合、StringやDateなどの情報を保持する基本クラスの多くがImmutable Objectになっており、Javaプログラミングを下支えしています。
Immutable Objectの長所は、とにかく属性値が変更されないこと。一度生成したオブジェクトは何の心配もなく、メソッドの引数で渡すことができます。その先で、どのような共有のされかたをしても、知らないところで勝手に内容が変更されるということがありません。マルチスレッドプログラミングでは、この性質はさらに重要になります。
一方、Immutable Objectは以下の短所があります。
- 値を変更するためには、オブジェクトをまるごと複写する必要がある。
- すべての値の設定をオブジェクト生成時に行う必要があり、プログラミングがちょっと煩雑。
前者の問題は、最近のハードウェア性能の向上で、普通のWebアプリ、業務アプリではまず問題にはならないでしょう。まるごと複写といってもshallow copyとなるので、まるまるデッドコピーとはなるわけではありません。 また、多少の性能劣化があっても、プログラム品質、開発効率の向上の方がより重要というケースは多いはずです。 よほど性能要件の高い場合でも適材適所で使い分ければよいわけです。
そういう意味で、Value Objectは当然として、DTOといった情報量の多いオブジェクトもできるだけImmutable Object化していきたいところです。
となると、現在問題となるのは後者。まずオブジェクト生成時のコンストラクタで全情報を引数で渡さなければなりません。さらに、オブジェクトの変更(つまりデータを変更して複写)では、オブジェクトのほとんどの情報と変更したいデータを用意して、コンストラクタに渡すという手間が必要になります。 StringやDateのようなValue Objectでは、オブジェクトが管理する情報が1つやせいぜい2つなので全く問題ありませんが、DTO等の場合は管理する情報が数十個になるケースも考えられ、かなり煩雑になります。数十個と言わずとも5個ぐらいでも十分嫌になります。実際のプログラミングではこの手間が嫌で、Immutableの方がよいと分かっていても普通のMutable Objectを選択することになりがちです。これを何とかしたいですね。
この問題を解決するのがBuilderです。
プログラムはこんな感じ。
Immutable Object「Person」と、そのBuilderである「Person.Builder」を定義しています。 Personは、Immutable Objectであることを活用して属性をpublicにして外から扱いやすくしています。 Person.Builderの方は、普通のMutableオブジェクトで、値を設定しやすくするための工夫を好きなだけ行うことができます。ここではwithXXXメソッドでメソッドチェインを実現してみました。
package advent2011; import java.util.List; import java.util.ArrayList; import static java.util.Collections.unmodifiableList; public class Person { public final String name; public final int age; public final String address; public final List<String> phones; public Person(String name, int age, String address, List<String> phones) { this.name = name; this.age = age; this.address = address; this.phones = unmodifiableList(new ArrayList<String>(phones)); } public static class Builder { public String name; public int age; public String address; public ArrayList<String> phones = new ArrayList<String>(); public Builder() { } public Person build() { return new Person(name, age, address, phones); } public Builder withName(String name) { this.name = name; return this; } public Builder withAge(int age) { this.age = age; return this; } public Builder withAddress(String address) { this.address = address; return this; } public Builder withPhone(String phone) { this.phones.add(phone); return this; } } }
こんな感じで使います。
package advent2011; import org.junit.Test; import static org.hamcrest.core.Is.is; import static org.junit.Assert.*; public class PersonTest { @Test public void buildPerson() { Person.Builder builder = new Person.Builder(); builder.withName("Taro") .withAge(30) .withAddress("Yokohama") .withPhone("045-123-4567"); Person person = builder.build(); assertThat(person.name, is("Taro")); assertThat(person.age, is(30)); assertThat(person.address, is("Yokohama")); assertThat(person.phones.get(0), is("045-123-4567")); System.out.println(person); } }
Personオブジェクトを生成す時の手間は、普通のMutableオブジェクトの時と同じ。 buildメソッドで返ってくるPersonオブジェクトはImmutableオブジェクトなので、安全に使うことができます。 どちらの目的も叶える解ですね!
新たな問題
さて、Builderを使うとImmutableオブジェクトが使いやすくなるのは分かったのですが、新たに別の問題が発生します。
このBuilderを用意する手間がなかなか大変なんです。コーディング量も多いですし、コーディング内容が単純作業のためが短調で面白くない、という問題もあります。 この手間があるので、このままでは結局使わないテクニックになってしまいそうです。
単調なコーディングあるところ、自動生成あり。ここで登場するのが自動生成です。クラスの形が分かっていれば、その情報からJavaプログラムのソースコードを生成すればよることが可能です。
SimpleModelerService
現在開発中のSimpleModelerServiceでは、この問題に対応するためにDSLからJavaプログラムを自動生成する機能を提供する予定です。DSLにはScala DSLに加えて、CSV、マインドマップ(XMind)、Excelなどが利用できるようになる予定です。 今回は、CSVを使って試してみましょう。以下の内容のCSVファイルを用意します。
person,name;age(int);address?;phone+
CSVの第1カラムにクラス名、第2カラムに属性のリストを定義しています。「(int)」はint型、「?」「+」は多重度(?は0または1、+は1以上)を意味しています。
これを以下のフォームに設定して「生成」すると、色々なコードが生成されたものをzipで固めたものが返ってきます。
この中にある、DDPerson.javaに今回のテーマであるImmutableオブジェクトとBuilderが記述されています。ぜひ覗いてみてください。
ImmutableオブジェクトとそのBuilderの作成は、手間がかかるのでつい手抜きをしたくなりますが、プログラムの自動生成を活用すれば楽々クリアできますね。
SimpleModelerのJava生成機能は、近々公開したいと思いますので、ぜひご利用ください。
こんにちは。
返信削除よく勉強させていただきます!