日々の破片

_ 科学技術館

光についての教室に子供を連れてったら、妙にデッカな車がいっぱーい北の丸公園を取り囲んでるんですがなんですか？

で、入り損ねてしょうがないから九段会館の角を一周してもう一度やり直してびっくり。普段は比較的空いている駐車場がパンパンになってるではありませんか。っていうか、違法駐車も多いし、こりゃ大盛況ですね。

しょうがないから妻子を降ろして泣く泣く1人で家に帰って電車で出直し。

そっか、武道館で矢沢永吉のコンサートがあったのか。

_ 昨日の補足

DDJJのパターン特集が1998年らしい（この号はもう廃棄したから確認できない）。それ読んで、そうそうあるあると、ほーなるほどそのテがあったか、の両方があったな。

後、気付いた点：

●プログラム（モジュールと呼んだほうが良いかも）の粒度。

僕が最初のうちに仕事で作らされたトランザクションプログラムについて考えると、COBOLで1本のプログラムは、今現在JavaやC#で組めばストラテジが3〜4クラス、コンテキストが2〜3クラス（これは他のプログラムと共用可能）、コンテキストからストラテジの選択に利用するファクトリで1クラス（実装依存でパラメータ化するかどうかとかで結構変わる部分だが、これも他のプログラムと共用可能）、その他にユーティリティが粒度によるけど3〜4クラス（当然他のプログラムと共用可能）に分割できる（もっと多いな実際は）。

この分割戦略が決定すると、あとは個々のストラテジにはビジネスルールを埋め込むだけになるから、この単位で独立させて開発対象とすると、結局実装についての文書化の意味は無いことになる。しかも、フローチャートが必要になるような構造がもしあれば、大抵の場合はそれは複数回出現する構造となるので、テンプレートメソッドパターンを適用できる。すると、親クラスが（細粒度のビジネスルール抜きで）構造ごと独立するから、ますます、個々のストラテジについてはビジネスルールだけになってくる。（ここはリファクタリングの結果として求めるべきだろう）

このオブジェクトの組み合わせを規定するのはアーキテクチャパターンモデルだから、それはビジネスロジックの実装とは異なる層の話になってしまう。で、このアーキテクチャパターンモデルについての文書は、当然、個々のビジネスロジックについての設計の文書とは異なるものだ。一方、個々のストラテジはビジネスルールの固まりだから機能定義があれば文書として記述の必要はない。そりゃ、パラメータで与えられたAのフィールドBの内容をキーとしてテーブルC（と書くと実装とは異なるわけで、Cクラスのファインダを呼び出してとなるわけだろうが）を検索して……とか書けといえば書けるわけだが、それ意味あんのか？ と思うな普通。さすがに今となってはC派生の構文を持った言語であれば誰でもソース読めますな。しかも、パラメータで与えられたAなんてのは、他のストラテジも共用するわけで、すべてについてそんな文書書くのって無駄でしょうとなると思うんだが。

しかも、ビジネスデリゲートとかサービスロケータとか作るわけだし。70年代仕様のCOBOLとかだと、こういう細かなオブジェクト（というかCALL対象のサブモジュール）は作って管理するほうが大変だから個々のプログラムが持つことになるわけだが、JavaやC#だったら当然ビジネスデリゲートとかサービスロケータっていう別モジュールに分けてしまうので、ますます個々のビジネスロジックはビジネスルールだけになってくる。

結局、個々のモジュールは構造を持たない単なるノードになって機能要求の生な点しか扱わないことになる。

こうなると、もうプログラム作る楽しさは、アーキテクチャパターンモデル（とブレーク打ちながら、本当にモデルか？ モデルというほどギチギチに決定してないんだからパターンでいいんじゃないか？ と疑問も）決めたとこでほとんど終わりだな。

と書いていて思ったが、実際にはそんなことはないのはどうしてだ？ と自問自答。そうか、そこにTDDが結合するから単にビジネスルールを並べてくだけでもそれなりに面白いのか（ゲームになるからだ）。それにサービスロケータとかっていきなり作らずにリファクタリングの過程で出現するものだから（と考えているし事実そうやっているんだが、あらかじめ全部モデル化しとくものなのかな）すべてのオブジェクトがアーキテクチャパターンモデル（やっぱりモデルだな。パターンをアーキテクチャへ写像し終わったものだから）に出現するわけではない。というか、こういうのって内装のうちだから見取り図設計図（見取り図はないだろう）には出てこないだろう。

と考えていくと、デザインパターンによる設計、アジャイルな開発方法論、この2つを利用してオブジェクト指向言語で実装していくというのは実に理に適っていると思う。

●例外（エラー）はどうすれば良いのだろう

もしそれが個々のストラテジの内部でリカバリー可能な例外ならそれはビジネスルールのうちだ。そうではなくグローバルに影響するものだったらどうかといえば、ストラテジの呼び出し元で一括処理できるわけなので、例外投げろ−−処理中断しろとなるのだが、このあたりは例外機構が無い言語だと辛いかも。