業務アプリの業務部分で、オブジェクト指向なんか使わないよね - K.Maebashi's はてなブログ

久々の更新なのでちょっとは刺激的なことを書いてみる。 今時のプログラマにはオブジェクト指向は必須、常識、みたいな言説はよく聞きます。 しかし、煽りでもなんでもなく、実のところ現場ではあまり使わない、というのも事実だったりします。 そりゃ、ライブラリやフレームワークでは使いますよ。しかし、多くのプロのプログラマが会社で作るような「業務アプリ」の世界において、プログラム全体の中でライブラリやフレームワークの占める割合は大きくはない。10万行のシステムを書いて、5万行が(自社開発の)共通ライブラリやフレームワークだというのなら、それはおそらく設計が間違っています。まず8割以上は「業務ロジック」のプログラムになるんじゃなかろうか。 そして、たいがいの「業務アプリ」は、フロントエンドがWebであろうがクライアントアプリであろうが、データの本体はRDBMSにあり、それを操作するのはSQLです。よって、

[kmaebashi]

2年前に書いた文章だが、Twitterに流す目的でいまさらブクマする。

[ghostbass]

最近のはやりならBankAccountModelとBankAccountDTOに分割とか、かな。/じゃあ一個の巨大なグローバルクラスに各種データアクセスと描画ロジックをまとめる？そういうクラスをメンテする気になる？

[tanakahisateru]

むかし、プログラムなんて足し算と代入ができたらあとは努力と根性って言われてたな

[srkzhr]

"たいがいの「業務アプリ」は、フロントエンドがWebであろうがクライアントアプリであろうが、データの本体はRDBMSにあり、それを操作するのはSQLです。"

[fujiyoshisyouta]

http://okyuu.com/ja/news/6139 経由。/ OOPにもやっぱり得手不得手があるんじゃないか、と言うところに落ち着きそうな話。

[fukken]

×オブジェクト指向なんか使わない　○うちではオブジェクト指向なんて使わない//早期にドメイン・モデルを作りこむと良くないという点には同意するが、それでもあった方がラクなものはある

[rryu]

そこでRailsのActiveRecordですよ。あれはSQL大好き人間が作ったとしか思えない恐るべきO/Rマッパ。

[lizy]

エンティティに対する制約・操作・ロジックも時には必要になるのではないかと｜DBに出し入れする程度のものであればいらない、というかもっと単純化してほしいぐらい

[ch1248]

確かにSQLが全面的に何か言われるってことは少ないような。

[simpleboxes]

「業務アプリ」の定義がよく分かりません。私の場合、仕事でオブジェクト指向は必須。使えないと仕事にならないと言っても過言じゃないぐらい実際使っています。結局作るソフトウェアに依存するような？

[fumokmm]

ちょっと刺激的なことを書いてみる。業務アプリしか書けないようならそのうちそんなプログラマ要らなくなるよね。

[oldriver]

あまり使わないし、ゆえに使えない。普通のプログラマは手続きしか書かないから、そもそもフレームワーク外のクラスを自分で作ることは無い。

[suginoy]

「実務で重要なSQL」そしてバッチ処理

[pekepekesamurai]

「使わない」んじゃなくて、「使えない」が大半じゃないだろうか？SQLができる云々はごもっとも。だけどOOPがちゃんと使えれば、(設計次第だけど・・・)メリットのほうがでかいと思いまふ。

[Nagise]

業務システムのボリュームゾーンである業務ロジックを書くにはAPIライブラリの使い方だけ知っていればよい。という、お膳立てをするフレームワークにはOOP的設計が必要だ。技術力の偏在化が進んでる。

[hatest]

タイトルを「SQLかわいいよ。SQL」に変えると好感度が上がるぞ

[int128]

現実は現実でいいんだけど、RDBの制約がAPに波及しているのが悪い。RDBがkey-value DBになれば設計も変わるだろう。

[yura_saito]

業務システムは歴史が長いのでライブラリ化できるようなところはすでにライブラリ化してるのだろうとは思う/まあ暇があったら何か書くかも

[katzchang]

違和感。「まず8割以上は「業務ロジック」のプログラムになるんじゃなかろうか」オブジェクト指向って、そもそもライブラリと業務ロジックの区別はないでしょー。

[cyokodog]

同意。独自性の強い業務ロジックにおいては使えなくてもそれほどこまらない。汎用性を持たせようとするとAPI的にも保守的にも使えたほうがいいけど

[niam]

J2EE全否定疑惑。でも、基本的には同意。Transaction処理がcriticalに必要な部分（金銭処理）以外はもう、RDBもいらなくて、Key Value Storeでいいんじゃないでしょうか。Tokyo Cabinetとかmemcacheとか使える人を雇えば・・・

[yuki_2021]

割と同意。オブジェクト指向やデザインパターンよりもSQLなどのデータベース設計が重要だよねということ。

[terazzo]

ロジックのみ書けば良いというのはアーキテクチャとして完成形に近いのだろう。／SQL書けば完了系のシステムだと、権限の扱いとかはどうしてるんだろう。