GenerationGapパターン

GenerationGapパターンはご存知だろうか。
GoFのパターンではないので、そんなに有名ではないと思うのだが。

このパターンはコードの自動生成を利用する場合に有効な手法。
自動生成したコードには一切手を入れず、その自動生成したクラスを継承したクラスを用意し、必要なメソッドなどを追加するというパターン。
自動生成したものには手を入れないので、(ジェネレータが信用できるなら)テストを省けるというメリットもある。

何の本でみたのか忘れたが、Entityクラスには特に有効だ。
Seasar2系のフレームワークでは、DAO+Entityと最初から分かれているので、さほどこのパターンの恩恵を受けることは無いのだが、
ドメイン指向の開発だと、テーブルに対するクラスは、そのテーブル(と周囲)の操作をするための処理をクラスに内包することになる。
そうなると、テーブルレイアウトが変更になった場合、既存メソッドがあるため、クラスの自動生成はできない。→フィールドの追加を行いつつ、既存メソッドの変更も行わなければならなくなる。が、
GenerationGapパターンでは、フィールドの追加は、自動生成されるクラス側にされるため、間違いようがない。手も入れないのが前提なので、バグの入りようが無いという状態になる。
メソッドはそのクラスを継承したクラスに書いてあるので、自動生成されても親クラスが変更されるだけなので、影響が最小限となる。

EclipseのDBViewerプラグインでも、DBのテーブル定義からクラスを自動生成できたりするので、このパターンは使いどころが意外とある。