「design-patterns」タグのついた17記事

TypeScript は構造的部分型なので、形が合っていれば明示的な implements なしにそのまま渡せます。それでも変換役を挟む必要が残るのはどこからかを見ます。

任意引数の多いオブジェクトはリテラルで組み立てられます。一方で「この値を入れるまで build できない」という順序の制約は、TypeScript の型で表現できます。

要求を順に手渡していく構造は、Node.js のミドルウェアとして広く使われています。型で文脈を積み上げる書き方まで踏み込みます。

木構造を扱うとき、共通インターフェースを継承したクラス階層の代わりに、再帰的な判別可能ユニオンで表せます。ファイルシステムを題材にします。

同じ名前でも、GoF の Decorator パターンと TypeScript の Decorators 構文は別の概念です。両者を区別したうえで、高階関数による合成と比較します。

生成ロジックの切り出しは、TypeScript では多くの場合ただの関数とリテラル型のユニオンで足ります。関連する複数の生成物をまとめる制約があるときだけ Abstract Factory が意味を持ちます。

反復の抽象化は Symbol.iterator とジェネレーターとして言語仕様に入っています。自前の Iterator クラスを書く理由が残っているかを確かめます。

通知の仕組みを自作する前に、EventTarget と AbortSignal という標準の道具があります。購読の解除まで含めて、どこまで標準で足りるかを見ます。

JavaScript には Proxy という組み込みオブジェクトがあり、GoF の Proxy パターンとは別物です。遅延読み込みとアクセス記録を題材に、両方を扱います。

Repository は GoF ではなく PoEAA に由来します。本章は既存記事と重ならないよう、TypeScript の型でこの境界をどう表現するかに絞ります。

ES モジュールは同じ URL に解決されるかぎり 1 度しか評価されないため、Singleton クラスを書かなくても単一インスタンスが手に入ります。その保証が届く範囲と、それでも別の手段が要る条件を整理します。

状態ごとのクラスを作る代わりに、判別可能ユニオンで状態を表すと、その状態で呼べない操作を型で禁止できます。自動販売機を題材にします。

振る舞いを差し替えるだけなら関数を渡せば済みます。それでもオブジェクトとして束ねたくなるのは、戦略が複数のメソッドや状態を持つときです。

処理の骨組みを固定して一部だけ差し替える手段は、抽象クラスの継承だけではありません。フック関数を受け取る形との違いを整理します。

GoF の 23 パターンを現代の TypeScript で読み直す全 16 章のガイド。パターンごとに言語機能で代替できるかを判定し、クラスとして書き続ける価値が残る条件を並べて示します。

判別可能ユニオンと never を使った網羅チェックがあると、Visitor のクラス階層を組まなくても「処理し忘れ」を型で防げます。構文木を題材にします。

独立した章を設けなかった 8 つのパターンを短く扱い、連載全体の判定を 1 枚の表にまとめます。パターンを使うかどうかを決めるときの手順も整理します。