No Programming, No Life

プログラミング関連の話題や雑記

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

業務アプリの業務部分で、オブジェクト指向なんか使わないよね - プログラミング言語を作る日記
というエントリを読みましたが、ちょっとだけ突っ込みを入れてみたいと思う。

「使わない」ではなく「使えない」のでは?

実際に業務アプリの実装において、オブジェクト指向が使われていないというケースはよく耳にする。ところで、オブジェクト指向が使われない理由についてだが、本音を言えば、「使わない」のではなく「使えない」の方が比率が高いではないだろうか。
例えば入社してすぐに戦力に回された新米プログラマは、研修でしか触ったことがないようなプログラミング言語を覚束ないながら使用していくことになる。そんな新米率が高いプロジェクトに至っては「なんでもかんでもオブジェクト指向で書け」というのは少々敷居が高いというのも事実であるとは思う。ちょっとした処理をするのに重厚なクラスを書いて、そられを巧みに連携させる必要が出てくる。
だがしかし、だからといってオブジェクト指向が要らないというのは少々飛躍しすぎな気がしてならない。オブジェクト指向の利点であるカプセル化ポリモーフィズム、そして継承などの有益な機能は利用できなくなる。それにオブジェクト指向はアルゴリズムをシンプルにする力を持っていると思う。見なくていい部分は内部に隠されている。
本当は使えたほうがいいんだけど・・・「使えないから使わない!これでいいんだ、動くから」になってはいないだろうか。

SQLで書けばいいは「効率論」

SQLを直接操作した方が効率がいいことはあるかもしれないが、それはあくまで「効率」の話。
将来に渡ってメンテナンスされ続ける業務アプリであるということを考えれば、ソースの読みやすさ、理解しやすさ、データと処理の結合度の低さといった、もっと重要な視点があることが容易に想像できる。
難解な業務処理を行わせようとすれば、それなりに複雑なSQLが出来上がるものである*1。それを後から保守しなければならなくなったプログラマにとっては地獄以外のなにものでもない。
入念に考え抜かれたオブジェクト設計は、複雑な部分はクラス内部に覆い隠してくれるし、オブジェクト使用者にはフレンドリーなインタフェースのみを提供してくれるものである。バグ発生時も処理は適切に分離されているため、変更箇所および影響範囲の判定も容易に行えるのだ。将来に渡ってメンテナンスしやすい見通しの良いコードが約束されるといってもいいだろう。

また、ORマッピングを使うことの利点としては、SQLの方言を吸収し、どのデータベースに対しても一貫した操作で処理が行える点も挙げられる。将来データベースシステムが変更されるといった場合であっても、ORマッパーが対応していればソースを変更する必要はない。さらに言うなら、SQLという低レベルな処理をライブラリにすべてお願いすることで、うっかりエスケープし忘れなんてバグは最初から入り込む余地はなくなるだろう。

本当のエキスパートとは

SQLのエキスパートはそれはそれで素晴らしい。彼らはどんなに複雑な処理要件もSQLという武器一つでまるで魔法のように片付けてくれる。しかし前述のように万人にとって理解しやすかったり、メンテナンスしやすかったりするかどうかは疑問が残る。
最後に、本当のエキスパートとはなんだろうか。
私の考えるエキスパートとは、どちらか一方のみではなく、互いの欠点と利点を理解した上で利点のみを組み合わせて使うことができる人材である。ボトルネックとなる部分は高速なSQLを魔法のように操り、万人が理解できるよう、十分に考え抜かれたインタフェースを業務アプリのビジネスロジック部分のコードに提供する。そんな設計・実装ができる人材だと私は思う。

*1:私は他人が書いた500行くらいのSQLに泣かされたことがある。