「Java言語で学ぶデザインパターン入門」を読んだ

目的

• 自身のコードレビューをより良くしたかった。今はバグが発生しないか?やtypoやコード規約レベルの内容ばかり指摘していて、長期的に良いプロダクトを作るのにつながるような議論ができていないように感じる
• アーキテクチャに関する議論をしているときに、前提知識として必要になっているなと感じるシチュエーションが度々発生していた。ある意味エンジニア間の共通言語として必要不可欠な知識となっている気がする

全体を通して

• 個別のパターンについて細かく覚えられてはいないが、よく聞くパターンや用語について理解することができた(Observerパターンなど)。
• なぜそれが必要なのか、どういうときに役立つのかを あなたの考えを広げるためのヒント で解説してあるため、サンプルプログラムと自身の過去の経験と照らし合わせて想像できた
• 昔、サンプルプログラムとUMLの理解を意識しすぎて挫折していたた、後半の解説を腑に落ちるように自分で咀嚼するのを繰り返したら、楽に読み進められた。次読むときはきちんと練習問題もやるつもり(今回は挫折する前に読み切ることを第一に考えたので飛ばした)

メモ

Adapter

• すでにある機能をに変更を加えたい時、直接変更を加えるのではなくラッパークラスを作って振る舞いを変更するようにすると、テストすべき影響範囲が減る。もちろん、処理速度やわかりやすさ等でデメリットが発生する場合もあるが、急いでいるとき等の選択肢の一つとして持っておきたい

Builder

• 昔よくわからなかったものの一つ。最近必要性がわかるようになってきた
• インスタンス生成に複雑なステップを踏むクラスがあり、それがいろいろなところから使用されている場合は検討すべき。利用側が知る必要がない項目を隠蔽でき、修正が必要になった場合も影響範囲を少なくすることができる

Strategy

• 処理ロジックを差し替えたい時等に使える
• 昔やった案件の、〇〇会社のときと✗✗会社のときで金額計算ロジックが違う、みたいなシチュエーションで役立ちそうな考え方

Decorator

• 弊社のRailsで採用しているレイヤ
• データ本体を、View用に装飾するために利用する。データの中身と共通IFにすることで同一視できる(透過的インターフェース)

Facade

• 複雑なものをシンプルに扱えるようにする窓口
• 青い銀行のシステムの中に出てきていた気がする。当時はそういう固有名詞としか教えられなかったので全然理解できなかったが、デザインパターンの一つだったならそう言ってもらえればよかったのに。。。
• 複数の複雑な機能を無理に共通IFに揃えるのではなく、ファサードの役割のクラスが最小限のpublicメソッドを公開して適切に利用できるようにしておけば解決しそうな部分がありそう

Mediator

• なんとなくFacadeとカブる部分がある。おそらくまだ理解が足りない
• FacadeはIF、Mediatorは内部の処理ロジックの抽象化・カプセル化を扱っているという理解

Observer

• よく聞くやつ。Pub-Subモデルとか
• Observeに通知して、購読者がそれをまつ

State

• Kotlinの seald class は状態を表す用途に最適であるとあらためて感じた

増補改訂版Java言語で学ぶデザインパターン入門