BlogCakePHPを中心としたサイト開発情報をメインに公開。新しもの好きなので時々製品レポートなんかも。Builderで編集している「アレ」の存在でしょう。xib形式のファイルで書かれている中身は、いったい何者なんでしょう?前回の記事で「Windowsでいうリソースファイル」と書いたと思うのですが、実際には少し違うようです。インターフェースの配置に関してはそのようなものなのですが、基本的にあの記述は「インスタンスの記述」のようなのです。Builderで「実行時に必要なインスタンスをあらかじめ作っておく」もののようです。xibで指定したインスタンスは、何処で作られているのでしょう。main.mや(プロジェクト名)AppDelegate.mを見ても、xibに相当するものを読み込む仕組みが何処なのか、よく分かりません。この辺で行われているのでしょう(知っている方がいらっしゃったら是非教えてください)。Cocoaプログラミングでは、インスタンスが格納されている場所を意識する必要はなさそうです。これらインスタンスはメッセージ形式で受け渡すため、ぶっちゃけIDが分かっていればどこからでもアクセスは出来るからでしょう。Builder上でインスタンスとして作りました。普通なら、FooからWindowに配置されているパーツ(UIButtonやUITextFieldなどのインスタンス)が、少なくともFoo内で定義されているインスタンスではないため、実体へのアクセスは出来ないはずですが、アウトレットの仕組みでアクセスが出来ています。アウトレットは実はID型のプロパティであり、ID型はもっと言えばただの整数です。Builderでは配置したパーツにユニークなIDをあらかじめ振っているため、そのIDを使ってアクセスをするのです。Builderで「接続」を行うのですが、これはどういう事かというと、各インスタンス内のアウトレットに初期値として該当IDを振る作業のようです。このことからも、xib内のアイテムがインスタンスであることが分かりますね。IDで管理する概念は実はWindowsでも普通にやっていて、リソースファイルを覗いてみると、しっかり配置したアイテムにユニークな番号が割り振られています。Windowsプログラミングとの大きな違いは、結局はWindowsではインスタンスそのもの(もしくは参照)を引数として渡している、という点です。リソースファイル上のアイテムへアクセスする場合は、リソースからインスタンスを入手するためのAPIでインスタンスを入手し、それを使ってアクセスします。この際にリソースIDを用いますが、それから先は基本的に不要です。ところがCocoaでは、xibでアイテムを呼び出すにも、プログラム上でアイテムを作り出すにも、帰ってくるものはIDで、インスタンスの実体はどこか分からないところにひっそりと存在しているようです。使い手にとってIDが全てになり、逆にどんなケースでもIDだけを扱っていればいいわけで、あれこれ考えなくても済む、というわけです。基本的にWindowsは普通のC/C++のルール上でAPIが出来ているのと、Windwsリソースの概念は後付けで、そもそもDOSプログラミングの延長上であったため、無理矢理とってつけた感が強いのですが、CocoaはObjective-Cのメッセージ概念のもとに成り立っているというのか、最初からそれありきで作られているような点で差があるのでしょう。実行速度の面では、メッセージ形式だとステップ数が増えそうな気がします。IDからインスタンスを特定するという部分が若干冗長だとは思います。それは誤差の範囲かも知れませんね。Objective-Cの記述はまだ慣れないのですが、確かに手順の記述に関しては、C++で記述するよりは簡潔かもしれません。横道にそれましたが、xibに関してはおおむねこんな感じですかね。Windowsプログラミングとはやはり全然違いますね。