日々の破片

_ インターフェイス

角谷さんから『インターフェイス指向設計』を献本してもらったので、薄いってこともあって、大体読んだ（つもり）。

インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践(Ken Pugh)

ぱらぱら読んだ限り、悪くない。むしろ手軽さからは良いのではなかろうか（落とし穴はあるかも知れないから、そこはがっつり読み込んだわけではないので断言はできない）。

まず、この本は普通にUMLを使いたい人（そうでない人は規格本を読むと良いのではなかろうか）で、良く使い方がわからない人の役に立つ。ファウラーの薄いUMLの本も良いけど、これもいいね。少なくとも、シーケンス図、状態遷移図、クラス図、ユースケース図は押さえられる。設計するには、とりあえずそれだけ書ければ十分だ （コンポーネント図と配置図は、UML2で微妙になってしまったしなぁ）。

でも、ちょっと思ったが、この本のUMLってOmni Graffleっぽくて、Judeっぽくないけど、そんなものなんだろうか。（大きなお世話だね）

でも、それはどうでも良い。

ポリモーフィズムとインターフェイスについて、わりと納得しやすい例で始めているところも良いと思う。

JavaとかC#がC++より良い点って、メモリー管理とかじゃなくて、インターフェイスがあること、かつそれが、継承とは完全に分離されて、ただもうポリモーフィズムのために存在している点だと僕には思えるし、それに沿っているからだ。

でも、データインターフェイスって必要か？ とか思ったりもするが、そこはちゃんと読み込んでないから、必要なのかも知れない。うん、APIではなくドキュメント型インターフェイスというのは、そう言い切ったところがおもしろい（というか、そういうコンセンサスがあるのだろう。知らなかったけど。ヴォキャブラリーがそれに当たると考えればよいのだろうか。というか、単にプロトコルでのリクエストレスポンスの取り決めのことを文書インターフェイスと言い換えただけのようにも思うが、概念を固めることは良いことだ……が、オブジェクトをDTOとしてエンコードするのか、文書としてエンコードするかの違いにわざわざ名前をつけただけのように見えるのだが、区別する必要があるんだろうか？）。

と、まあ、読めば何かしら反応できるので退屈もしない。

デザインパターンのおおざっぱだけどたぶん、今となってはこれで十分かも、のような解説もある。特に、デコレータパターンとプロクシパターンの区別について、今までで最も簡潔かつ納得がいく説明があって、思わず納得した（良くわかってなかったようだというか、わかっていなかった）。「Decoratorパターンでは、ユーザーの側がデコレートを行います」――あ、なるほど。そりゃそうだ。

ただ、ゴミのような問題点がある。ひどい問題だ。

UMLについてはこの本で適当に書き方を学ぶで良いかも知れないが、この本のコーディングスタイルは最低だから、絶対マネをすべきじゃない。

うがって見れば、JavaとC#の両方に色目を使ってすべてを台無しにしたという感じだ。

例：正しいC#のコード(MSDNによってオーソライズされている)

public class BeautifulWorld
{
    public BeautifulWorld()
    {
        if (IsReal)
        {
            throw new IdontWantToSeeTheRealWorldsProblems();
        }
    }
}

例：正しいJavaのコード（JDKによってオーソライズされている）

public class PrettyWorld {
    public PrettyWorld() {
        if (isReal()) {
            throw new IdontWantToSeePeopleWhoWantToRuleTheWorld();
        }
    }
}

例：この本のコード

public class WhatYourName
    {
    public WhatYourName()
        {
        if (unpa() && runpa())
            {
            throw new PleaseTellHimTheRightIndentSettingPlease();
            }
        }
    }
}

まったくお手本にならない。

追記：スティーブマコネルさんはこのインデントを推奨しているらしい(via @hajimehoshi)。だからといって、（おれにとっては）まったくお話にならないことには変わりはないんだけど、そういう考え方もあるということは知っておいても良いかも。
CODE COMPLETE 第2版 上 完全なプログラミングを目指して(スティーブ マコネル)

ところで、低凝縮かつ密結合な設計って、存在しうるのだろうか？ ……DTOでんがな？

_ メモ

ジェネレーティブプログラミング (IT Architects’Archive CLASSIC MODER)(クシシュトフ・チャルネッキ)

776ページか。

_ 夢の跡

マルチスレッドGUIツールキットは夢の跡（松尾芭蕉的な意味で）

おもしろかったので途中まで訳したが、結構難しいってことと（英文が）、今更感がぷんぷん漂っているので挫折した。というかSunだからもしかして既に和訳されてたり？

追記：新丈 径さんが訳してくれた。ありがとうございます。「マルチスレッドツールキット：見果てぬ夢？」

特に興味深いのは、実は最後のほうにあるコメントで、GUIツールキットを構成するプログラミング言語のコルーチンの欠如を指摘している。つまり、マルチスレッドではなくイベントキューで良いのだが、イベントハンドラへのファイアの個所をツールキットが抽象化してコルーチンにすれば良いのではないかという指摘。コルーチンっていうのは、この場合、継続の意味だと思う。

ああ、と何か見えた気がしたのは、イベントドリブンとWebアプリケーションの類似性とか、むしろWebアプリケーションよりもイベントドリブンプログラミングでの分断の度合いの強さ（Webアプリケーションは設計上、分散を意識し、イベントつまりリクエスト間は疎結合にする、すべき。しかし、GUIアプリケーションでそんな作りは普通は取りたくない。1プロセス1アプリケーションなんだから密結合で良いはず）に対する一定の解に違いないとか。

で……おれはコルーチン（この場合Fiberよりも継続だと思うのだが）を避けてきたが、ちょびっと興味がわいてきたのであった。

……いやFiberで良いのか。実行を与えれば良いのか？ （今20:20か）

_ はじめてのFiberプログラミング

OS Xだと自由に使える（使いかたを知ってる）GUIツールキットがtkしかなくて、しかもtk良く知らないんだよなぁ。

とりあえず使えることはわかった。最低の例だが、cd_timer.rbのボタンを無理矢理Fiberを使うようにしてみた。

#オリジナル
b.command(proc{ 
            if mode == :start
              timers.each{|timer| timer.restart}
              b.text('reset')
              mode = :reset
            else
              timers.each{|timer| timer.stop.reset}
              b.text('start')
              mode = :start
            end
          })

これを無理矢理Fiber化してみる。と、軽くやってみたらクロススレッド違反になった。……ってことはウィジェットのproc内で作る必要があるのか。あまりうまくないけど、まあしょうがない。

def new_fib(b, timers)  # ウィジェットのイベント処理スレッド内で実行
  Fiber.new do 
    while true   # まったくおもしろくない処理
      timers.each{|timer| timer.restart}
      b.text('reset')
      Fiber.yield
      timers.each{|timer| timer.stop.reset}
      b.text('start')
      Fiber.yield
    end
  end
end
b.command(proc{ unless fib   # ここで作るのがなぁ。
                  fib = new_fib(b, timers)
                end                               # ここまで
            fib.resume })                   # でもキャプション状態の保存は不要に!

（30分かかったorz）

#追記： それにつけてもWindow3.1の頃に、高速で動作する……というか、VBがコルーチンを言語仕様としてサポートしていたら（中間コード方式だからできなくはないはず）世の中、相当変わっていたんじゃないかなぁと、過去のアプリケーションを思い起こしながら考えた。