たなかこういちの開発ノート

システム開発に携わる筆者が、あれこれアウトプットするブログ

J. Coplien氏による「Lean Architecture / DCI Evening」に参加してきました

DCI DDD アジャイル エンタープライズ・システム・アーキテクチャー イベントレポート
J. Coplien氏、および奥様のGertrud Bjørnvig氏による、こちらの講演に参加してきました。PHPメンターズの久保氏、杉本氏他の皆様は、以前よりCoplien氏と交流（※ぃぇ、こ←れだけじゃないですが。。）があって、機会あって今回の開催に至ったとのことです。
 
会場は、ポート株式会社様にご提供いただきました。様々な勉強会に参加させていただいておりますが、全て主催者様、スポンサー様、そして各スタッフ様あって開催が実現されるわけで、感謝いたします。（※ポート様の入居されているビルは、TIS様、セプテーニ・オリジナル様の入居されているビルと同じでした。いつのまにか馴染みのあるビルになっていました^^ ）
 
濃密な3時間半でした。Coplien氏はとてもゆっくりと話していただいたので、TOEIC自己評価400台の自分にもだいぶ聞き取れました。 
 

 
◇
 
以下、私の気になったトピックの備忘録です。
 
※私が関心を持った点を、私の理解、解釈を通して書いていますので、Coplien氏、Bjørnvig氏の本来の意図や趣旨とは異なっている可能性があります。
 
※以下の記述では「※」に続く文や段落は、私自身のコメントや注釈です。
 
- Javaは“OO言語”では無い！
 
Javaは"Object-oriented"では無いのだそうです。"Class-oriented"だそうです。アラン・ケイが云っていたのは"Object-oriented"であり"Class-oriented"ではない、と。"Class-oriented"では無いところの"Object-oriented"とは、いわば“インスタンス指向”。そしてそこでいうオブジェクトは静的なものでは無く、動的なものであると。"Class-oriented"では静的になっている。動的というのは、インスタンス構築後、そのオブジェクトが可能な振る舞いが、インスタンス構築時のクラスに定義されていたものに限られず、可能な振る舞いが実行時に事後的に追加、削除、差し替えが自在なことを云う。
 
基本的に静的型付け言語では「真のOO」は実現し得ない。Coplien氏自身はRubyが気に入っているそうです。Scalaは静的型付けであるものの、implicit classで擬似的に事後のクラス差し替えが出来るので良いと。
 

 
- Role？Class？
 
Class-orientedでは、オブジェクトの可能な振る舞いが、クラスに事前定義されたものに限られる。あるオブジェクト（※例えば「ユーザー」でも「顧客」でも「注文」でも）に、何らか“責務”、言い換えれば“役割”を与えようと考えたとき、事前に定める固定的な振る舞いセットに限られてしまう。これは、様々な要求仕様をオブジェクトに担わせようとなったときに、クラスに事前定義する固定的な振る舞いセット自体を編集しなければならない、ことを意味する。このことが、本来のOOのオブジェクトの柔軟さを失わせてる。（※神クラスの原因にもなってる。）
 
オブジェクト（※というかエンティティ）に事後的に任意の“責務”あるいは“役割”を与えられるようにする。オブジェクト（※エンティティ）の存在の問題（"what-the-object-is"）と、場面場面でどういう機能を担わせるか（"what-the-object-does"）という問題を切り離す。（真の）OOでは普通のことである。Class-orientedでは一体になってしまう。切り離した"does"の部分を「Role」という。（※OO用語か、DCI用語か不明。）Roleはコンテキスト＝ユースケース依存、もしくはコンテキスト＝ユースケースに属する。"is"の部分は「Class」でよい。ここでのClass（※Class-orientedのClassではなく、Roleを切り離し、純粋に存在についてのみを表すClass）はユースケースに属さない。
 
このような「ClassにRoleをmix-in？weave？すること」を既存言語で実現しようとしたとき、どのようにできるかというと、Javaではうまくできない。interfaceのdefaultメソッドが導入されたからそれが使えるかもしれない。（※無論、DCIサポートするフレームワークを組み上げることはできるでしょう。Roleをmix-in？weave？することを直接サポートできる言語機能が無いってことです。）C++なら、templateが使える。（※使われっぷりは、Scalaの型クラスに近い感じ。）多重継承は使えない。二つのベースクラス間でのアクセスができないから。（※そうだっけ？Scala traitと同じにできた気がするけど）Scalaならtraitが使える。Scalaのtraitはこれら静的型付き言語の諸機能の中では一番いけてる。
 
- "trygve"
 
Coplien氏自身が開発されている「DCI記述言語」とそれのIDEです。
 
 
※DCI記述DSLです。Scalaで再実装したらなかなか良さげになるだろうと思いました。と思いましたら、あるようです。
 

 
- "Lean"ってAgileの枠のアクティビティ、では無い！
 
 
Role-Class構築様式（つまりDCIアーキテクチャー）に取り組む場合の方法論について。結論として、RoleはAgileに、ClassはLeanにやるのが良いと云う。売りたいものはシステムの内的構造（＝Class）ではなく、ユースケース（＝Role）でしょう。ユースケースを担うRoleはシステムの"Revenue"（※稼ぎ頭、プロフィットセンター）に関連付けられる。対するデータ部分のClassは、"Cost"に関連付く。Roleの開発では、様々な要求仕様に応えるために、俊敏にいろいろ試行錯誤出来なければならない。計画は出来ない。Classには安定、確実さが求められ、計画的で低コストな開発が求められる。Classにおいては、まずはドメイン分析から必要とされ得るメソッドや属性を事前に設計する。それらのInterfaceを決める。Implementationはしない。Implementationをどのように進めるか？Leanである。Leanは、「今実装したいユースケースに必要なもの」から来る。ClassにNo.1から10のメソッドや属性が事前設計されているとする。今回実現するユースケースでは、その内のNo.3,4,8が必要なのだとする。なので今回のスコープでは、No.3,4,8に対するカンバンが立つ。それだけを実装する。供給は正に"Just-In-Time"！（※キマり具合がヤバい。）
 
そして、LeanはAgileではない。
 

 
◆以上