図は嘘をつかない

(ハイになって書いている文章なので、以下は流し読みしてください)

[DP/2] というわけで、午後の仕事。 11個目のお話はまだとめておき、12個目のお話の続きを書く。コードスケッチは破綻なく終わったが、もっとよい例を思いついたのでプログラムは明日書き直すことにしよう。それよりも図だ。いま、UMLのクラス図を描いていて、顔がほころびるくらいうれしい。なんて美しい図だ。うん、やっぱり変奏曲の方がシンプルで本質的な解説がしやすい。特に、本書を読んできた読者にとってはこっちの方がよい。そうしよう。それにしても、美しい図だ。

うん、実例は嘘をつかない(実例では嘘をつけない)けれど、図も嘘をつかないな。もちろん、機械的にプログラムをクラス図に置き換えることはできる。でも、何かを主張するためにクラス図を描くのは、かなり技術を要する仕事だと思う。

例えば、それはこういうことだ。 Proxyなどのdelegationが登場したときには、クラス同士を「いかにも委譲しています」という感じに横に並べたい。それから、自然な流れとして左から右にクラス図を「読める」ようにしておきたい。そう、クラス図は構造を表現したものだから時間順序なんてないのだけれど、人間はそんなことにはおかまいなしに左から右に図を「読んでいく」。だから、典型的なシナリオに読者が乗れるようにクラス図も構成するのがよいだろう。これはUMLのアートワーク技法ですね。

そうか！「UMLで描くためのパターンランゲージ」というのも作れるわけですね（というわきみちにそれていると、本の完成が遠のくのでやらないけれど）。

話がそれた。さっきまで、12個目のお話で、メソッドのinvocationとexecutionの分離をいかに効果的にクラス図でアピールするかに腐心していました。それが、ぴぴっとひらめいて（聖霊に感謝）、うまくおさまったので、とても舞い上がっているのです。本書の前の章でとりあげてきたパターンのいくつかが、最終章のパターンの中におさまって、きゅっと引き締まった感じになりました。とても大きなカタルシス。前著で、Abstract Factoryパターンや、 Bridgeパターンが理解でき、クラス図にぴたりと収まったときの感じと似ている。ああっ、美しい。本を書くって、なんて素晴らしいお仕事なのでしょう。

さて、これからの作業は、いったんいま捕まえたものを忘れたつもりにならなければなりません。それは、いまからこの章を読む読者の立場になるということです。読者の帽子をかぶるのです。そして「いま（読者の帽子をかぶっている）私は、何を知っているだろうか。何を次に知りたいと思うだろうか」と考えるのです。そして急いで著者の帽子をかぶって、読者に伝えるのに一番抵抗のないもの、一番自然なものから書いていくのです。それは、ちょうど、愛する人の手をとってエスコートするようなものです。

「それでは、あそこまで一緒に行きましょう。足元に気をつけてくださいね」