2008-07-21

最近もらった本: インターフェイス指向設計

最近でもないですが頂きました. ありがとうございます > 関係者の方. 多忙にかまけて感想を書くのが遅れてしまいました.

遅れた理由はもう一つあって, 私はこの本の主張があまりピンとこなかった. でも貰った本のことを単にイマイチだったと書くのも社会人としてどうかなー, などとよたよたするうちに月日は流れ...

嘘や間違いはない. けれどアジャイルなオブジェクト指向設計という視点でみると, いまいち relevance を欠く気がする. この本を読んでまずい設計が良くなるのを期待できない自分がいる.

何でピンとこないのか, しばらく考えていた. どうも "インターフェイス" を中心に据えるのがまずいんじゃなかろうか. オブジェクト指向の設計を議論する上で, インターフェイスはツールの一つに過ぎない. "インターフェイス指向設計" という切り口は, 極端に言えば "クッキー指向ウェブアプリケーション" とか "バイリニアフィルタ指向グラフィクス" みたいな違和感がある. とても強力なツールだし, これなしに仕事をするのは辛い. けれど核じゃない. だから "良いインターフェイスとは..." と話を進めるとぎこちなくなる. (逆に要素技術としてのインターフェイスを概観するには良い本かもしれない.)

私は継承が嫌いだ. 殺意に近い憎しみを抱いている. この世から継承を撲滅するための NPO があったら喜んで参加するし, 駅前で "すみません継承の勉強をしてるんですが..." と話しかけられたら間違いなく釣られると思う. だからこの本を読むまでは, インターフェイスを頼りに良い設計を説く うまい方法がないかと, 私自身も考えていた. 継承の天敵としてのインターフェイス (とコンポジション) に強い期待があった. けれど, どうもこの路線は先が長くない. 著者の Ken Pugh が身を持って示してくれた. 意図してないと思うけれども.

良い設計にインターフェイスが現れるのも, 悪い設計に継承が現れるのも, 何かの症状や結果に過ぎない. 肝は他にある. では何が肝なのか. それが上手く説明できれば苦労はない... たぶん, オブジェクト同士の <役割分担> や <協調> のありかたを中心に 考える必要があるのだと思う. この語彙はあまり的確じゃないかもしれない. でも話の都合でそう呼んでおく.

むかしながらのオブジェクト

クラスは, 古典的には "モジュール" と呼ばれていた概念を焼き直して説明されてきた. "一つのことを上手くやる" とかね. もう少しフォーマルな切り口は ADT. 今や古典である CODE COMPLETE や OOSC は, だいたいこれに則っている.

どちらも暗黙の前提がある: クラスは自己完結している. あるいは, 依存があるにせよなるべく自己完結しているべきだ. もちろん ADT の理論そのものにこうした前提はない. けれど, そこから先の議論はいつも単一のクラスの善し悪しに焦点を置いている. 古典にあらわれる指標は, クラスひとつの設計を評価するものが大半だ. 協調の影は薄い.

クラスを(再)利用する <利用者> と, それを提供する <実装者=読者>. こうした立場の断絶が先の流れを助長する. 利用者に公開されるオブジェクト (おそらく facade) は, 利便性のために自己完結しているかもしれない. けれど実際の価値ある複雑な仕事は, その多くを複数のオブジェクトが担っている. 利用者からは隠されているだけだ. 困ったことに, なぜか複雑さは教科書の読者からも隠されてしまう. それがまさに知りたいことなのに! 実装の詳細というには話がでかすぎる.

こうして古い流儀では, 一人の利用者のために一つのクラスやインターフェイスを仕上げることばかり気にして, 裏にある協調のありかたをおざなりにしている. これじゃ片手落ちだ. "高凝集で疎結合なのがいい" というけれど, それをどう実現するかが知りたいんだよ. "インターフェイス指向設計" に不満があるのは, 新しい書籍の割にこのへんが無自覚だからだなあ. きっと...

実際のソフトウェアでは, 複数のオブジェクトが協調して仕事を進めることになる. だからどう仕事を分担し, 協調して振る舞うべきなのかを考えないと, 良い抽象をつくることはできない. そのためには複数の立場から問題を眺める必要がある. ある視点からは隠された実装の詳細には, 別の視点にとっての抽象の核が潜んでいる. この複眼的な視点で設計するソフトウェアはどんな姿になるのだろうか.

いまどきのオブジェクト (はこうあって欲しい)

そんな疑問に答えるのが, 多くの場合 agile を名に冠する, いまどきのオブジェクト指向設計/プログラミングなのだと私は考えている.

"デザインパターン" は, 複数のオブジェクトが協調して仕事をすることに重きを置いた教科書のひとつだ. ただ, 協調の姿がどうあるべきかという原則に関する議論は少ない. (それこそ例の "移譲を使え" くらい.) かわりに具体的なパターンが列挙されている. よりモダンな応用に "パターン指向リファクタリング" がある.

"オブジェクトデザイン" は, 責務や役割, 協調を中心に置いて設計の原則を議論している. これは私の感覚にとても近くて, 読みながらなるほどと思うことが多かった. ただいわゆる上流工程テイストが強く, 話も抽象的なので割と眠い. もう少しコードの言葉を話してくれれば良いのにね.

"アジャイルソフトウェア開発の奥義" に示されている設計原則には, 役割分担と協調という前提があるように見える. (本の中でそれを強調することはない.) ソフトウェアを変更するときにようやく分担すべき責務がみつかるとするこの本の主張は, "リファクタリング" の流れを汲んでいる. いまどき感がある. "オブジェクトデザイン" も設計は反復的なプロセスだと言ってはいるものの, 書いてみなければわからないというぶっちゃけた態度を取るには至っていない.

変更を前提とした開発様式の中で, いかにオブジェクトを協調させ役割を果たしていくか. そのための抽象をつくるにはどう考え, 手を動かすべきか. そのへんをずばっと説明している教科書を私は知らない. だから "インターフェイス指向設計" だけを責めてもフェアではないかもしれない.

そんな本を, いつか Martin Fowler あたりが書いてくれんかなーと勝手に期待している. そのときはオライリー/PragBook から出してね > Martin Fowler.