つーさのくーかん

デザインパターンは誰かとプログラムを組むときのコミュニケーションの手段になる。
でも、誰かと協力してプログラムを書くのでなければ、それは必要ない。

本当にそうだろうか。

もしあなたが一人でプログラムを書いていたとしても、
30分前のあなたと協力しなくてはならないし、
1時間前のあなた、3時間前のあなた、昨日のあなた、
先週のあなたと協力しなくては、大きなプログラムは完成しないだろう。

誰かと協力しないでプログラムを組むなんてコトはそうそうない。
誰かって言うのは、文字通り他の誰かかもしれないし、来週のあなたかもしれない。
常に相手にわかりやすいプログラムを書くっていうのはやはり重要だと主張したい。

環境がどんどんよくなっている今の時代では、
覚えておかなきゃいけないことも変わってきているように思う。

関数の使い方は都度IntelliSenceが教えてくれる。
オブジェクト指向やポリモルフィズムがプログラミング言語に取り入れられて、
同時に大量のシンボルや変数に注意を払う必要もなくなっている。
バグは減り、生産性をあげることができている。
忘却の時代。OOPのイディオムやデザインパターンがそれらを支えている。

言語が道具であるのと同じで、デザインパターンも道具であるとは思う。
ある「実現したいこと」がオブジェクトコンストラクタでが十分なのなら、
わざわざFactoryを使う必要もないが、それではできないこともある。
そういうときに、パターンを知っていれば近道ができるという程度のもの。

それはパズルの解法の一つになるのではないかと。
便利だと思ったら使えばいいし、そう思わなかったら勉強しなくてもいいのかもしれない。
それでも、パターンに沿った教科書通りの実装というのは理解しやすいものだ。
ゲームを作るときだって、お決まりのアルゴリズムがあるのと同じぐらいおきまりのパターンがあるのだ。
たしかに、そのパターンに名前はついていないかもしれないけれど、
それをデザインパターンと呼ばずして何と呼ぶんだ。