続き

上記で書いたようなことを、一つずつ、ただ機能としてアプリにとりこんでいったら、そのアプリは肥大して、最後には手が付けられなくなるだろう。windowsのように。
ＤＲＹを実現すために、手続きや関数にまとめたり、クラスや継承を使ったりすることも良いが、一番強力なのは、抽象化のためのパラダイムやモデルだ。
構造化プログラミング、関数型、オブジェクト指向、リレーショナルモデルという道具をうまく使えば、個々の抽象化や部品化は、より効率的に進むようになる。
ただ、これらの道具にも限界があると思う。

　普段プログラミングをしていて、手続きや関数を使って部品化を進めているときに、
どうにもうまくいかず、すっきりしない、そんな時がある。そういうときは、問題をすこし引いた位置から眺めて、部品化の切り口を変えてみる。すると、一気にすっきりと部品化できる。こういうことは一般的にもきっと良くあることなんだろうと思う。

　この、抽象化の切り口、というのは感覚的なものだが、これもおそらくモデル化の一つだと思う。関数型プログラミングやオブジェクト指向という道具は、当然抽象的なモデルであって、目の前の具体的な問題を解決するために、それらの道具をどのように適用するかは、その都度誰かが考えなければいけない。その際には、きっと頭の中で、「これは、このデータベースのここらへんのデータをJsonに変換する関数だ」とかなんとか、関数に役割を割り当てたり、そのための全体的な処理の流れ、もしくは状態マシンのイメージのようなものを思い浮かべていると思う。
　で、その漠然と抱いているモデルが、不適切なものであれば、関数化やクラス化をいくら頑張ってもコードはぐちゃぐちゃのままだ。それで、仕方が無いので、細部を見つめるのを中断して、全体をみながら頭を整理する。このとき、モデル化をやりなおしているんだろう。

　でも、このモデル化作業をいくらやり直して頑張ってみても、うまくいきそうに無いときは、それらのモデル化のベースとなっているモデル、つまりオブジェクト指向やリレーショナルモデル自体を見直してみる必要がある、と思う。
　
　続くと思う。