日々の破片

_ 細分化する世界

最初の頃のプログラミング言語には、サブルーチンというような考え方はなかったはずだ。なぜなら、スタックマシンの登場は比較的最近（ていうこともないか）だし、スタックなしで戻りアドレスを保持するには相当特殊なことをしなければならないからだ（というか、そういうマシンを知っているし）。

でもLISPには再帰関数があるな、と書いた瞬間に気付いたが、実用の世界（リアルワールド）の話と限定すればいいか。

で、構造化されたりモジュール化されたり細分化されるようになった。オブジェクトというのも細分化の1つの方法だ。

というようなことを考えれば考えるほど、AOPっていうのは理に適っている流れに感じる。ただ、ちょっと僕が考えている実用の世界のプログラム（というか業務アプリケーションプログラムということだが）では、向きが反対なように感じられるのは、AOPがOOPの上に乗っかるように今のところなっているからかな。

つまり、何をアスペクトと見るかということだ。現時点のAOPの例を見る限り、業務処理（機能そのもの）をアスペクトとは見ず、非機能要件に関する部分をアスペクトとして記述する方向がうかがえるからだ。

そうではなく、機能は（フレームワークで言うところの）ホットスポットに相当するのではないだろうか。で、ホットスポットを切り替える/差し替える/充当する（この言葉がいちばん適切な感じがするな）のにアスペクトを利用できるようにするのが良いように思える。

データがあるとする。面倒だから従業員でいいや。こいつの給料の計算をどうするかは、実に多数のファクタで決定される。基準額、時間あたり単価（は時間外勤務手当ての計算に使われる）、勤続年数、歩合（これは部門に依存するかも）、家族構成、考課、所属部署（というか職能か）、休日勤務数、差し引く代休数（時間数かも知れないし、日数かも知れない）……。

で、これらのファクタは極端に言えば日ごとに変化する。

が、データそのものには社員コードのように不変なものから、今月の勤務時間数、本日の時間外時数、本年度の職能、本年度の勤続年数、今期の考課、本日の売上などの可変なものまである。

実際の計算は複数のマトリクス（これは給与規定によって通常年度ごとに決定される）を適用した結果に対して法律的なルールと企業独自のルールによって制約（ただし最大???円まで、最大???時間までというような制約）をかけて求められる。

ここでマトリクスと制約をシステムとしてどのように持つかによって実装戦略が決定されることになる。

1つの巨大なループ処理の中で計算する（その過程でデータを引っ張ってくることになる）ように設計すれば、これはTransaction Scriptパターンによる実装ということだ。

マトリクスを主となるデータに従属させ、そこで求めさせた結果をまとめるように設計すれば、それはDomain Modelパターンによる実装ということになる。

だいたいにおいて、ウィジェットをオブジェクトとして扱うように、業務処理をオブジェクトとして扱おうという発想自体が筋が悪いのだ（ロジックの分散設計にオブジェクト指向を援用することには問題はないと考えられる。経験的に）。

オブジェクトはアイデンティティを持つが、ルールやマトリクスにアイデンティティは無い(実際にはあるが、あくまでもシングルトンでしかない)。正しく現実をシステムへ写像すれば、オブジェクトは単なるデータとしてしか出てきようがないのだ。

OOPはシミュレーションのために生まれ、GUI(むしろ古式ゆかしくマルチメディアというべきか)プログラミングによって育まれたプログラミング言語だ。その言語をビジネスの、つまりリアルワールドのシステムの構築に利用しようとしたときに、もってこなくても良い、余分なOOの尻尾がついてきたと見るのが良さそうだ。その尻尾の最たるものがOOAあたりかも。勝手に伸びて木に巻きついているから始末に悪い。

人間のシステムはサルのシステムではない。尻尾はいつか切らなきゃならない。

現実的な解決策はストラテジとしてルールやマトリクスを組み込むことだ。それは正しく現実のシステムを正しく写像している。次にすべきことは、このストラテジをシステムに対する変更/修正ではなく、あたかも給与規定書を変更するように、簡単に置換できるようにすることだ。給与規定の変更は別途行うシミュレートなどによって熟成させる必要はあるだろうが、適用は即時だ。

しかしシステム化された場合、適用のために要求の決定(別途行うシミュレートなどによる熟成フェーズと等しい)の後に、仕様化−設計−開発−配備というステップが必要になる。これはおかしい。かえって工数が必要になっている。

ここでのマトリクスやルールが、システムへのパラメータとしてあらかじめ決定可能なものならば、それはパラメータとして実装すれば良いから何も問題はない。適用はパラメータの変更で済むからだ。

だが、実際は人間にとっては何の問題もない計算方法の変更であっても、それはいわゆるパラメータの変更の範疇を越えてしまう（乗数の変更程度であればもちろん問題はない。健康保険の本人負担分の上昇程度なら）。

というか、基本的にはパラメータ化されているのだが、そのパラメータがただ事ではなかったりするので、そのパラメータのメンテナンスするための特殊技能の持ち主が必要となったりしているという現状もある。また、パラメータというのは、そのパラメータをプルしてきて、内容について実装で面倒みなければならないという点からあまり筋が良い手法とは考えにくい。

想起するのはWebアプリケーションの進化だ。CGIは、完全に外部の（HTMLを吐く）アプリケーションの呼び出しで、続くのは埋め込みHTML（埋め込みアプリケーションかな）、そしてWebアプリケーション自体をホットスポットとして交換可能にしたサーブレットコンテナやASP.NETだ。

業務システムはまだ埋め込みHTML(過剰パラメータ)とCGI(完全な作りこみ)が共存している状態に近い（入れ子になっていることに注意。WebサーバーとWebアプリケーションの関係を、Webアプリケーションの中に見ているのである）。サーブレットがそのコンテキストでは（パフォーマンス要件が理由だとしても）シングルトンだということに注目すべきだろう。

なんて書いていたら6時か。外が少し明るい。やめた。