「Dynamic Objective-C」読了

木下 誠著、BNN新社刊。
久しぶりの大判プログラミング本。けっこう勉強になった。
著者はずいぶん昔からHMDTというサイトを運営しておられて僕も何年も前から参考にさせていただいて、お世話になっている。
ちょうど今、著者のサイトでこの本の宣伝を兼ねた「プレゼントキャンペーン」をやってる。今更ながら僕も応募することに。

マイコミジャーナルのWEB連載を加筆修正したもの。僕は連載当時、読んでいたので部分的には覚えているものの、マイコミジャーナルはレイアウトが読みづらくて途中で挫けていた。紙の本の方がずっと読みやすい。

一般向けのプログラミング本でこのレベルのものは非常に珍しいと思う。たいていは初心者向けで、その次を探すと、たまーに蛸壺本があるけど、それ以外は抽象的なガイドか、それさえ無くてリファレンスを読むしかなかったりする。

第1章の前半でCocoaのランタイムの実装の話に突っ込む。ランタイムなんてこれまで必ずリンクしなければならない税金みたいなもので、ましてやその実装なんて気にしたこともなかったが、この話題は面白かった。Cocoaのプログラマならisaポインタがオブジェクトとしての動作を実現していることをなんとなく知ってはいるが、具体的な実現方法やCoare Foundationとの関係などはこの本で初めて知った。どんなものでも構造を知ることで設計思想が見えてくる。Cocoaは非常にスマートだけどそれ以上に地道で素直に作られていることがわかる。

多分Cのランタイムはこれほど面白くないだろうし、C++のランタイムは足の立たない泥沼みたいなもんだろうから、さすがにこれはCocoa固有の現象だろう。と言っても、他のランタイムなんか見たことはないけど。

1章の後半にはLeopardから導入されたObjective-C2.0に関する話。2.0の変更点は主に

1. Gabarge Collection
2. Property
3. Fast Enumeration

だった。Gabarge Collectionは便利だけど、僕にとってはretain/release/autoreleaseがやっと身に付いてメモリアロケーションにまつわるバグをやっと出さなくなったところだったので今更感があったし、Propertyは文法の異質さと微妙な制御を明示的にやらないとうまくいかない（実はこれまでの文法でも必要な制御だったが）わかりにくさの両方がC++的に見えて、あまり好きになれなかった。 Fast Enumerationは、NSEnumeratorをループの外で宣言する必要性が煩わしかったこれまでの記述がすっきりしたものになったのでこれは歓迎した。

ということでFast Enumeration以外は無視しようと思ってたけど、とはいうものの例えばPropertyで書くのが一般的になってしまって他人のコードが読めなくなってしまうんじゃないか、とちょっと不安だった。この本にはそれぞれの具体的な実装方法（使い方よりも）について語られていて納得がいった。

著者の、とにかく実装から掘り起こそうと言う姿勢は勉強する上では非常に重要。人のコードを読むのはおっくうで集中力が必要なので挫けやすい。この姿勢は僕も見習いたい。またそれは自分のコードを読みやすくもする。

第2章はデザインパターンをObjective-Cの特徴を生かして実装するという話になっている。もとになったGoF本を僕は知らないけど、面白くてしかもこれは役に立つ。

GoF本に現れるパターンがCocoa/Objective-Cだとどう表現されてどんな利点があるのか、Cocoaらしさがどういうところに現れるのか、という論点で進められる。例えばChain of ResponsibilityパターンではCocoa/Objective-Cでは動的な特性を生かして非常に簡単に表現できることがわかるし、またCommandパターンではCocoaのTarget/Actionは単にうまくできているだけでなく「美しい」と言えるほどである。

読んでいて「そうか、こういう手があったか」と思うところもあるし、逆に知らずにパターンを踏んだプログラミングをしていたということもある。このブログに上げたコードの中にも我流のパターンを見ることができる。

Cocoaでのプロラグラミングでは動的な特性も重要だけど、「異なるクラスの、意味として同じ動作を表すメソッドには同じセレクタ（メソッド名）を与える」というのも重要だと思う。copy:、paste:などだけでなく、countやsetSize:なんかのようにクラスは違っても一般的に共通する概念はあって、これに積極的に同じセレクタを持たせることは可読性にも役立つ。ただし、これはJavaやC++でも同じことが言えるのでこの本では強調されなかっただけなのかもしれない。

「Bridge」と「Facade」のように区別がよくわからないものや、「Strategy」や「Template」などのようになんでもそうじゃん、と思えるようなものもあるけど、過不足のないきれいな分類が必要なのではなくて「典型的」であることが大切。そしてパターンに即したコードを書くときはやはり出てくる名前を積極的に使って「これはこのことだな」とわかるように書くというのがいい、ということがわかった。これから使ってみようと思う。

僕はどっちかというと一般的なアプリではなくて数値計算のようなユーザを限定した、極端な場合自分しか使わないソフトを書いてきた。その印象から言うと、C++はいろいろなレベルのプログラマが大勢で開発するのに向いていて、Objective-Cはスキルの揃った少人数での開発に向いているような気がする。もちろん素人が使う言語の選択は、趣味にあった好きなのにすればいいのだけれど、僕みたいなのが使うにはObjective-Cがよく合っている。残念ながらObjective-Cで一緒につきあってくれる人は少なかったけど。

ちょっとごちゃごちゃ書きすぎたな。