前回、前々回は関数型に関する話だったけど、今回はその他で感じたことに関して。
データベースの重力
オブジェクト指向の理解を妨げる原因の一つとして、データベースに引っ張られがちというのがありそう。
この発表ではそのことを指摘してた：
前回の記事でも、データベースの都合に引っ張られて変な設計になってると書いたけど、これはよくあることなんだと思う。 そのせいで適切なクラスを用意してメソッドを用意するということができなくて、ただのデータクラスを関数でゴリゴリいじるというよくない設計になる感じ。
これは個人的にはなるほどというか、そんなこともあるんだなと思ったり。 というのも、自分はデータベースを使うような開発というのはほとんどやってきてなくて、RubyやPythonでCLIのツール書いたり、Cで組込み開発したり、JavaやC++でIDEの開発をやってきたりしたから。 もちろんデータの保存や読み込みをしたりはするけど、その場合もプログラムで扱うデータ構造がまずあって、必要に応じてそれをファイルに書き出したり読み込んだりするので、その入出力の形式がプログラムでのデータ構造に引っ張られることはあっても、その逆というのは普通ありえない。
ただ、今はWebアプリの開発をしてる人が多くて、そうなるとデータベースを使わない開発は少なく、まずデータベースでのデータ構造があって、それをどうこうするのがプログラムの役割になりがちなんだろうね。 そうすると、本来はプログラム内でのデータ構造がまずあるべきなのに、データベースの都合に引っ張られて歪な設計になってしまうと。
オブジェクト指向を理解したり、ドメイン駆動でビジネスロジックをコードで表現できるようにするには、この「データベースの重力」から逃れる必要がありそう。 データベースのデータ構造に引っ張られてる状態では、プログラム内で適切なクラスを定義できるようにならないんだろうね。
このデータベースに引っ張られているというのは他の発表でも感じたり。
たとえば、きしださんの「オブジェクト指向は必要なのか」もそう：
結局、ワンショットでデータベースからデータ読んでモニョモニョしてデータベースに返すみたいなアプリしか作らないから、そりゃオブジェクト指向いらないんじゃね？みたいにもなるよなぁと。 データベースでのデータ構造がまずあって、プログラムであるべきデータ構造とか考えることもないんだろうし。
これに関しては久保秋さんの「せっかくモデル図描くのなら、嬉しいことが多い方がいいよね！」でも、フロントエンド開発がホットになって、モデルを描くことが減ったという話が出てる：
まぁ、それで済む仕事だけしてるならそれでもいいけど、もっとプログラマとして高度な仕事をしていきたいなら、データベースを使わない開発も経験して、オブジェクト指向やドメイン駆動設計について理解を深めた方がいいんじゃないかと思う。
フロー指向とオブジェクト指向
他に感じたこととして、やっぱりフロー指向で考えてるかオブジェクト指向で考えてるかの違いは大きいんだろうなということ。
たとえばこの発表：
タスク指向UIとオブジェクト指向UIという形で対比してるけど、これはフロー指向とオブジェクト指向の対比とも言える。
あるいはこの発表：
開発で苦しんでる様子を伝えてるけど、やっぱり処理の流れをどうコントロールするかという観点で設計してる感じがあって、それだとまぁ苦しいよねとなる。
一方でこの発表：
この発表では処理をちゃんとデータとして扱ってて、適切なインタフェースを切ることで部品化をうまくやってる。
そんな感じで、データベースの重力から抜け出すこと、フロー指向から抜け出すこと、そしてデザインパターンを学んで活用していくことがやっぱり重要よね。
今日はここまで！
