Murga

個人的に言いたいコト・主張・気持ち。

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 処理とデータ保持を別クラスに分けるのが一番良いやり方です」つって元に戻した。

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

「男は黙って!」

「先人の知恵にならえ」

「口頭で伝えた方が早く済む病」のバカを駆逐したい

ビジネスにおいて、何かにつけて「メールなどの文章より口頭で済ませた方が早い」と言う奴がいるが、口で説明した方が上手くいくという発想はほぼ 100% 失敗する、間違った思考だ。

口頭の方が上手くいくと思っているのは伝える側だけで、総じて聞き手を意識できない自己中だ。

だいたい口頭伝達を好む奴は文章を書くのが苦手で、それはつまり日本語の言語能力が低いということだ。話し言葉と書き言葉は違うなどというがそれは日常会話の話で、ビジネスで伝えるべきことを正確に伝える技術としては、文章に落とし込めるだけの「言語化」ができる能力が必要なのである。

それがなぜか、口頭だと言語化する能力が要らなくなると思っているのか、「そっちの方が伝わる」と言いたがる。日本語が不自由な奴は話しても書いてもダメなんだよ。だったら記録が残る文章でのやりとりの方が良い。


受け手として、文章であれば、何度も読み返したり、主述の関係を整理して読み取ったりすることができる。その文章を引用して内容を確認する返事が書けたりする。

逆に口頭での会話というのは、受け手は話し手が展開する話の順番に支配され、話し手の時系列に合わせて聞かなくてはならない。これは初めて理解する内容が多い程難しい作業になる。話し手は書く時と違って言いたいように喋るので、時系列や物事の順序が整理されていないことが多く、それを受け手が再整理しながら聞く必要がある。

そうすると質問による確認の回数が増えるし、口頭は大抵記録が残らないから、「言った・言わない」とか「自分は伝えた・いや伝わってない」といった揉め事の種になる。

一度聞いて全てを理解し、二度と忘れない、というようなことは人間には不可能だ。だから時には何度か同じことを聞いてしまうことになるものだ。そうしないようにいくら気を付けたところで、人間には忘れる能力が備わっているものなので無理な話だ。だったら1人で読み直せる文章の方が、話し手に時間を取らせずに済む。


要するに、話し手の方が情報を持っているのに、それを整理して理解する労力を聞き手に委ねているのが、口頭伝達というものなのだ。

ビジネスにおいては大抵は話し手が上司で、内容が業務指示になるワケだから、指示を受ける部下の方には絶対的に会話の内容に対する知識が足りていないはずだ。

それを部下の方に丸投げしてうまく理解しておけというのは、上司としては無能でしかない。

指示を出すなら、文章に理路整然と落とし込んで伝え、不明点や確認事項は文書でやり取りして記録を残すのだ。急いでいる時、「些細なこと」と思っている時こそ、口頭で済ませてしまうとあとあと記録が残っておらず、面倒なことになるのが見えている。


こうしたことを、話し手は考えない。口頭で発信するのは話し手としては楽だからだ。自分が問題の種になっている場合、その人は問題を認知出来ないので、周りが直接的にその行動を否定してあげないといつまでもそいつは変わらない。

自分が日本語をまともに話せていると思うな。お前の日本語に1番問題があって、みんな迷惑してんだ。