令和にGoFデザインパターン
プログラミングの設計で勉強会をやろうと思って、ネタを集めています。とっかかりで便利なんですよね、いわゆる「デザパタ」。はい、いちいち書きませんけど、GoFデザインパターンのことだと読み替えてくださいね。「エンジニア」はこの記事内では、ソフトウェアエンジニアのことを指しますよ！（皮肉です。この中で「エンジニア」は二度と出てきません）。
以前にも少し触れた覚えがありますが、いまさら感はあります、デザパタ。最近だとプログラミング言語の機能でもっとスマートに解決できることも多いですし。それでも今回デザパタを題材にしようとしているのは、「パタンランゲージ」だという一点です。言語化されているものは、やはり強い。注釈を入れながら説明すれば、最初の一歩としては充分に役割と果たせることかと思います。
というわけで、「実践Python3」を入手しました。
実は以前から本の内容にも目を通していましたが入手は見送ったことがあって、その理由はむしろ「デザインパターンが説明されているから」でした。いまさらデザパタでもないなーと正直判断してしまっていたのです。今回は教育的観点から再度見直しをして、実際の中身はきちんと、「Pythonの目から見たデザパタ」になっていることに気づきました。すまんな、早とちりして。
この書籍では、23のパターンを
の3つに分けています。巷でも言われてきた通り、この分類方法も議論があるでしょうが、オーソドックスな方法なのでまあいいかという感じ。
改めて眺めてみると、この中で私がよく使うのは「構造に関するデザインパターン」ですかね。基本的に特定のパターンを採用する理由は2つあると個人的には思っていて、以下の2つです。
- 特定の構造を拡張しやすくする
- 特定の構造に実装を制限する
で、この分類でいうと主にパターンを使いたい場合は1です。大抵の場合、設計に乏しいソースコードって、やりたいことをそのまま逐次的に一箇所に無整理に並べていることが多くて、そういう人は2を使って実装を制限しなくてもそういう方法でしか実装しないし、下手に構造を変更するとむしろ怒り出したりします。なのでだいたい拡張したい部分に「穴を開ける」ためにこういった設計技術を使うことが多いのです。具体的には、自分で作るとしたらAdapter/Bridge/Facade/Command/Strategy/Stateパターンを使うことが多いかな…そこまで意識的にやっていない場合がほとんどですけど。
Pythonで言うと、（厳密にDecoratorパターンと同一ではないにせよ）デコレータやイテレータは言語機能として存在しますね。それからJavaScriptなどの言語でよく使われる、イベントハンドラという概念の基礎にはObserverが横たわっていますし、イベントバブリングはChain of Responsiblityですよね。これらはもはや市民権を得たパターンでしょうか。一方でPrototypeとかはせっかく継承ベースでないオブエジェクト指向と言われていたのに、もはや隠蔽されようとしていますね。別に好きではありませんが、バリエーションが減るのは少しだけ寂しいような気もします。
