元ネタは
業務システムでオブジェクト指向をどこに使うか。
http://d.hatena.ne.jp/yotaropg/20090502
とか
[プログラミング一般]業務アプリの業務部分で、オブジェクト指向なんか使わないよね
http://d.hatena.ne.jp/kmaebashi/20090427/p1
とか。
とりあえず…雑感をつれづれと。
そりゃ、ライブラリやフレームワークでは使いますよ。しかし、多くのプロのプログラマが会社で作るような「業務アプリ」の世界において、プログラム全体の中でライブラリやフレームワークの占める割合は大きくはない。10万行のシステムを書いて、5万行が(自社開発の)共通ライブラリやフレームワークだというのなら、それはおそらく設計が間違っています。まず8割以上は「業務ロジック」のプログラムになるんじゃなかろうか。
割合はとりあえず置いておくとして。
・一般的なフレームワーク(ライブラリ)
・会社でよく使うライブラリ
・そのプロジェクトでよく使うライブラリ
・ある機能でよく使うライブラリ
・完全な固有/個別
って感じで粒度があるので。かくして「固有の業務ロジック」が何割かある、ってのは、Yesだと思います。
そして、たいがいの「業務アプリ」は、フロントエンドがWebであろうがクライアントアプリであろうが、データの本体はRDBMSにあり、それを操作するのはSQLです。よって、オブジェクト指向を駆使してクラス設計をして……という作業はまず入ってこない。
…違和感その１。
これはUMLの多重度でも表現できますが、レガシーなER図でも表現できます。私が設計するなら、記事の文章は「日記記事」テーブルに置いて、日記記事更新のたびに「エントリ」テーブルをメンテナンスすることにしますかね。
「可能である」は、Yesです。
で、こんな感じでテーブル設計をしていくと、はてなダイアリーの画面に表示されている各項目は、ほとんどがSQLで直接的に取得できることがわかります。オブジェクト指向だのデザインパターンだのが登場する余地はない。
………はぁ。
実際仕事でWebアプリを開発するのにプログラマを雇うなら、JavaやC#やオブジェクト指向に詳しい人よりSQLのエキスパートを雇いたいです。私は。
私の観測範囲では、最近のたいていのアプリケーションにおいてこれは事実です。
あ。ここでも「SQLまんせー」な人発見。
つぎ。
…多分、この一言が、ある意味「全てを物語ってる」です。
業務システムは「鶴の一声の理不尽な変更」に耐えうることが前提だから。
うん多分間違いなく orz
とりあえずおいちゃんとしては。
例えば「DBのスケールアウト性能*1」とかその辺の拡張性と、後は「問答無用な修正変更追加」が思考の基準点になってるのと。
その前にそも、OOって、P以外にもあるんだよなぁとか。
或いはもうちょっと身も蓋もなくいくと「"ちゃんとオブジェクトが切れるくらいのスキルレベルの人が"否定しているケースが極めてレア」なのは なんでだろ〜？♪(C)テツandトモ 、とか。
色々と興味深かったので、memo。
*1:そういや。「むちゃくちゃなアクセス数」を経験した後の人とって、大抵会話がかみ合うんですよねぇ。一方で「机上の空論」だったり「固定概念の固まり」だったりする人とは意見が食い違う(苦笑
