トップ «前の日記(2008-05-21) 最新 次の日記(2008-05-23)» 編集

日々の破片

Subscribe with livedoor Reader
著作一覧

2008-05-22

_ インターフェイス

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

インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践(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版〈上〉―完全なプログラミングを目指して(スティーブ マコネル/Steve McConnell/クイープ)

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

_ 夢の跡

マルチスレッド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がコルーチンを言語仕様としてサポートしていたら(中間コード方式だからできなくはないはず)世の中、相当変わっていたんじゃないかなぁと、過去のアプリケーションを思い起こしながら考えた。

本日のツッコミ(全8件) [ツッコミを入れる]
_ arai (2008-05-22 09:22)

Generative Programmingの翻訳本が出たんですねー。<br>知りませんでした。だいぶ前に購入したもので。

_ arton (2008-05-22 14:56)

おお、で、今でも読んでみる価値(もちろんその人の必要性に依存するので、単に教養として、という観点で結構です)はあると思われますか?

_ NyaRuRu (2008-05-22 22:03)

>Generative Programmingの翻訳本<br><br>「6章 ジェネリックプログラミング 6.7 いまどきの多態」のところに先日話題になった Polymorph のまとめがあって,これ読んでたらこっち引用してたーと呻いてます.8 年前の本の「いまどき」ってのがまた突き刺さる.

_ arton (2008-05-22 22:07)

お、買われたんですね。どうです? 8年前の……そうか刺さるってことは21世紀は8年遅れと……買うかなぁ。

_ NyaRuRu (2008-05-22 23:09)

>どうです?<br><br>まず萩原さんファンなら買いかと.<br><br>自分の持っている本しか引用しないことにしている私としては 6 章だけでも言い値で買うか,でした.<br><br>視点が C++ に偏りすぎな気もしますが,そこは 8 年後という身分を利用して別言後視点のものを自分で書けば良いんだと好意的に解釈すれば問題なしかと.(でも絶対誰かがもうやってる)<br>とにかく多くのトピックが取り上げられています.なので,「たとえばいまならこれは Ruby でサンプルを書くと旬だな」というものもあるわけです.そういう楽しみ方もあるかと.<br><br>>21世紀は8年遅れと<br><br>これに関しては訳者あとがきに書かれていましたが,色々なければ 3 年遅れぐらいで読めていたみたいですね.

_ arton (2008-05-23 01:52)

なるほど。いや、サンプルを書くかどうかはともかく、コード例も多いんですね。Software Factoryみたいな本なのかなと思いました。<br>読破するかどうかはともかく買うことにします。

_ arai (2008-05-24 16:51)

色々と示唆を受けました。<br>師匠からも勧められましたし...<br>また素晴らしいのが、この活動が今でも続いていてDSL Toolsとかにも思想が取り入れられています。私の場合は原書なので、読むのに苦労していますが...

_ arton (2008-05-24 18:33)

私も結局買ってしまいました。示唆を受けるというのはわかりますねぇ。「思想」というのもそうでしょうね。<br>それにしても訳のこなれかたには感心しています。


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|

ジェズイットを見習え