依存関係逆転の原則

■所感
いくつか前の章でも出てきたが、うまく消化できていなかったので「助かった」というのが本音。エンジニアやってて一番怖いのが、「わかっているつもりになっている」状態と、「未消化のまま放置している」状態だと思っているので。

図解を注視しながら、章の後半部分を何度か読み返してようやく理解できた。インターフェイスをimplして具象化されたクラスから見ると依存関係が確かに逆転している。逆に、具象化されたクラスを継承した場合は、依存関係が逆転しない。要するに、具象化されたクラスをバカみたいに継承するなよ、ってことだと理解した。

インターフェイスを使っていればそんなことは起こらないと思うんだけど。。どうなんだろう？.netのときはありまくりだったが、javaになってからはほぼ見かけない気がする。たまたまなんだろうけど。

本当に個人的な感想なんだろうけど、javaのほうがインテリジェンスというか、ハイソサエティな感じがするな。。
技術者の質もいいように思えるし。。自分の場合は、たまたま、というにはちょっと偏りすぎている。

■内容について
特筆すべきことはないと思う。こういう原則があるのね、くらいで、業務上あまり意識する必要はなさそうだ。

ちょっと脱線するが、クリーンアーキテクチャという言葉に引っ張られすぎて、根本的な部分での見落としをしているエンジニアが多すぎると感じる。

エンドユーザーって、どんなアーキテクチャで書かれているかなんてどうでもいい話で、ゲームにせよWebにせよ、見た目とレスポンスが良いことがエンジニアには求められていると思う。見やすさとか面白さは、プランナーのお仕事とした場合だけど。

UI、ビジネスロジック、ストレージときれいに分離できたとして、ビジネスロジックはUIやストレージを本当に意識しなくていいものか？と疑問に思うことが多々ある。仮に、ストレージがOracleだとして、設計でOracleを意識する必要がないんだろうか？Postgresだった場合は？

ロールバックセグメントで動いているOracleと、追記型構造のPostgresでは根本的な考え方が違う。確かに、ほぼ同じような設計で動きはするが、ストレージによって得意不得意があるのは当たり前だ。インターフェイスで抽象化しておいて、implして具象化したとしても、DBの正規化がうまくいっていなければ速度なんて出るはずがない。Oracleっぽい正規化の状態で、Postgres上で動かそうとしても全く動かないアプリになってしまうケースもあると思う。例えば、UIがステートマシンになっていて、受注情報のステータスを頻繁に更新するような作り。受注情報はたくさんのフィールドを持っているが、Oracleだったらセグメント管理だから問題なく更新がかかると思う。でも、Postgresだったら更新するたびにタプルが増えていって、autovaccumに引っかかったら問い合わせ受付を停止してしまう。postgresが前提になっていれば、設計時にある程度意識して正規化するけど、アプリの作りに注力したプロジェクトだとどうだろう？

クリーンなんだから、DBなんてなんでもいいだろ？

という理論は通用するんだろうか？？
極端な例なのかもしれないが、そんなことをふと思った。