DAO にデータ持たせて単一原則守れてるとか言ってる奴がいたんすよ〜

「DAO にデータ持たせて単一原則守れてるとか言ってる奴がいたんすよ〜」

「ナァ～～にぃ～～～！？　ヤッちまったなぁ！！」

…

DAO (Data Access Object)、あるいは Entity とも呼ばれたりする、DB アクセスを担当するクラス。

それと、DTO (Data Transfer Object)、あるいは厳密には違いがあるが、Value Object とか呼ばれる、データを抱えておくだけのクラスがある (Java だと Getter・Setter しか持たない POJO なやつだ)。

それぞれ、「DB アクセスする」という単一の役割、「データを保持する」という単一の役割を担うのだが、これを一つのクラスがやっていい、と言っている奴がいた。

「DB 処理も抱えるデータも少ないから、クラスあんまり増やしたくないし、そもそも『○○データを扱う』って意味では単一役割ですよね？」とか言ってた。

お前にはオブジェクト指向の基礎もないし、日本語に対する言語能力の欠落からなんとかしないといかんな、という感じで笑っちゃったのだけど、こういう柔軟な発想 (笑) ができちゃう奴もいるんだなーと。

単一原則は同時に拡張性も考慮してるわけで、オープン・クローズド原則とも関わってくる。

ある一つのクラスが、(1テーブルに関する) DB アクセスだけに終止してるクラスであるなら、機能拡張もしやすいというものだ。

「持つデータが少ない」というのは今の作りだからいえることで、今後どのような機能改修が入りうるか全く考慮していない。

「アレしてコレする」という複数の同士を直列実行して一つの役割を表現するようなクラスを1度作ってしまうと、なんでもかんでもそのクラスに追加してしまい、いわゆる「神クラス」に育ってしまう。

であれば、最初からオブジェクト指向の原則を守り、たとえ今後データの種類がなかなか増えそうにない性質のデータであっても、その規模に関わらず、「ある1テーブルに DB アクセスをする役割のクラス」と「ある1テーブルのデータを保持する役割のクラス」は分離しておくべきなのだ。

…

また、フレームワークなどの仕様にもよるが、「DB アクセスはシングルトンなクラスで行う必要があるが、データを保持するインスタンスは複数作りたい」とかいうときに、両方の役割を1クラスでやろうとすると一発で破綻する。

オブジェクト指向は先人の知恵だ。今あるものは、自分なんかよりよっぽど頭の良い人間たちがよってたかって作ったものなのだから、自分なんかの発想がそれに勝ると思っている時点でそいつは終わりなのだ。自分なんかが思いつく程度の発想は既に考え尽くされていて、それだと何らか問題があるから、そうではないやり方が提唱され一般化しているのだ。それに気付かないようでは「四角い車輪の再発明」を繰り返すだけだろう。

…

今回とあるドアホがそのように提案した部分は、結局正しく動作しなくなることが目に見えていたから、自分は「言うとおりに直したらこういうタイミングでデータの受け渡しができないかもしれませんよ、それでも直すんですね？」と聞いたが、ドアホなので何の根拠もなく自信満々に「いいからやれ」状態だった。

「そこまで言うなら従います」と言って直したが、案の定指摘したところでバグが出た。こっちからしたらこうなるのは当たり前だろと思ってたのだが、そいつはただただ「クラスを増やしたくない」という謎のこだわりで試行錯誤してて、「じゃあこれをこっちで呼ぶようにして…」「それだとこの条件分岐ができなくなるからこっちにも書いて…」とか言ってたのだが、そもそも「DB 処理」と「データ保持」を1クラスでやろうとしてる無理がネックになって起きてるバグなのだから、クラスを分けるしかないのだ。

終いには「他に良いやり方ないかな？」と聞いてくる始末なので、「オブジェクト指向の原則と、フレームワークの制約に従って、DB 処理とデータ保持を別クラスに分けるのが一番良いやり方です」つって元に戻した。

バカのクセに粋がるとこうなる。

…

「男は黙って！」

「先人の知恵にならえ」