技術を神格化しないようにしたい - プログラミングパラダイムとか
公開日時:
つい最近、いろんな記事を読んで思ったことがあったので、それをメモしておこうと思います。 結論としては、たった一つのさえたやり方なんてものがあったら苦労はしない、ということになるのだと思います。
オブジェクト指向プログラミングと関数型プログラミング
当たり前のことではありますが、例えばオブジェクト指向プログラミングだろうが関数型プログラミングだろうが、それは目的ではなくあくまで手段です。 少なくとも私はそう思います。
オブジェクト指向プログラミングの考え方や、関数型プログラミングの考え方を持っておくことは良いことだと思いますが、だからといってどちらかの技術に傾倒する必要はないはずです。
例えば、内部に状態を持たない入力に対して一意に出力が決まる関数型プログラミングのコードを書きたいけど、テストなどのために DI などで実装の差し替えがしやすいようにクラス化しておこうという判断があるとします。 オブジェクト指向としては内部に状態を持っているほうがおそらく正しいはずですが、状態はデータベースに保存しているので関数寄りの書き方にしたほうが取り回しやすい、とかそんな感じかも。 じゃあこのコードはオブジェクト指向プログラミングの原理をしっかり守ってないから良くないプログラムか、と言われたらそんなことはない、はずです。
そして何よりの問題として、プログラミングの際に大事なことはロジックとか処理であって、オブジェクト指向プログラミングか関数型プログラミングか、ではないと思います。 ここで忘れてはいけないのがオブジェクト指向プログラミングがダメとか関数型プログラミングがダメとかいってるわけではないということです。時と場合によって選ぶべき答えは違ってくるという話です。 なんなら先ほどみたいにオブジェクト指向プログラミングと関数型プログラミングの考え方を合体させてもいいと思います。
たとえば Web ベースの話だったら、大抵の場合においてデータベースが使われていて、データと処理が分離されています。そういう場合には例えば先ほど書いたような考え方は間違っていないと思います。 また、GUI アプリなどの話になってきたらオブジェクト指向プログラミング的にデータと処理を一緒に扱ったほうが良い、かもしれません。
そもそもの話をしてしまうと、クラスと聞くとオブジェクト指向プログラミングじゃないか！となることがあるかもしれませんが、別にクラスはオブジェクト指向プログラミング固有の考え方ではないはずです。多分。 真面目な話、オブジェクト指向プログラミングという言葉が指す範囲が広すぎて、オブジェクト指向プログラミングを否定すると、現代のプログラミングを全否定したようにとられてしまうことがあるのつらい。 そうじゃないねん。それだけが全てでそれだけが正しいわけではないって言いたいだけやねん（怒られそうな似非関西語）。
あとがたり
面白みのない結論なのは認めます。ついでに文章がごちゃごちゃなのも認めます。
神格化をしてしまうこと自体は仕方ないと思うのですが、ふと立ち止まって本当にそうか？と自問自答することが大事だと思います。 一度抜け出してしまえばあとはどうということはないです。常に場に応じた最適を考え行動することができるでしょう。まぁそこまでに多大な失敗を積み重ねましたがそれはそれ（過去形）。
体験として、学校の授業などでは、オブジェクト指向プログラミングはさえたやり方として紹介されることが多い気がします。 これこそが正解！これこそが全て！みたいな正解があれば分かりやすい世界でしょうが、悲しいかなそんなローコストな世界はそう簡単に見つからないのです。 エネルギー消費がえげつないことはわかってますが、それでも選択し続けるしかないのです。
年をとってくるとその選択が苦痛になって徐々に一つの道に傾倒し始めたり、新たな知識を取り入れることをしなくなったりなっていくのかなぁ、と日々おびえている今日この頃。 これ前回も書いた気がします。そうならないよう日々精進するなり、エネルギーコストをそこにさけるように他の消費を減らしたりしていくしかないのかなぁと。