GoFのデザインパターンが今でも有効だと感じた2つのポイントと1つの注意点
簡単に結論
デザインパターンを勉強してみて、以下のような点で有効だと感じました。
- 自分では思いつくことが難しい設計のアイデアを知ることができる
- ライブラリを自分で作る時にはデザインパターンを使用する可能性が高い
想定読者
- デザインパターンに興味があるが、ネット上で「実際役に立たない」的な意見を見て、勉強しようか悩んでる人
記事の背景
僕は新卒でエンジニアとして2年間働いて現在育休をとっています。
育休中は手を動かす時間が取れないので、具体的な技術よりも抽象的な技術を勉強したいと思い、空き時間に設計に関する知識をつけることにしました。
DDDとかクリーンアーキテクチャについて勉強した後に、「じゃあ小さい機能単位で書くようなコードはどう綺麗にすればいいんだろう?」と考えてデザインパターンを勉強することにしました。
デザインパターンが設計力向上に有効か分からなかった
しかしいざ、デザインパターンについて調べてみると、実際は役に立たないという意見がちらほらみられました。
- フレームワークでの開発が主流なのでデザインパターンを使うような場面は少ない
- デザインパターンは難しいので使うと逆に分かりにくくなる
というのが主な意見なようでした。
せっかく勉強するなら役に立つものを勉強したいと思っていたので同じように悩んでる人に向けて、実際勉強してみてどうだったのか解説します。
デザインパターンを習得するメリット
学習教材はこちらを使用して、Golangで実装しました。 実際に学習してみて感じたメリットをまとめます。
自力では発想しづらいアイデアを知れる
デザインパターンを学習することで、何をクラスにするか、何をinterfaceにして交換可能にしておくかといった新たな視点を得ることができました。そしてそれらは自力で思いつくのは難しかったと思っています。
例えば、以下のような考え方です。
- Composite Patternではファイル(もの)とディレクトリ(いれもの)を同一視する
- State Patternでは具体的な"もの"ではなく、"状態"をクラスとして考える
教えられると理解するのは難しくないのですが、全くの0から自分でこのアイデアを考えつける気はしませんでした。
こういったアイデア一度頭の中に入れておけば、それらを適応できる場面に遭遇した場合に、完全な自力でひらめくことはできないけど、パターンを適用できるという絶大なメリットがあります。
自分でライブラリを作るときに役立つ
デザインパターンの有用性に反対する意見としてよく見られるのが
「フレームワークを使って開発するのが主流なのでそんなに複雑なプログラムは書かないからデザインパターンは役に立たない」
という意見です。
しかし逆を言えば自分でフレームワークやライブラリを作成するときはデザインパターンの考え方を知っておくべきだと思います。
フレームワークを作る機会はほとんどの人にとってあまりないと思いますが、小さいライブラリを業務で書く可能性は高いと思うので、デザインパターンを知っておくことは重要だと感じました。
GoFのデザインパターンが役立ちそうにないと感じたポイント
理解が困難で複雑なパターンは現場で使えなさそう
GoFのデザインパターンの中には複雑なパターンがあり、それを現場で使うのは控えたほうが良さそうと思いました。
解説本を読みながらでも理解が難しいと感じたパターンがいくつかあったので、デザインパターンを知らない人がいきなり業務中にそれを見たら、かなり混乱します。
Template Method PatternとかBuilder Patternは初見でも分かると思いましたが、Abstract FactoryやVisitorみたいな難しいパターンを実際に使うのは、かなり慎重になったほうがいいと感じました。
デザインパターンを学習してみてのまとめ
こんな人におすすめ
- 長期的に設計力を向上させたい人
- すぐに使える!という感じではないため
- 自力で閃くことが難しいアイデアを知ることができる
- ライブラリを自分で作る可能性が高い人
- 抽象的なロジックを書く必要性がありデザインパターンが役に立つ可能性が高いから
学習に使った教材
- 増補改訂版 Java言語で学ぶデザインパターン入門
- https://github.com/monochromegane/go_design_pattern
- Golangでの実装例が載っていてとても助かりました