Effective Objective-C 2.0の日本語訳版が出たらしい

Effective Objective-C 2.0

買うべきかどうかやや迷っている。

公式サイト（Effective Objective-C 2.0）の目次を見る限りでは、やたら常識的なことしか書いて無いし、この本を読むよりDynamic Objective-Cと、エキスパートObjective-Cプログラミングを読んだ方が役に立つ気がする。

前者はもう絶版なんだけどね。

不穏な目次

目次を見ると用語の翻訳に不穏な点が目に付く。監訳者は悪くないと思うんだけど…。

項目10 既存のクラスにカスタムデータを追加するにはAssociated Objectを使う

公式ドキュメントで Associative References と呼ばれていて、日本語ドキュメントでは 関連参照 と訳されている機能のことと思われる。

詳解Objective-C 2.0では 連想参照 と呼ばれていたりもする。統一してくれー。

もっともThe Objective-C Programming Languageが既に古いドキュメントなのか、現在の日本語化公式ドキュメントの一覧から外されているし、モダンなObjective-Cプログラミング解説の方には、関連参照の説明自体なくなってるのでしょうがないのかも。

どうせ「カテゴリでプロパティを追加する」みたいな使い道しかないし。

項目13 不透明なメソッドのデバッグではメソッドのSwizzlingを使うことを検討する

不透明なメソッド、の意味が分からない…。原文にOpaque Methodみたいに書いてあったのを直訳したとか？

ログ出力などを追加したデバッグ用メソッドを用意して、そこから本番用ロジックを呼ぶような挙動にしておき、マクロなどを用いてMethod Swizzlingで切り替える…というような内容かなぁ。でもそれなら単にデバッグログ部分をマクロで切り替えるだけでも十分だと思うし。

項目27 実装の詳細を隠すためにクラス延長カテゴリを活用せよ

クラス延長カテゴリってクラス拡張のことだよね。これもClass Extensionを直訳したとか？

結構前からXCodeの新規クラス追加テンプレートに含まれるようになったから、いまどき活用していない人を探す方が難しいと思われる。

昔はprivateなインスタンス変数も全てヘッダーファイルに@privateディレクティブで記述して、公開しなければいけなかったんですよ、という方が驚かれそう。NeXTSTEPの歴史から考えると昔というほど昔でもないけど。

項目28 プロトコルを使って無名オブジェクトを提供せよ

これは公式ドキュメントだと匿名オブジェクトと呼ばれていたもののことかな？

ちょっと読まないと分からないや。

匿名オブジェクト自体は、インターフェースのみ提供して実装クラスを隠蔽する（ファクトリとインターフェースの活用）という、オブジェクト指向の考え方としては常識的な内容。

ただ、Objective-Cの特性を使うことで、メッセージを横流しして実体オブジェクトを隠蔽できるとかそういう点について触れていたような記憶がある。

項目32 例外セーフコードによるメモリ管理には注意が必要

例外セーフコードってなんだろう…。

unsafe_unretainedのコードはちゃんとメモリ管理しようとかその程度のことだったりするんだろうか。

項目34 メモリ最高使用水準を下げるために自動開放プールブロックを使う

これが言いたいのってたぶん、ARCを使っていてもメモリが解放されるのはスコープを抜けるタイミングだから、forループで大量のインスタンスを生成するようなコードを書く際には明示的に@autoreleaseを書け、みたいなことだよね。

メモリ最高使用水準ってもうちょいいい訳ないんだろうか。「最大メモリ使用量」だとニュアンスがぼけるかな。

項目35 メモリ管理上の問題をデバッグするときにはゾンビが役立つ

「ゾンビが役に立つ」のそこはかとない忍殺アトモスフィアがじわじわ来る。

NSZombieEnabledを利用することを指してるのか、InstrumentsのZombiesテンプレートを活用することを指してるのかのどっちかだろう。

項目45 スレッドセーフなコードのワンショット実行にはdispatch_onceを使う

ワンショット実行…という言葉は聞きなれないけど、これも直訳なんだろうか。

例えばsingletonオブジェクトを作るときに、dispatch_onceを使うだけで、マルチスレッド対応の一度きりの実行が実現できる、ということだと思う。うーん、確かに上手く纏まる言葉が見つからないかも。

昔は@synchronizedによるmutexロックが推奨されていたけど、システムレベルで並行処理を行うdispatchの方が高速かつ、記述が平易。

ただGCDはblocksとセットなので、いずれかの知識が不足していると読解が難解になり、開発メンバー全員が両方の知識を十分に有していることが利用の前提になってしまう。

みんながエキスパートObjective-Cプログラミングを読んでくれれば解決なんだけど、世の中そう甘くない。

そのほか気になる項目

項目5 状態、オプション、ステータスコードにはenumを使う

これだけだと本当に常識レベルの話なので、CocoaではNS_ENUMマクロとNS_OPTIONSマクロを利用せよ、という点まで触れてあるのかな。

NS_ENUMマクロは単にtypedefしたenumと違って、switch文でのコンパイラチェックが走るのと、型を明示する必要があるので型安全性を維持できる。もっとも、NSIntegerのような型を使わないと32bitと64bit環境間で問題が発生すると思うけど。

これに加えて、コンパイラに応じてEnumerations with a fixed underlying typeというClangの新しい構文を利用してくれるらしい。

項目7 インスタンス変数にクラス内でアクセスするときは直接アクセスする

これ理由が分かんないや。

個人的な指針では、公開インターフェースは全てプロパティ、非公開のものについてはスカラ型はインスタンス変数にして、オブジェクトは全てプロパティにした上で、プロパティ経由でアクセスしている。

例外としてinitやdeallocのようなオブジェクトの状態が不定になる場面でのみインスタンス変数への直接アクセスを行う。KVOによって不定なオブジェクトが操作される可能性があるため。

プロパティを経由することによる速度的なデメリットも、セレクタのキャッシュが吸収してくれて大きな差は出ないと思うし、後からプロパティを@dynamicにしてカスタムな挙動を加えたとしても、コードの修正が最小限で済むから、直接アクセスするメリットが分からないや。

そもそも速度が重要なら、最初からメソッドじゃなくて関数で書くべきと思っている。

項目50 キャッシュではNSDictionaryではなくNSCacheを使う

キャッシュ用途でNSDictionaryを使う人がいるとしたら、それはレベル低すぎるでしょ…。普通LRUなキャッシュを構築しようと考え、既存のライブラリやフレームワークが無いか調べ、そしたらNSCacheまでは自然に辿り着くはず。

あと、公式リファレンスに追加された、メモリ効率の向上に関するガイドラインにNSCacheや関連するクラスのAPIの詳細な日本語解説が載っていて、恐らくそちらの方が詳しいので、キャッシュ機構を作る必要がある人は一読するのがおすすめ。

追記

読まずにDISる記事が思った以上に反響がありおっかなびっくりで、一応買って読んでみました。

公式の用語を使っていない、という点で翻訳に不安を覚えたのですが、本文の訳文そのものは読み辛さはないし、ボリュームの割には深いところまでちゃんと突いている（NS_ENUMマクロがC++11の恩恵を受けていることとか、NSPurgeableDataの存在とかまでちゃんと書いてある辺りは完全に予想外）という感想を持ったことを追記しておきます。

初心者向けのiOS開発入門本から入って、古いAppleのドキュメントを読んだことがない、という人がObjective-C 2.0のマニアックな言語仕様について把握する本としては、値段以外は手ごろかなと思います。