プログラムの真髄

[タマニチェンコさん]

もし、「プログラムの真髄とは何か?」と言う質問を受けるのであれば、なんと答えるだろうか?


僕は、「コールバック」であると思う。


少し前までは、「フレームワーク」だと思っていたんだけど、フレームワークと言うのも、効率よくコールバックするための仕組みでしかない。


「コールバック」とは、何なのかと言うことを説明すると、その名の通り、自作の関数をライブラリなどから「呼んでもらうこと」である。
あまりプログラムに詳しくない人でも、「呼ぶ」ライブラリに関しては、直感的に理解できると思う。printf()やopen()など、呼び出すことにより仕事を代行してくれる関数は数多く存在し、ライブラリも多い。
逆に、コールバックだと、自分が「呼ばれる」側になる。ライブラリが果たすような仕事を自分で書くようなイメージだ。
プログラミングに詳しくなければ、こんなことをしても、まったくメリットが無いように感じるのではないかと思う。僕も、最初そう思った。


なぜコールバックが重要であり、真髄と呼べるようなものなのであろうか。



依存関係からの脱却

プログラムを呼び出すと、そのプログラムに依存する。
[呼ぶ側]→[呼ばれる側]の関係だ。呼ぶ側は呼ばれる側を知っているが、呼ばれる側が呼ぶ側を知ることは無い。
シンプルでわかりやすく、絶対的な法則だが、これが足枷となる場合がある。
と言うか、致命的な足枷といえる。
例えば、プログレスバーを進捗させるプログラムを書くとき、いくつのプログレスをいつ更新されるのか?と言う問題を解決できなかったりする(プログレスバーを進捗させるプログラムを書いたことがある人には、一番わかり易いたとえなんじゃないかと思う・・)。
コールバックは、これを解決してくれる。プログレスバーを進捗させたいタイミングで、コールバックを呼んで上げれば良いのだ(これはライブラリの立場からの言い方で、ユーザプログラムからすると、ライブラリがプログレスを進捗させたいタイミングで呼ばれることになる)。

これは、JAVAで言うこところのDIである。
JAVAは、コールバックの仕組みを持っていないなため、そのすべてをインターフェースで代用する。コールバックの重要性は、インターフェースの重要性と同義である。
ほとんどすべてのインターフェースは、コールバックを想定して定義される。


実は呼び出す処理の方が、定型的

プログラムが複雑になるので、共通した処理をライブラリ化する。
ライブラリを呼び出すことによって、複雑な処理を隠蔽する事ができるが、実はメインロジックが一番複雑で、且つ毎回同じことを書いているような気がする。
よくよく考えると、呼び出す側を隠蔽する方が効率的だったりするのだ(もちろん呼ぶ側もライブラリ化した方が良いに決まっている)。
そして、このことの一番わかり易い例が、OSによるプログラムの呼び出しなのではないだろうか。
マシンをブートアップし、メモリやタスクやディスクやその他のリソースを管理し、必要なタイミングで、ユーザプログラムを呼び出す仕組みこそ、巨大なコールバックライブラリそのものではないか。
誰もが、コールバックの「お得意さん」というわけだ。


規律

コールバックによって、呼び出しタイミングをライブラリ側が決められることは、プログラムに規律を守らせる上でも非常に重要になる。
適切なリソースや権限を与えてユーザプログラムを呼び出すことで、プログラムがオイタをする可能性をコントロールすることができる。
これは、コールバックと言うよりもフレームワークの仕事かもしれないが、コールバックとフレームワーク(そしてOSも)の間にパラダイム的な境がないので、どちらも同じである。
プロジェクトが大きくなればなるほど、規律は重要な懸案事項となり、「紙の上に書かれたルール」だけではなく、現実的な強制力を持つ必要性が出てくる。




実際のところは、実例を出して紹介しなければ納得しにくいかと思う。
とはいえ、ブログで書くには量が多くなりそうなので、別の機会に、もっとテーマを絞って書いて見たいと思う。
尻切れトンボ。(__)