GoFのデザインパターン
この本を読んだ
よく分からなかった
覚えなきゃ！と思ってはいた
たまにデザインパターンが使えるケースを思い出したときは、喜んで採用していたと思う
このチートシートはわかりやすくてよい
このアドベントカレンダーがとてもいい ちょうぜつ Advent Calendar 2019
パターンは、図解があってこそ
良いポエムだった
確かに、既存コードを読んでパターンと一致すると目的が分かる
ただ、パターンのための実装をしている時をよく見かけ、「無駄にBuilderパターン使ってるところ全部消したい」とか感じることもあった
#パタン・ランゲージ―環境設計の手引 を読むと、実装するためのカタログというわけではないことが分かる
GoFのデザインパターンは、当時のコンテキストで生まれた古典であり、もっと時を経て洗練されていくべきもの
なのに経典として放置されていて、それがまだ正しいものだと新規学習者が出てしまっているのが良くない
Game Programming Patternsはゲーム開発の文脈で改良を加えたパターンを発表した良い例だと思う
再考: GoF デザインパターン より引用
厳しい批判だが、納得いく点が多い
> グローバルの免罪符として使われている現状をどうにかしないといけない。
> 「状態を持たず多態性を利用したい」という状況でのみ使うべきである。
> 多態性を利用しないのであれば、staticを利用したほうが単純性が増す。
現実の開発でかなり苦しめられるパターン
確かにその場では便利なんだけど、後からどんどん首を絞めてくる
使い方がただのグローバル変数と勘違いしているから
>ドメイン駆動設計の第二部はパタン・ランゲージであることが意図されているが、ぼくはここに違和感を感じている。エヴァンスは要素に分解しすぎている。かれの実践的な方法論はほとんど「部分を合計すると全体になる」ような要素還元主義になってしまっている。この発想自体がツリー的で、エンティティも値オブジェクトもサービスもこれらを組み合わせるとパターンが現れるかというとそんなことにはならない。この組み合わせの方こそパターンなのである。この組み合わせの可能性としてのパターンは脳内にあるものだ。ドメイン駆動設計、とくに軽量DDDと呼ばれる実践は、思考パターンというメタ領域に対してあまりに無自覚である。この無自覚は、実際にツリー状のコンポーネント群を生み出すという結果になるだろう。アレグザンダー以前のデザインに戻るわけである。
DDD(Domain-Driven Design)も興味対象の分野であるので、上記の引用文について気をつける
割と #クリストファー・アレグザンダー の本を色々読んでいるので、そろそろ批判的な目でも見ないといけないなと感じた
最初は素直に読んで、再読する時に批判的な目で読む