GoFのデザインパターンが今でも有効だと感じた2つのポイントと1つの注意点

簡単に結論

デザインパターンを勉強してみて、以下のような点で有効だと感じました。

僕は新卒でエンジニアとして2年間働いて現在育休をとっています。

育休中は手を動かす時間が取れないので、具体的な技術よりも抽象的な技術を勉強したいと思い、空き時間に設計に関する知識をつけることにしました。

DDDとかクリーンアーキテクチャについて勉強した後に、「じゃあ小さい機能単位で書くようなコードはどう綺麗にすればいいんだろう？」と考えてデザインパターンを勉強することにしました。

しかしいざ、デザインパターンについて調べてみると、実際は役に立たないという意見がちらほらみられました。

というのが主な意見なようでした。

せっかく勉強するなら役に立つものを勉強したいと思っていたので同じように悩んでる人に向けて、実際勉強してみてどうだったのか解説します。

学習教材はこちらを使用して、Golangで実装しました。実際に学習してみて感じたメリットをまとめます。

デザインパターンを学習することで、何をクラスにするか、何をinterfaceにして交換可能にしておくかといった新たな視点を得ることができました。そしてそれらは自力で思いつくのは難しかったと思っています。

例えば、以下のような考え方です。

教えられると理解するのは難しくないのですが、全くの0から自分でこのアイデアを考えつける気はしませんでした。

こういったアイデア一度頭の中に入れておけば、それらを適応できる場面に遭遇した場合に、完全な自力でひらめくことはできないけど、パターンを適用できるという絶大なメリットがあります。

デザインパターンの有用性に反対する意見としてよく見られるのが

「フレームワークを使って開発するのが主流なのでそんなに複雑なプログラムは書かないからデザインパターンは役に立たない」

という意見です。

しかし逆を言えば自分でフレームワークやライブラリを作成するときはデザインパターンの考え方を知っておくべきだと思います。

フレームワークを作る機会はほとんどの人にとってあまりないと思いますが、小さいライブラリを業務で書く可能性は高いと思うので、デザインパターンを知っておくことは重要だと感じました。

GoFのデザインパターンの中には複雑なパターンがあり、それを現場で使うのは控えたほうが良さそうと思いました。

解説本を読みながらでも理解が難しいと感じたパターンがいくつかあったので、デザインパターンを知らない人がいきなり業務中にそれを見たら、かなり混乱します。

Template Method PatternとかBuilder Patternは初見でも分かると思いましたが、Abstract FactoryやVisitorみたいな難しいパターンを実際に使うのは、かなり慎重になったほうがいいと感じました。