フレームワークとしての一貫性からCocoaの歴史を振り返る

Cocoaにもだいぶん慣れてきたタイミングで、Cocoaって他と何が違っているのか考えてみている回。その答えの大きな部分がこの一貫性にあるのではないかという最初の結論。

Cocoaってシステムレベルのフレームワークなので、いわゆる他のフレームワークとは格が違うのはしょうがないかとは思います。例えばWindwos の昔のAPI、Win32のころのフレームワークでMFCというのがありましたが、Win32でも作れるけどその上にC++で便利に作れるように被せてみたよ、っというレベルではないということです。なので出来がいいのは当たり前、むしろそうだからこそコアな機能に至るまで一貫性がある、つまり他のローレベルな概念がほぼ登場しない、ということになるのです。

実際、世の中にはさまざまなオブジェクト指向言語で作られたアプリケーションフレームワークがありますが、ひどいものもたくさんあって、形だけオブジェクト指向にしてみました、いけてるでしょ？みたいなのもたくさんあったのです。Cocoaはそういった中で極めて真っ当で、ちゃんとオブジェクトが自分の責務を果たしており、さらに不変性、Immutabilityも備えていてプログラミングのパラダイムとして極めて優れた設計をしていたように思います。

そうした一貫性のおかげでプラグラマは作法よくコードを書く癖が付き、その流れからObjective-C 2.0、そして ARCと繋がっていきます。Cocoaでのメモリ確保のパターンを、言語であるObjective-C 2.0の仕様に取り込み始め、@property 表記による getter/setterの暗黙的な実装が追加され、人が書かなくてはいけないコードを減らすという進化を遂げました。さらにはARC（Automatic Reference Counting）の導入では、プログラマが記述する一定のメモリ確保・破棄のパターンをコンパイラが勝手に挿入することができるようになったのです。これでミスすることもそもそもできなくなりました。それまでそのレベルの冗長なコードを人が書いてきたことにも驚きですが、それに不満を抱かせずにバグの少ないコードが書ける環境としてCocoaの仕様が成熟していたということが、1番の驚きだったようにも思います。

この流れはさらにはApple製の新しい言語、Swiftへとつながったわけですから、この地道さ、Apple、そしてその元となったNeXTの人たちの成し遂げた一貫性というものがいかに大事なことだったかということがわかると思います。