[システム開発]メタデータとテンプレート

　前述したようにメタデータを使う場合、文字列変換を行うためにテンプレートが必要になる。たとえばJavaのエンティティクラスをメタデータを使って自動生成したい場合、次のようなテンプレートが必要になる。

public class [物理クラス名] {

    // 以下、メタデータのメンバ数分繰り返し

    private [メンバの型] [物理メンバ名(ロワーキャメル表記)];

    public [メンバの型] get[物理メンバ名(キャメル表記)]() {
        return [物理メンバ名(ロワーキャメル表記)];
    }

    public void set[物理メンバ名(キャメル表記)]([メンバの型] [物理メンバ名(ロワーキャメル表記)]) {
        this.[物理メンバ名(ロワーキャメル表記)] = [物理メンバ名(ロワーキャメル表記)];
    }
}

　エンティティクラスはデータベーステーブルの構造と対応するようにメンバとgetter/setterを用意しなければならないので、上記のような構造となる。このように用意するテンプレートは、自動生成する対象に応じて作成する必要がある。
　また、このテンプレートを差し替えることによって、OSや開発言語、データベース、フレームワークの違いを吸収することができる。別掲記事にも記載がある通り、システム開発を取り巻く環境は日々変化している。フロッピーディスク、プリンタポートはなくなり、PS/2インターフェースもほぼ消えつつある。フレームワークも、データベースも栄枯盛衰、消えたものもあればバージョンアップで下位互換がなくなったものまで、色々だ。
　このような変化が起きても、本質モデル(永続化データ＋業務ロジック)は不変であるため、テンプレートを差し替えるだけで対応が可能となる。JavaのコードをPHPにしてもよいのである。幸い、JavaとPHPのコード体系はかなり似ているため、テンプレートを差し替えることはそれほど困難ではない。
　人間が記述しなければならないロジック部分は必ず出てくるが、一度記述してしまえば、そこから逆起こしでテンプレートを作ることができるため、人間が記述したロジック部分も含めて、ソフトウェア全体を自動生成できるようになる。仕様変更でデータベースが変わったならば、自動生成できる箇所は新しい構成で再度ソースコードを自動生成し、JUnitテストが通らない箇所だけ人間が手を加えて修正すれば問題ない。仕様変更で既存サービスが大幅に変わる場合は、新しいサービスを作成して業務ロジックを手書きし、テストが完了したら、次からは新しいサービスを使えば問題ない。