Hatena::ブログ(Diary)

プログラミング言語を作る日記

2009-04-27 業務アプリの業務部分で、オブジェクト指向なんか使わないよね

[]業務アプリの業務部分で、オブジェクト指向なんか使わないよね

久々の更新なのでちょっとは刺激的なことを書いてみる。

今時のプログラマにはオブジェクト指向は必須、常識、みたいな言説はよく聞きます。

しかし、煽りでもなんでもなく、実のところ現場ではあまり使わない、というのも事実だったりします。

そりゃ、ライブラリフレームワークでは使いますよ。しかし、多くのプロのプログラマが会社で作るような「業務アプリ」の世界において、プログラム全体の中でライブラリフレームワークの占める割合は大きくはない。10万行のシステムを書いて、5万行が(自社開発の)共通ライブラリフレームワークだというのなら、それはおそらく設計が間違っています。まず8割以上は「業務ロジック」のプログラムになるんじゃなかろうか。

そして、たいがいの「業務アプリ」は、フロントエンドがWebであろうがクライアントアプリであろうが、データの本体はRDBMSにあり、それを操作するのはSQLです。よって、オブジェクト指向を駆使してクラス設計をして……という作業はまず入ってこない。私は銀行のプログラムを書いたことはないけれど、教科書に出てきそうな「BankAccontクラス」って実在するんでしょうか。BankAccountテーブルを操作するためのユーティリティクラスでもなく、BankAccountテーブルのレコードを表現するための構造体的なクラスでもない、インスタンスが実際の「口座」と1:1に対応してそれに対する操作を公開しているようなものって。

こういう話をするときは、具体的な例をベースにしないと生産的ではないので、今みなさんがまさに見ているはてなダイアリーを例にしましょう。

はてなは「ブログ」ではなく「日記」であり、1日分の記事がひとつのかたまりとして解釈されていて、1日にいくつかの記事(エントリ)を書こうと思ったらはてな記法で「*」を使う、という、普通のブログからすれば相当変態的な仕様になっているんですが、この構造を表現すれば、

  • 1「ユーザ」に対し、n「アカウント」(サブアカウントとやらがあるらしいので)
  • 1「アカウント」に対し、1「ダイアリ」
  • 1「ダイアリ」に対し、n「日記記事」(「日記記事」は1日分の記事を表現する)
  • 1「日記記事」に対し、n「エントリ」

となるでしょう。これはUMLの多重度でも表現できますが、レガシーER図でも表現できます。私が設計するなら、記事の文章は「日記記事」テーブルに置いて、日記記事更新のたびに「エントリ」テーブルをメンテナンスすることにしますかね。

で、こんな感じでテーブル設計をしていくと、はてなダイアリーの画面に表示されている各項目は、ほとんどがSQLで直接的に取得できることがわかります。オブジェクト指向だのデザインパターンだのが登場する余地はない。うちでは右サイドバーに「カレンダー」を出していますが、これなんかSQLでGROUP BYをかければ一発であるのに対し、下手にORマッパーなんぞを導入してSQLを隠そうとすると変なことになるんじゃないでしょうか。

以前、こんなことを書いたことがありますが、

http://d.hatena.ne.jp/kmaebashi/20070522

実際仕事でWebアプリを開発するのにプログラマを雇うなら、JavaC#オブジェクト指向に詳しい人よりSQLエキスパートを雇いたいです。私は。

私の観測範囲では、最近のたいていのアプリケーションにおいてこれは事実です。

……と言いつつ、私自身はCADっぽいアプリにいたことが多かったので、SQLはあんまり得意じゃないんですけれど。

Web界隈を見渡して、オブジェクト指向とかLL言語とかに対し、実際に実務で重要なSQLが取り上げられることがあまりに少ないので書いてみました。

某ベンダーSE某ベンダーSE 2010/06/13 12:34 複雑かつ整合性のとれた中間状態を維持する必要のあるエントリー画面なんかでは、オブジェクト指向は非常に有用だったりしますけど?
逆に、参照系やバッチ処理なんかだとオブジェクト指向やORマッパーの出番はありませんね。

sakurai_youheisakurai_youhei 2014/07/29 22:26 「ほとんどSQLで出来るよね」って実装されたら後追いする立場とすると辛い。オブジェクトとしてある程度振る舞いが抽象化されてれば非デベロッパでも追えるけど、一旦SQLマジックで完結されるとSQLがかけない人には敷居がぐんと高くなります。

kmaebashikmaebashi 2014/07/30 03:33 こんにちは。
SQLというのは現在成功している言語の中ではほぼ唯一「宣言的に書ける言語」なのであって、下手なOO言語なんぞよりずっと抽象度は高いと思います。まあ得手不得手はあって、100行くらいのSQLに同じパターンの繰り返しが何度か出てくることがあって、なんとかならないかとは私も思っているのですけど。

いくいく 2018/07/13 00:31 業務で必要な正しい粒度のデータを、正しい形で格納できれば、あとはSQLでなんとでもなる。
画面はウィジットの組み合わせで作れるし、最近ではSQLでJSONが入出力に使えるので、DBとフロントの間のアプリーサーバーはフロントとDBの間の受け渡しのみ。
一個一個の画面なんて、3日で作った画面なら、(すでに動くものがある=仕様が固まっている!だからより短期間の)2日で再作成すればいい。(メンテナンス性?直すより、作り変えてもっといいものを出せばいい)
※せいぜい使ってknockoutどまり

けれど、データはそうはいかない。あとから”すみません、データ足りませんでした。過去データを含めて再入力してうださい!”とはいえない。データには日々の仕事の積み重ねが集約されているのだ。
大切なのはシステム(PGM)ではない!データなのだ!

御託をならべず、少しでも早くシステムを作り、使ってもらう。データを蓄積するのが早ければ早いほど、活用するチャンスが生まれる。システムにデータが乗れば、ユーザーのしごとぶりは変わる(考える時間ができる、人にしかできないことをやる余地がうまれる)
そう思っているのですが、なかなかゼネコン体質のシステム屋さんたちには受け入れたもらえません。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証