再利用の罠

再利用再利用と声高に叫んだプロジェクトほど失敗します。再利用しようとしてはいけません。手段が目的になってしまわないようにしましょう。

再利用できるもの

さて、「再利用は目的ではなく結果だ」と言いました。これからは、どんなも のが再利用できるかという話をしましょう。

ここでこれから挙げる物事は再利用のためのものではないということに注意し て下さい。あくまでシステムを深く理解するためのものなのです。そしてシス テムというものは似通ったものが多いからたまたま再利用ができるというだけ なのです。

ドメインの再利用

ドメインとは、ある立場から見た場合のシステムの見え方のことでした。ドメ インは独立した単位ですので再利用ができます。

ドメインの再利用は何も難しい事ではなく、言ってみれば当たり前の話です。 例を挙げると、あるシステムをWebベースで作成した後で、画面や操作はまっ たく同じにしてJavaで作り直して欲しいと言われた時のことです。こんな時に はデータベースや画面の設計をそのまま持ってきてコーディングだけやり直せ ばいい、というだけの話です。

しかし、言うだけなら簡単ですが、実際にやってみるとそんなに簡単ではない ことがわかるでしょう。ドメインを意識した設計でないと、仕様書のそこかし こにWebの言葉が出てきてしまっているでしょう。「FORMタグを使う」とか 「URLに○○のパラメータを含めて……」とか。このようにWebベースであるこ とを前提とした仕様書になっていると再利用することが難しくなります。

こうした場合、本来ならアプリケーション本来の動作を表現するアプリケーショ ンドメインとそれをWeb上で閲覧/操作するためのユーザインターフェースドメ インに分けるべきなのです。アプリケーションドメインではURLとかタグとか CGIというような用語は一切使ってはいけません。なぜならそれは本来のアプ リケーション(経理とか在庫管理とか)とは一切関係がないからです。そしてしっ かりドメイン分けされていれば、関係ない部分が変わっても問題はない、とい うわけです。

デザインパターン

システムを開発していると、様々な場面で「あ、これはよく見る形だ」と思う ことがあります。これがデザインパターンです。普段はその時にそう思うだけ でそのうち忘れてしまいますが、これを形にして残しておくのです。

とにかく開発中に「あ、これはいつものパターンだ」と思ったらそれはすべて デザインパターンです。そしてそう思ったら、それを書きとめておいてデザイ ンパターン集に登録します。名前をつけ、それがどんな形のパターンでどうい う時に出てくるかの説明を書きます。そしてそれをファイルしておき、後で誰 もが見られるようにするのです。

デザインパターンの本質は、その表現形式が決まっていないところにあります。 従来はこうしたパターンはプログラムコード、もっと言えば関数という単位で 表現されていました。「ソートをする関数」とか「バイナリツリーを探索する 関数」といったようにです。しかし、コードとして再利用しにくい部分は手つ かずでした。例えばある処理を10回繰り返したい場合、ほとんどの人はこう書 くでしょう。

for(int i=0;i<10;i++){
  ....
}

これは頻繁に使われるにも関らず汎用ライブラリの中に用意されている例は 見たことがありません。なぜなら関数というかたまりにできないからです。 従来のコード主体の方法ではコードにならない部分は切り捨てざるを得なかっ たのです。 デザインパターンでは内容を図や文章で説明します。だからどんなパター ンでも記述できるのです。もしプログラマが「10回の繰り返しをどうやって表 現しようか？」と思ったら、デザインパターン集に書いてあるのを真似して記 述すればいいのです。

コードを書く時に限りません。すべての知見は言うなればパターンです。例え ば「アプリケーションとユーザインターフェースを分ける」というのはドメイ ン分割のパターンです。こうしたコードにならない知見を文書で残しておく事 に意味があるのです。

メタモデル

「メタモデル」とは、モデルをモデル化したものです。「CDには複数の曲が入っ ていて、曲にはタイトルと作曲者がある」というのがCDというものをモデル化 したものだとすると、「オブジェクトには属性があり、それぞれのオブジェク トは関係しあっている」というのがモデルをモデル化したものです。

メタモデルというのは案外いろいろな場所で顔を出します。データベースのテー ブル設計がモデル化であるとすると、テーブルの定義方法を設計するのがメタ モデルです。プログラムそのものに対して「プログラムには関数と変数があっ て……」というのがメタモデルです。

メタモデルというのは一種のパターンです。メタモデルはただシステムを開発 するだけならさほど意識しなくてもすむのですが、開発スタイルや開発ツール を作成しようとすると目を向けなくてはならなくなります。

コンベンション

「コンベンション」とは、システム設計に関する規則のことです。「コードコ ンベンション」という単語が一番馴染みがあるでしょう。コードコンベンショ ンとはコードを書く時の規則のことです。(例えば)Java言語の構文規則のこと ではありません。それにのっとった上で、例えば関数のコメントはどこに書く かとか、関数名の決め方などを決めたのがコードコンベンションです。当然の ことながら、こうした取り決めはいったん決めてしまえばいろんなシステムに 適用できます。

コンベンションはコードだけに限りません。仕様書や設計書の書き方、そして そもそもどんな仕様書を用意するのかなど、システム開発のやり方を規定する 様々な規則がコンベンションです。システム開発のモデル化とも言えるでしょ う。「システム開発=モデル化」という考え方からすればこれはメタモデルで す。

開発するシステムの種類によって適切なコンベンションは変わってきます。小 規模システムと大規模システムでは違いますし、データベース系と組み込みリ アルタイム系でもまた違うでしょう。その場にあったコンベンションを開発し、 それは同じようなシステムで使い回すというのがよいやり方でしょう。