pattern(代数的データ型パターン)なんてものが出てきて面白かったのでメモっとく。おける注文の種類を表現する方法が例題として掲載されている。株を取引したことがある人は知っていると思うのだが、株の注文には下記のような種類がある。代数的データ型パターンと呼んでいるデザインパターンが使われている。ないのか?その謎を紐解いていこう。プロジェクトで実験する。プロジェクトを生成しよう。com.example株取引の注文種別を列挙型として実装するまずは成行注文と指値注文のみを列挙型として実装してみよう。フィールドを持たせる。抽象メソッドを定義して、各列挙値でオーバーライドしている。列挙型を使用するテストを書いてみよう。}}実際のところ株取引の注文種別を列挙型で実装することには下記のような問題がある。メソッドによって指値の指定ができる指値注文で指値なしの状態が実現できるこれらの問題の解決策は様々あるかもしれないが、今回は代数的データ型パターンを用いて解決してみようと思う。そのシールドクラスパターンで成行注文と指値注文のみを代数的データ型として実装してみよう。クラスについていくつか補足しておこう。内部クラスに限定している。クラスを継承できないようにしている。これシールドクラスパターンと呼ばれる理由だと思う。クラスを使用するテストを書いてみよう。}}株取引の注文種別を列挙型で実装することで生じる下記の問題は、代数的データ型で実装することで解決できた。メソッドによって指値の指定ができる指値注文で指値なしの状態が実現できるその一方、注文が実行できるかどうかの判定はそもそも注文種別の責務なのかという問題がある。これは、列挙型と代数的データ型でそれぞれ例示した実装に共通する問題になる。}このような条件分岐には共通して下記のような問題がある。パターンを用いたパターンマッチングを導入してみよう。ようなパターンマッチングを期待しないでほしい。メソッドはコードを理解しやすくするために削除することにする。抽象メソッドを宣言し、それぞれの型で実装している。メソッドを呼び出している。メソッドがオーバーロードされていることによって、それぞれの型によって処理が分岐することになる。予約語で使えないからだ。クラスを使用するテストを書いてみよう。使い方を見た方が理解しやすいと思う。}}これで下記の問題は解決される。クラスに新しい型を追加した場合、もちろんコードの修正はしなければならない。条件分岐を上記のようなパターンマッチングで記述している限りは、コンパイル時にエラーが発生するようになるので、修正箇所の特定が容易になり、修正漏れを防ぐことができる。代数的データ型を洗練するさて、代数的データ型パターンは便利そうだということがわかった。いかんせん定義するのが面倒でコードの見通しも良くない。ファイルに下記の行を追加する。使用して書くとこうなる。アノテーションで実現する。アノテーションを付与する。なるし、コンストラクターとゲッターも自動的に生成される。アノテーションを明示しなさいという警告が発生するので付与している。スタティックコンストラクターを用意するここからは好みの問題だと思うけど、スタティックコンストラクターを用意するとよりそれっぽくなる。メソッドのようにスタティックコンストラクターを用意する。アノテーションでプロテクティッドコンストラクターにしている。}}ここまでやるとアノテーションでごちゃごちゃするのでお好みでどうぞ。