部品

プログラミング関連の掲示板では「…をする関数は何ですか?」などと言ってかなり限定的な局面でしか使わなそうな機能を挙げる初心者がいたりする。既存のものを再発明することなくプログラミングすることは理想の形ではあるが、何もかもの機能を部品に要求してそれをくっつけるだけでプログラムになるわけではない。標準部品になるのはやはり広い場面で使えるからこそであり、細かい要求を実現するにはどうしても自前で書く必要がある。近年では標準的なライブラリが充実していて既存機能のおおざっぱな組合せでなんとかなるからであろうと思うが、基本となる理念を理解することをせずにただ部品の種類を覚えることがプログラミングの学習であるかのように思っている初心者が多くなっているように見受けられる。
とは言え、プログラミング言語そのものと標準ライブラリは不可分なものであることも事実である。標準ライブラリはプログラムの部品と言うだけでなく、言語の理念をも表現しているものであるから、単に覚えるだけでなく理解しようと努めるのであれば無意味ではない。標準として提供されているものをあえて自分で実装してみることが訓練として有用な場面もある。
ところで、プログラムの部品の抽象化方法と言うとどのような形があるか考えてみる。まず古典的なものとして思い浮ぶのはこういったものかと思う。

  • サブルーチン
  • 手続
  • 関数

更にオブジェクト思考的なものを追加する。

  • クラス

これに付随するものとして

  • メソッド
  • フィールド
  • プロパティ

等々も「部品」と言えるだろう。
特に主要と思われるものだけを挙げたが、細かく挙げればきりがない。また、同じ語が場合によって違う性質を持つものを指している場合があって同じような理念に見えてもその実は多様である。例えば動的言語のいくつかではメソッドがクロージャとしての性質を持っている場合があったりなかったりといったことだ。
また、応用も多彩だ。最近、私はCOMに関心を持ったが、これはクラスの概念を知っているだけで理解できるわけではない。クラスによる抽象化の一技法と言うよりは、もはや、COMという独自の理念と言っても過言では無いかもしれない。
そう言うわけで、思想は多様化している。既存のライブラリを利用するだけ、というプログラミングでさえもそれなりの知識が要求されるようになっているのではないか。膨大なライブラリと引き換えとは言え、その部品を使えるようになるだけの知識を身に付けるのは簡単では無い。
つまり、初心者がライブラリに期待し過ぎたとしても、使いこなすには結局は学ぶべきことは多い。だからそのステップは必須とは言わぬまでもそう回り道と言うわけでもないのかもしれない。私にとっては違和感のあるスタイルではあるが、日進月歩の業界にあってスタイルの変容は珍しくもない。
以上、ふと目についた変化を私なりに考察してみた。
Document ID: 00fe21b61d47830de0b73ee6dc082d76