もちろん有用だとは思うんだけど、自分でデザインパターンを用いた実装をした経験がほとんどない。「Storategyパターン的な感じだな」とか「こいつはFacadeだな」とか思ったりはするけど、明示的に名前をつけたり書籍にあるクラス構成をそのまま利用したことはない気がする。あ、FactoryとRepositoryは作ったことあるか。まあでもアプリケーション開発の実務でデザインパターンをバリバリに書きまくっているという人は少ないのではないだろうか。
フィヨルドブートキャンプでコードレビューをしていると、時々デザインパターンを使ったコードを見ることがある。練習という意味ではもちろん良いことだし、実際そのままレビューしてOKを出すことも多い。ただ、もし実務だったらと考えると「ユースケースに微妙にそぐわない」もしくは「抽象化が過ぎる」みたいな理由でこのパターンやめましょうというフィードバックをする気がする。
Java系ライブラリの中身を見ているとデザインパターンを使ったコードが山ほど見られるのだが、Rubyとかだと少ない気がする。ちゃんと数えたわけではないけれども。言語の特性や書かれた時期によって違うであろうことは察しがつく。おそらく柔軟な書き方ができる言語ほど、また新しい言語ほどデザインパターンを使わなくなっていそうである。というか、有用でよく使われるパターンはそもそも言語機能に組み込まれていて自分で書く必要がなかったりする。Iteratorとか。
それから、いくつかのパターンはシンプルにあまり有用でないように思える。Singletonとかね。あるいはパターンというほどでもないやつとか。まあでもよくある設計に名前をつけるという行為は意思疎通を便利にする意味では有用か。
既存のコードを読むときや、自分で設計を考える時にデザインパターンの知識があった方がいいのは間違いない。でも別になくてもそこまで問題ないような気がするし、自分で考えた設計が「よく考えたらこれってTemplate Methodだな」みたいな感じで後から気づくことも多い。デザインパターンを学んだことで得られた知見が設計の時に役立っているのかもしれないけれど、デザインパターンありきで物事を考えるというのはあまりないような気がする。
…とかなんとか色々考えていたのだけれども、正直そんなに詳しいわけでもないし、端的にいうとよく分からない。誰か現代のソフトウェア開発におけるデザインパターンの立ち位置を解説とかしてくれないかなー、と思ったらt_wadaさんがFukabori.fmでがっつりやってくれていた。
去年拝聴して感動したので身の回りの人には勧めていたのだが、一年経ってもう一度聞いてみるとやはり素晴らしい。ということで全プログラマに聞いてもらいたいくらいオススメです。
というか、GoFもしくはt_wadaさんはこの話題で書籍出してくれないかなあ。
