今週のObjective-C重箱の隅

http://www.atmarkit.co.jp/fcoding/articles/objc/02/objc02a.html
一番初めのObjective-Cプログラム - ＠IT

ものすごぅく細かいことだけど、ブコメにも出ているのに割とスルー気味なのが気になったので書いちゃう。

• alloc/retainとreleaseの対応付け

  他の点は見解の違いや記述意図次第で変わる話なので、ぶっちゃけどうでもいいと思うけど、これに関しては最低限きちんとやった方がいい。

  Cがmalloc()に始まりfree()に終わる言語であるように、Objective-Cもメモリ確保が非常に大きな意味を持つ。私がこの言語に触れたときはその最初の一歩(から少し踏み出したくらいだったかもしれないが)で、alloc、retain、releaseの組み合わせについて散々言及された文献にぶち当たらされたものだった。

  最初の一歩なので、それぞれの意味や規則についていろいろと説明するのは後回しでかまわないのだから、せめてサンプル内でもreleaseするくらいはして欲しかった。訳分からないうちから癖づけるくらいしないと、retain/releaseが幾重にも折り重なる現実のObjective-Cのコードとやっていくのはちょっと、いやかなり難しい。まあ、最近はGarbage Collectionも入ってきてはいるけど、それが全面的に受け入れられるほどまだObjective-Cの世界はシフトしていってないし。

• クラス個別のヘッダファイルのインポート

  これはどうなんだかな。最初なんで、使用するクラスを名指しでインポートして見せたいっていう意図なんだろうけど、通常は#import <Foundation/Foundation.h>とか#import <Cocoa/Cocoa.h>とか、フレームワーク単位で用意されたヘッダファイルがあってそっちを使うことが多いと思うなあ。でそいつをプリコンパイルヘッダに持ってくとかね。あんまり個別にインポートしてばかりいるとそれだけで1画面分とかなってしまうので、一般的にはちょっとおすすめできない。まあ、考え方次第だと思うけど。

• ヘッダファイルさらに

  Objective-Cは良くも悪くも根っこがCなので、ヘッダファイルをどのようにインポート(Cではインクルード)するかを一応ちゃんと考えとかないといけない、と思う。まあ、Cではかつて同一のヘッダファイルに対する多重インクルードを防ぐ仕組みが言語仕様上無かった頃の名残であって、#importでそこを解決してるんだからいいじゃない、という考え方もあるにはあるけど、しなくてもいいインポート／インクルードを防ぐことでコンパイル時間をコンパクトに保ちましょう、という主張は(この程度の極小規模のコードではあるが)まだ説得力があるはずだ。

  従って今回のケース、stdio.hのインポート位置は明らかにSinger.mの方だと思うし、Song.hについても同じくずらすことはできる。まあ、Song.hについては@class使ったりする必要があってさらに説明が増えることになるから、やんない方がいいか。まあ、そこをid型使ってごにょごにょ、っていうこともできるけどね。

• @implementationの後ろは

  クラス名だけでok。": 親クラス名"は要らんすよ。