Are Design Patterns Dead?
kawasima

Are Design patterns dead?

What are Design patterns
例：横断歩道
歩行路が道路を横断する地点では、たとえ歩行者に法的優先権があろうとも、車には歩行者を脅迫
し、服従させる力がある。これは歩行路と道路が同一平面上にあるとつねに生じる問題である。（中
略）横断者が道路を快適で安全と感じるのは、横断歩道が障害物になり、車がスピードを落とし、歩
行者に道を譲ることを物理的に保証される場合のみである。（中略）横断歩行路を道路より15-30cm
高くし、道路がそこに向かって盛り上がるようにすればよい。勾配が1/6以下であれば車には安全だ
し、しかも確実に車はスピードダウンする。遠方から横断を見やすくし、またそこでの歩行者の権利
に重み付けをする意味でも、道路際に縁を設けて歩行路を明示することもできよう。（中略）問題の
道路に、１日数回、異なった時間に出かけてみること。その度に、何秒待てば横断できるか測るこ
と。待ち時間の平均が２秒以上であれば、このパターンを適用する方がよい。（後略）
http://www.s-lagoon.co.jp/pattern_use_nf.html

Pattern Structure
・問題：横断歩道を造るとき、歩行者に安心感を与え、安全を守らねばならない
・フォース：２秒以上待たないと横断できないような道路
・解決策：横断歩行路を道路より15-30cm高くし、勾配を付けて車の走行に配慮
する
フォースとは…
解決しなければならない問題に対して、選択すべき解決策を
限定させるような、特定の状況の制約

Pattern Structure
問題
解決策
解決策
フォース
フォース
解決策
フォース
繰り返し見られる
(問題, フォース, 解決策)の
ペア

フォースが変わると解決策も変わる

Singleton
問題: あるデータが1つだけであることを保証したい
フォース: 生成のタイミングは利用するアプリケーション側でコント
ロールしたいが、そこで生成されるデータ自体を書き換えることはでき
ない。
解決策: Javaだとダブルチェックロッキング

※Notion AIに書いてもらいました

DIコンテナになると、自前で実装する必要が無くなった
依然として解きたい問題はそこにありフォースも変わらないので
多くの人はSingletonパターンとして認識する

問題: あるデータが1つだけであることを保証したい
フォース: 生成のタイミングは別にアプリケーションがコントロールする必
要はない
大元のフォースが変わると異なるパターンになる
解決策: グローバル変数として作っておけば良い
○ Node.jsならexport const singleton = new Singleton()
○ JavaならClass初期化時にINSTANCE生成
この場合、ただの「グローバル変数パターン」?

クラス継承前提のパターンはOOじゃなければ変容する

Template Method
問題: アルゴリズムの構造を変更することなく、アルゴリズムの特定のス
テップを再定義したい
フォース: サブクラス毎に再定義したいステップを実装する

※Notion AIに書いてもらいました

※Notion AIに書いてもらいました (関数合成はしてないですね)
Template Methodの「問題」は以前と
して存在していて、フォースが「サ
ブクラス」から「部分適用と関数合
成」に変わる
フォースが大きく変わるとパターン
名くらいは変えていいかも…

言語の発展とともに不要になった
➡ 不正確
Web開発では元々「問題」として現れにくいものもあった
➡ Flyweight, Interpretor
言語(フレームワーク)の発展とともに自分で解決策を実装しなくても良くなっただけ
➡「生成」のパターン全般
GoFはオブジェクト指向前提なので、解決策が変わるだけ
継承によるポリモーフィズム → パターンマッチによるポリモーフィズム
➡ Object Scopeのパターン (are still alive!!)
フォースまで変わると、別パターン(元のパターンは死んだと言っていいかも)
➡ Template Method
まとめ