オブジェクト脳に目覚めたときの話

私は10年以上SE/PGとしてSIerのITプロジェクトに関わってきました。大半はWebサービスの開発です。

それ以前から個人的にVisualBasicでゲームをちまちま作ったりしていたので、使い慣れない言語でもロジックを組むことはそれなりに出来ていて、あとは他人のソースを見様見真似でなんとかなっていました。
ちゃんと動くものを作ってるし、ソースも見やすいように細分化してるし、再利用できるようにしている。
文句も言われなかったし、これでいいじゃん！

それ故に、プログラミング手法やソフトウェアアーキテクチャなどについてはボンヤリと理解したようなしてないような…という状態のまま、長年だらだらと続けていました。

そんななかで、私が「ああ、オブジェクト指向ってこういうことだったんだ！」と、一気に霧が晴れたような気がしたときのお話です。

DAOのインターフェースはなぜ必要？

DAO(データアクセスオブジェクト)は、データベースアクセスを行うためのデザインパターンで、これによりビジネスロジック(以下BL)からデータ操作に関する処理を分離することができます。
で、実装例をググってみると、多くの場合DAOインターフェースとDAO実装クラスを作っています。
このインターフェースを作る理由としてよくあるのが、「DBを変更する場合に影響を最小限に抑えるため」という言い方。
はたして、本当にそうでしょうか。

私の経験上、DBの変更はインパクトが大きいと判断され、開発初期ではあり得るものの、開発の後半やリリース後に実施することはほとんどありません。テーブル定義の変更なども多くはBLの変更に伴うもので、上記の理由はあまりメリットがないのでは？と思っています。

なので、よく分かんないけどみんなそう作ってるから同じようにしておこう、くらいの考えで作っていました。
たまに実装から入って、忘れてたーと気が付いて後からインターフェース書いたり。
完全な思考停止ですね。
こんなことで自分の成果物に責任が持てるのでしょうか。

ではなぜインターフェースを作るのか。
こんな同じような意味のないコード、いつまで書き続けなければならないんだー！と嫌になったとき、じっくり考えてみました。

BLとDAO、Webサービスにとって大事なのはどちらでしょうか。
サービスとして提供したい機能は、BLで実現します。
つまりソフトウェアの構造として、BLが上位でDAOが下位。
DAOはBLがDBにアクセスするための補助にすぎません。
なのでDAOはBLを実現するために作る、BLの要求を満たすために作られるもの、と考えることができます。

一方、BLもDAOも、それぞれメソッドはブラックボックスであるべきです。
なのでお互いがお互いの中で何をやっているかを知ることはない。
しかし、DAOはBLの機能を実現するための実装をしなければならない。

ここでインターフェースの出番です。
BLは、必要としているDBアクセスの内容を必要最低限、DAOに伝えなければなりません。
「この条件を満たす情報をください」「これをDBに登録してください」
これはインプットとアウトプット、引数と戻り値。
BLからDAOに対して、欲しい機能の引数と戻り値を提示する。
これができるのがインターフェースです。注文依頼書のようなものですね。

つまり、DAOのインターフェースはBLによって作られる。
こう考えたときに、「あ、アレと同じじゃん！」と気が付いたのです。

依存性逆転の原則

オブジェクト指向プログラミングにおけるSOLID原則のひとつです。
上位は下位に依存してはならない。
下位は上位が定義した抽象に依存する。
この考え方とちょうど合致したのです。

BLはDAOがなければ機能しない、つまり上位は下位に依存していると言えます。
しかし先ほどのインターフェースの考え方になぞらえると、BLの都合で作られたインターフェースを実現するためにDAOを実装する。
つまり上位が定義した抽象に下位が依存しています。
完全に一致…！

この考えに至ったとき、「プログラミングの思想は、ちゃんと自分がやっている開発にも根拠をもって適用できるんだ」と思ったんですね。
脳内で別々に存在してたパーツがピッタリはまったようなスッキリ感。

覚醒その後

これをきっかけにしてシステムの設計思想とか開発手法に興味をもち、実践の場でも、採用しているアーキテクチャのメリットを生かすような実装をするように心がけるようになりました。
他の人のコードを見るときもそれなりに意図を理解できるようになったし、イケてないコードを修正してもらうときも、ちゃんと理由を説明できるようになりました（笑）

あ、最近の興味はレイヤードアーキテクチャ、特にクリーンアーキテクチャです。DDDも面白いですよね。