GoFのデザインパターンをなぜ見かけなくなったのか

現在、筆者はTypeScriptでプログラムを書いているが、昔はJavaで書いていた。
Javaはオブジェクト指向のプログラム言語で、20年前などはデザインパターンが流行っていた時期もあった。デザインパターンとは、典型的な設計手法を集めたものである。よくGoFのデザインパターンなどと呼ばれている。

しかし、普段意識して使うのは、せいぜい4つか5つで他は殆ど使わず、時間が経つにつれて他のパターンは忘れていってしまった。

Javaのみを使っていた頃は、Javaのフレームワークがかなりデザインパターンを意識して作られていたので、その存在は常々意識していたが、TypeScriptになってからはあまり意識しなくなった。
TypeScriptはJavaScriptにかなり柔軟で厳密な型の概念を付け加えた言語であり、使うときはJavaScriptに変換して使う。TypeScriptはクラスやインターフェース、継承などJavaのオブジェクト指向的な要素も取り入れられているため、GoFのデザインパターンを適用する事も可能である。
実行時はJavaScriptとして動作し、ライブラリによってはJavaScriptのみの文法で作られるものもあるため、JavaScriptでは必ずしもGoFのデザインパターンを使用して実装される事はない。

また、JavaScriptが関数を変数として扱える第一級関数言語である事もGoFのデザインパターンを使わなくなる理由の一つであるように思う。機能を変化させるために部分的に処理を変えたいとき、必要に応じて関数をパラメータとして渡せるのは便利である。
またUIにおいてReactのような宣言的UIがメインになってきた事も大きな原因のようには思う。Electron、React NativeなどでもReactが使われ、命令的UIも減り、GoFのデザインパターンが出てくる要素が少なくなったのも大きいように思う。

そこで久しぶりに結城浩さんの「Java言語で学ぶデザインパターン入門」を読み返し、自分だったらどう実装するだろうかと言う観点で考えてみた。
そこで思ったのは、TypeScriptになりかつ関数をパラメータとして渡せるようになって、これらを使用することで使わなくなるGoFのパターンは23のうち4か5パターンに過ぎなかった。やはり大半のデザインパターンは、普段それを使うには単純過ぎる課題しか無いためのようである。

結論としては、GoFのデザインパターンは綺麗にまとまっていて勉強にはなるが、複雑すぎて普段は使わないというのが実態のようである。
(一昔前に出た結論ではあるが。)

つまりプログラムの実装において一番重要なのは、文法の深い理解と、常に応用を意識して実装することだといえる。
これらが浸透した結果と言語の機能が増えたことにより、GoFのデザインパターンを見かけなくなったのだと思う。