元ネタはこちら。「業務アプリの業務部分で、オブジェクト指向なんか使わないよね」
もちろん元記事を書かれた方は当方よりよっぽどご承知だと思うので、批判しているわけでも賛同しているわけでもなく、単にきっかけということで。
非常に興味深いので、ワシなりに考察してみる。
実際に開発現場ではそのとおりなのである。
例えばイマドキの業務アプリでいちばんありそうな開発形態として、バックエンドに Oracle のような RDBMS があって、フロントに VB.NET / ASP.NET な UI 層がくっつくと考えよう。
Visual Studio でペタペタとフォーム（画面）にボタンやらのオブジェクトを貼り付けて、そのボタンをダブルクリックするとボタンクリック時のイベントハンドラメソッドが生成される。
なので、ここで SQL 文を実行して実際の業務ロジックを実行する…というカンジであろうよ。
たしかにフォームを作ると裏でクラスが生成されて、オブジェクトを貼り付けて、イベントハンドラはそのクラスのメソッドなので、オブジェクト指向といえばそうである。んが、それはあくまでフレームワークのハナシであって、自分でわざーざクラス設計をして、いわんや継承したりするようなある程度構造を持つようなクラスを設計をして、それを使うなんつーことはほぼないと言っていいだろう。
別にこれは VB.NET のハナシではなく、Java で Struts を使っていようが PHP で Zend Framework を使っていようが、Ruby on Rails だろうがたいして変わらないハナシである。
まれにあるとしたら、フレームワークが標準提供している以上の機能が必要になり、そのフレームワークを拡張する必要が生じた場合であったり、各ロジックで共通的な処理を作らなければならなくなったトキぐらいである。
んがしかし、実際問題オブジェクト指向的思考ができないヒトが共通処理を作ったところで、それは結局「単なる共通プロパティ＆共通メソッドをまとめただけのサブルーチンの寄せ集め的クラス」になってしまう。
さらに、実際問題それで何ら問題なかったりする。
もっと言うと、所謂「業務アプリ」なんてご大層なモノではなくとも、いわいる「Web プログラマー」も多くはそんなもんである。
では、オブジェクト指向なんていらないのか？
GoF のデザインパターンなんて、勉強する意味もないのか？
ひとつの結論としては、「別にいらないヒトにはいらないんじゃない？」というところである。
やりたいこと・やるべきことをやるために、早くてうまくて確実な手段があるひとがわざーざ違う手段をとるこたぁない。
世の中の多くの大型ホストで動いている COBOL システムは全てオープン系の Java / ASP.NET に置き換わると誰かが言ったかもしんない。
確かに置き換わったモノもたくさんあるだろう。
でも、絶滅したわけじゃない。
団塊の世代プログラマーが引退しはじめたことにより、COBOL プログラマーが足りない！なんてハナシはかなり前からあるし。
そういや最近こんな記事もあった。『下げ止まってきたメインフレーム市場』
※ただし、「メインフレームが下げ止まり」というハナシは数年前から言われていることであるがっ
オブジェクト指向なんてもなぁオブジェクト指向言語をつくるヒトとか、それで動くライブラリやフレームワークを作るヒトが知ってればよくて、それより上位のアプリケーションプログラマーには必要ないのかもしれない。
だが、オブジェクト指向で思考するアプリケーションプログラマーと、そうでないプログラマーとは根本的に考え方が異なるのである。
ここまで書いたら長くなったので、次回つづく（ぉぃ
コメント