GoFのデザインパターン

この本を読んだ

https://gyazo.com/e936b2bbbf50ef9d8b804bf6282c0e25

よく分からなかった

覚えなきゃ！と思ってはいた

たまにデザインパターンが使えるケースを思い出したときは、喜んで採用していたと思う

このチートシートはわかりやすくてよい

パターンは、図解があってこそ

良いポエムだった

確かに、既存コードを読んでパターンと一致すると目的が分かる

ただ、パターンのための実装をしている時をよく見かけ、「無駄にBuilderパターン使ってるところ全部消したい」とか感じることもあった

GoFのデザインパターンは、当時のコンテキストで生まれた古典であり、もっと時を経て洗練されていくべきもの

なのに経典として放置されていて、それがまだ正しいものだと新規学習者が出てしまっているのが良くない

厳しい批判だが、納得いく点が多い

グローバルの免罪符として使われている現状をどうにかしないといけない。

「状態を持たず多態性を利用したい」という状況でのみ使うべきである。

多態性を利用しないのであれば、staticを利用したほうが単純性が増す。

現実の開発でかなり苦しめられるパターン

確かにその場では便利なんだけど、後からどんどん首を絞めてくる

使い方がただのグローバル変数と勘違いしているから

ドメイン駆動設計の第二部はパタン・ランゲージであることが意図されているが、ぼくはここに違和感を感じている。エヴァンスは要素に分解しすぎている。かれの実践的な方法論はほとんど「部分を合計すると全体になる」ような要素還元主義になってしまっている。この発想自体がツリー的で、エンティティも値オブジェクトもサービスもこれらを組み合わせるとパターンが現れるかというとそんなことにはならない。この組み合わせの方こそパターンなのである。この組み合わせの可能性としてのパターンは脳内にあるものだ。ドメイン駆動設計、とくに軽量DDDと呼ばれる実践は、思考パターンというメタ領域に対してあまりに無自覚である。この無自覚は、実際にツリー状のコンポーネント群を生み出すという結果になるだろう。アレグザンダー以前のデザインに戻るわけである。

最初は素直に読んで、再読する時に批判的な目で読む