オブジェクト指向でプログラムを作れば再利用性が高くなるというのは誤りだったと思う。オブジェクト指向プログラミング（OOP）についての本を呼んでいるとOOPは再利用性が高いというようなことが書いてある。すでに結論が出ている話な気もするが、これは必ずしも正しくないと思う。
正確には、OOPは結果として再利用性は高くすることもあるかもしれないが、それを目的にするものではないと思う。素直に作れば良いものを変に欲出して再利用性とか言って作ったら、そのプログラム内でも使いづらいし、他のプログラムになんか流用したくないものが出来てしまうだろう。
クラスの意味・役割は、プログラムの目的――ドメインって言うのか？――によって異なる。十得ナイフなんて作ろうとしたら、鉛筆削りにすら使えないものができるのでやめたほうがいい。特定のドメインのためのプログラムが他のプログラムに使いまわせることってあんまりないと思う。
逆説的だが、使いまわせるプログラムってわざわざ作る必要ないと思うのだ。そのドメインの問題が解決するプログラムがないから、わざわざ新しく作るのだと思う。あるなら別に新しく作る必要がないから、再利用なんて必要なくないだろうか。すでにそのドメインに既存のプログラムがあるなら、既存のプログラムの部品（クラス）をつまんできて再利用して組み直すより、組まれたものを拡張する方が正しいと思うのだ。
再利用性と拡張性は矛盾はしないけれども別の話だ。再利用性というとツブツブのクラスを流用できるという意味合いだと思う。一方で、拡張性というとクラス同士が結合した状態のものに新しいクラスを結合してプログラムを拡大できるという意味だと思っている。
OOPの良さは拡張性の方だと思う。大伽藍を作るときの設計にも非常に有用だが、それを増改築するときのしやすさが一番の利点なのではと考えている。綺麗に設計された構造になっていれば、増改築の影響は少数のクラスに影響に閉じるので、大きくしていくのが簡単になる。*1
特定のドメインのためのプログラムを作ったとしても、他のドメインでも使えそうな小さな部品が結果としてできることはある。ドメインに依存しないような部品ってのは当然ある。でないと標準ライブラリなんて存在意義がない。そういうのは、再利用すればいいと思う、できればドメインに依存しないような使いやすい形にして。
でも、それは別にオブジェクト指向だから再利用できる部品になったわけではなかろう。使いまわせそうなルーチンができるなんて、オブジェクト指向に限ったことではない。CでもシェルスクリプトでもFortranでも同じことだ。
もしかしたら、オブジェクト指向だと、ルーチンが小さいだとか、部品が整理された形で存在している可能性が高いだとか、名前が衝突しにくいといった理由で、部品が再利用できる可能性が高くなるかもしれない。しかし、それは副次的効果であって、期待してはいけないと思うのだ。
*1:それがどういう構造なのかは今調べているところ。
