久々の更新なのでちょっとは刺激的なことを書いてみる。
今時のプログラマにはオブジェクト指向は必須、常識、みたいな言説はよく聞きます。
しかし、煽りでもなんでもなく、実のところ現場ではあまり使わない、というのも事実だったりします。
そりゃ、ライブラリやフレームワークでは使いますよ。しかし、多くのプロのプログラマが会社で作るような「業務アプリ」の世界において、プログラム全体の中でライブラリやフレームワークの占める割合は大きくはない。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アプリを開発するのにプログラマを雇うなら、JavaやC#やオブジェクト指向に詳しい人よりSQLのエキスパートを雇いたいです。私は。
私の観測範囲では、最近のたいていのアプリケーションにおいてこれは事実です。
……と言いつつ、私自身はCADっぽいアプリにいたことが多かったので、SQLはあんまり得意じゃないんですけれど。
Web界隈を見渡して、オブジェクト指向とかLL言語とかに対し、実際に実務で重要なSQLが取り上げられることがあまりに少ないので書いてみました。
