このへん( https://mag.autumn.org/Content.aspx?id=20030911005128 )で何気なく「脱オブジェクト指向的」という言葉を書いてしまいましたが、それが意図するところを、もうちょっと整理してみようと思って少し書いてみます。
最初に断っておきますが、このようなアイデアが正しいかどうかは全く分かりません。また、これを世に広めたいということでもありません。
さて、プログラムとは何か。
それに対する答はいろいろあると思います。
ここでは、時間の流れに従って逐次的に実行される命令の列、と捉えて話を進めたいと思います。実際には、マルチスレッドやマルチプロセッサという形で、必ずしも逐次的に実行されない場合もあります。また、CPU自身が複数命令を同時に実行してしまう場合もありますが、基本的には一度に1つの命令が実行される、ということで話を進めます。
逐次的に実行されるということを、ここでは「手順的」という言葉で表してみます。
その用語を使って言うなら、プログラムは手順的に表現されることが、最もプログラムの基本的な性格に照らして、直接的で単純で分かりやすい、と言えます。
手順的なプログラムというのはどういうものかというと、実行される命令の並びが分かりやすい形で表現されたものと言えます。間接的に実行されるもの、たとえば、メソッドなどは、あるメソッド呼び出しが呼び出す実体としてのメソッドが1つに決まっている状態が、手順的であると言えます。
さて、ここで手順的ではないプログラムというものも考えられます。たとえば、ポリモーフィズムを使うと、あるメソッド呼び出しが具体的に呼び出すメソッドの実体が1つに決まりません。1つに決まらないどころか、あとから継承を使って、呼び出し先となり得るメソッドを追加することすら容易です。これは、「元のソースを書き換えることなく拡張可能」というメリットとして語られる場合がありますが、手順的に考えるなら、手順の見通しが悪くなるという意味で、デメリットと見ることができるかもしれません。
実際、YAGNIを座右の銘として開発を行っていると、未知の拡張の可能性を配慮することは、やるべきことではないことに対応したりするかもしれないので、未知の将来の拡張に対して開いていることはメリットに数えないことにします。とすれば、(ここに書かれたことだけ見れば)、デメリットの方が目立つことになります。
もう1つ、極めて現実的なことを書くと、Visual Studio .NETで開発している場合、手順的なソースの方が便利ということがあります。この統合開発環境では、キーワードを右クリックして、定義へジャンプさせることができます。これは、手順的なプログラムでは有効に機能します。しかし、ポリモーフィズムを使っている場合は機能しません。スーパークラスのメソッドの定義は飛べますが、実際に呼び出されうるメソッド群がどれなのか知ることはできません。
以上です。
そのようなわけで、手順的プログラミングは、もしかしたら何かのメリットをプログラマにもたらしてくれるかもしれない、という単なる思いつきのメモでした。これが正しいかどうかは分かりません。
ちなみに、手順的プログラミングは、ポリモーフィズムや継承に対して否定的ではありますが、全否定ではありません。汎用のクラスライブラリなど、未知の拡張に対して開いていることが要件であるプログラムの場合、それらは有効なツールとなるような気がします。また、カプセル化の機能は必須のものだと思います。カプセル化することと、手順的であることは、完全に両立します。
