「一般的な業務プログラム」の開発においてインスタンス化は必ずしも必要じゃない

http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html
んー、なんだか散漫な本文で、なんだかよくわからないな。
「自分の仕事で作るプログラムではインスタンス化は必ずしも必要じゃない。」
ぐらいしか言っていないような気がする。あとはなんだか、オブジェクト指向の説明なんだか批判なんだかよくわからない文が続くけど、オチがない。

うーん、なんだこれはw

細かい話は放置して、最初に主張されている「インスタンス化は必ずしも必要じゃない。」についてちょっとコメントするなら、「うん、そうだね。」といった所か。別に今まで手続き型でやってきた人が、手続き型チックに作ったっていいし、インスタンス化しても効率化できない場面もある。いわゆる「一般的な業務プログラム」(オペレータの入力やファイル、DBを読み取って、ファイルやDB、帳票、画面を編集・出力する、みたいなの)を作るって事を考えると、スクラッチで構築する部分はstaticな関数で大抵のことは済んじゃうだろうなってのはわかる。うちの現場でもそうだしね。

じゃ、オブジェクト指向が活きる部分は何かっていうと、それはライブラリだと思う。みんなが使うライブラリを構築するならオブジェクト指向の特性(インスタンス化や継承、多態性)が活きる。アプリケーションフレームワークを構築するのにも便利だ。ここ10年ばかりでいろんなアプリケーションフレームワークが登場したのは、オブジェクト指向技術の普及と無関係じゃない。オブジェクト指向ってのはそーゆー便利な基盤を作るのに、すごく向いた技術なんだ。でも、いわゆるIT技術者のうち、みんながみんな基盤の仕事をするかっていうと、必ずしもそうじゃない。むしろさっき触れたような「一般的な業務プログラム」を書く人のほうが多く求められている。

「一般的な業務プログラム」を作る仕事ができるかどうかって点で言えば、オブジェクト指向で作るかどうかは重要じゃなくて、問題は効率的にモノが作れたり保守できたりする=経済性が重要になる。たまたまそれがオブジェクト指向だって事はもちろんあるだろうけど、やりたいことが安くできるなら、どんな手を使ったっていいんですよ。関数型だろうが手続き型だろうが、知ったこっちゃない。特定の技術が経済性に貢献するかどうかは、その現場の特性によるしね。保守まで考えるなら、保守する期間だけ、人が確保できるかも重要だ。1年で終わる保守と10年続く保守じゃ話が変わる。どれだけの人が必要なのかも。1人、2人ならたいした話じゃないが50人、100人となれば要員調達の特性だって変わってくる。

じゃあオブジェクト指向は不必要な技術なのか?というと、それはそんなことはない。今の便利な基盤は大抵オブジェクト指向って考え方で構築されているんだから、基盤の維持に必要だ。それに、その基盤をうまく使おうと思うなら「オブジェクト指向のやり方」を勉強したほうがより効率のいい開発ができる可能性が高い。「一般的な業務プログラム」を作る一人の技術者の目線で見れば、「知ってれば便利な技術」ぐらいのモノかな。

ということで、

  • オブジェクト指向が「一般的な業務プログラム」を作る仕事でそんなに重要とは思わんな!
  • 技術論だけで仕事の話はできんよな! 仕事の話をするなら期間・規模を考慮に入れんとおかしくなるぜ!
  • でもオブジェクト指向でできたモノいっぱいあるし、知ってれば便利さ!

といった感想でした。

コメントがものすごい量ついているので、これはこれで後で読んでみよう。