DCI Architecture
Trygve Reenskaug と James O. Coplien による新たなプログラミング概念 DCI(Data, Context/Collaborations, Interactions)の提唱。
http://www.artima.com/articles/dci_vision.html
導入部から抜粋すると：
In this article, we'll show how to combine roles, algorithms, objects, and associations between them to provide a stronger mapping between the code and the end-user mental model. The result is an architecture based on the object Data, the Collaborations between objects, and the way that Use Cases scenarios comprise Interactions between roles: the DCI architecture.
意訳：
エンドユーザーの持つ概念モデルをコードとして表現するために、ロール、アルゴリズム、オブジェクト、およびその関連をまとめる方法を示す。結果として、データとオブジェクト連携、ユースケース(ロール群の相互作用)にもとづく構造ができる。これが、DCI アーキテクチャである。
OOram のロールという概念に馴染のある人でないと、ピンとこないかもしれませんね。
DCI の背景には、オブジェクト指向はデータ抽象はうまく扱えるが振舞いについては今一つだ、という主張があります。ここで言う振舞いとは、複数のオブジェクトをまたぐ複雑なロジックのことで、内部状態の変更や問い合わせといった単純なメソッドとは異なります。
複雑な振舞いの例としては、エディタにおけるスペルチェック(画面、文書、メニュー、辞書等にまたがる)や、ATM における送金(画面、口座、取引、取引履歴、監査証跡等と連携)などがあります。要するに、エンドユーザーが関与するユースケースですね。
ここで問題となるのは、具体的なロジックをどのオブジェクトが実装するのか、ということです。メソッドを実装したオブジェクトには他のオブジェクトとの結合が生じます。これが悩ましい。
DCI ではこの問題を解決するためにまず振舞いをカプセル化したロールを定義し、実行時にはこのロールをオブジェクトに Inject します。実行時というのがミソですね。この考えを押し進めると、オブジェクトからは「賢い」振舞いが取り除かれ、単純で安定したデータだけが残されます。いわゆる POD に近いものです。そして、安定したオブジェクトはそのままに、ユーザーの要求に応じて Agile に振舞いを追加していくことが可能となるわけです。実行コンテキストの異なるメソッドが単一のオブジェクトに同居する*1というような、気持悪いけれどありがちな状況というものを、DCI ではロールを使うことで回避しています。
ロールのメソッドはユースケースを直接コードに置き換えたかのような、単純な内容です。これならメンテナンス性も高い。まさに、ユーザーがシステムに期待する「振舞い」の概念モデルがそのままコード化されるというわけです。
C++ や Scala などのコード例もありますが、これは現状の言語機能を使うならこう表現できるよ、という程度の意味合いなので、コードだけを見て DCI の是非を判断するのは的外れだと思います。この記事に関する議論も続いているのですが、約一名が「コードで語れ!」とキャンキャン吠えていて、いまいち噛み合っておらず、あまり建設的な展開になっていないのが残念です。
http://www.artima.com/forums/flat.jsp?forum=226&thread=253008
DCI を Mix-In とか、メソッドオブジェクトとか、CLOS とか、template とか、そういった既存のプログラマの道具になぞらえて捉えると、たぶん本質を見失うんじゃないかと思います。理解するためのとっかかりとしてはいいと思うんですが、そこから概念的に飛躍しないといけない。まあ、人のことはあんまり言えませんけどね。
個人的には DCI に期待するところもあるのですが、ロールという概念をコードで表現できるようになるとか、そういった言語側のサポート体制がないと、市民権を得るのは難しいかなぁ。今のところ、僕らは class というハンマーしか持っていませんからね。
