
## 概要

半年前とかに読んだ[Java言語で学ぶデザインパターン入門第3版](https://www.hyuki.com/dp/) 感想まとめ

サンプルコードは書き慣れたTSで記述している(Javaは書き慣れていないので)

参考: [https://github.com/torokmark/design_patterns_in_typescript](https://github.com/torokmark/design_patterns_in_typescript)

## Adapterパターン

クラスのインターフェイスを、クライアントが期待する別のインターフェイスへ変換を実現するパターン

互換性のないインターフェースのためにできなかったクラス同士の連携が可能になる

## Singletonパターン

インスタンスが1つしか存在しないことを保証するパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/tree/main/singleton](https://github.com/torokmark/design_patterns_in_typescript/tree/main/singleton)

#### Singletonパターンの定義

- コンストラクタは外部に公開しない
  - `new Singleton`が外部から不可能になる
- インタンス取得用のメソッドのみ外部公開する
  - 内部実装的にはFactory Methodのようになっている
  - インスタンスがすでに作成済み確認する

```typescript
namespace SingletonPattern {
  export class Singleton {
    private static singleton: Singleton;
    private constructor() {}
    public static getInstance(): Singleton {
      if (!Singleton.singleton) {
        Singleton.singleton = new Singleton();
      }
      return Singleton.singleton;
    }
  }
}
```

#### 呼び出し

```typescript
namespace SingletonPattern {
  export namespace Demo {
    export function show(): void {
      const singleton1 = SingletonPattern.Singleton.getInstance();
      const singleton2 = SingletonPattern.Singleton.getInstance();
      if (singleton1 === singleton2) {
        console.log('two singletons are equivalent');
      } else {
        console.log('two singletons are not equivalent');
      }
    }
  }
}
```

## Prototypeパターン

新しいインスタンスを作る際にクラスではなく既存のインスタンスから複製するパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/tree/main/prototype](https://github.com/torokmark/design_patterns_in_typescript/tree/main/prototype)

#### Prototypeパターンの定義

- 複製対象クラスは自身を複製できるcloneメソッドをインターフェースとして持っている
- Builderクラスに複製対象クラスを表す文字列(ex. c1)を渡すと透過的に複製できる

```typescript
namespace PrototypePattern {
  export interface Prototype {
    clone(): Prototype;
    toString(): string;
  }

  export class Concrete1 implements Prototype {
    clone(): Prototype {
      return new Concrete1();
    }

    toString(): string {
      return 'This is Concrete1';
    }
  }

  export class Concrete2 implements Prototype {
    clone(): Prototype {
      return new Concrete2();
    }

    toString(): string {
      return 'This is Concrete2';
    }
  }

  export class Builder {
    private prototypeMap: { [s: string]: Prototype } = {};

    constructor() {
      this.prototypeMap['c1'] = new Concrete1();
      this.prototypeMap['c2'] = new Concrete2();
    }
    createOne(s: string): Prototype {
      console.log(s);
      return this.prototypeMap[s].clone();
    }
  }
}
```

### 呼び出し

```typescript
namespace PrototypePattern {
  export namespace Demo {
    export function show(): void {
      var builder: PrototypePattern.Builder = new PrototypePattern.Builder();
      var i = 0;
      for (i = 1; i <= 2; i += 1) {
        console.log(builder.createOne('c' + i).toString());
      }
    }
  }
}
```

### 所感

このコードでは複製時に`new`キーワード使っているので、生成コストは同じだと思った。

要件次第ではディープコピーを採用することになるので、そこのロジックは考えないといけないと思う。

また、生成時に複数のパラメータが必要な場合、生成コストはそこまで変わらないし、むしろ上がるのではと思う。

ただ、APIレスポンスをパラメータとしている場合は、複製する方がコスト低い(APIリクエストが発生しない)ので複製した方が良さそう。

## Abstract Factoryパターン

関連したオブジェクトの集まりを具象クラスを指定することなく生成できるようにしたパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/tree/main/abstract_factory](https://github.com/torokmark/design_patterns_in_typescript/tree/main/abstract_factory)

### Abstract Factoryパターンの定義

基本的に`Abstract.*`はインターフェースとして定義されており、メンバの集合体となっている

`Concreate.*`_は_`Abstract.*`のインターフェースの中身を定義している

`Abstract.*`では最終的に生成するオブジェクトの形式だけを決めておいて*、*`Concreate.*`でオブジェクトの実際の中身を返している

```typescript
namespace AbstractFactoryPattern {
  export interface AbstractProductA {
    methodA(): string;
  }
  export interface AbstractProductB {
    methodB(): number;
  }

  export interface AbstractFactory {
    createProductA(param?: any): AbstractProductA;
    createProductB(): AbstractProductB;
  }

  export class ProductA1 implements AbstractProductA {
    methodA = () => {
      return 'This is methodA of ProductA1';
    };
  }
  export class ProductB1 implements AbstractProductB {
    methodB = () => {
      return 1;
    };
  }

  export class ProductA2 implements AbstractProductA {
    methodA = () => {
      return 'This is methodA of ProductA2';
    };
  }
  export class ProductB2 implements AbstractProductB {
    methodB = () => {
      return 2;
    };
  }

  export class ConcreteFactory1 implements AbstractFactory {
    createProductA(param?: any): AbstractProductA {
      return new ProductA1();
    }

    createProductB(param?: any): AbstractProductB {
      return new ProductB1();
    }
  }
  export class ConcreteFactory2 implements AbstractFactory {
    createProductA(param?: any): AbstractProductA {
      return new ProductA2();
    }

    createProductB(param?: any): AbstractProductB {
      return new ProductB2();
    }
  }

  export class Tester {
    private abstractProductA: AbstractProductA;
    private abstractProductB: AbstractProductB;

    constructor(factory: AbstractFactory) {
      this.abstractProductA = factory.createProductA();
      this.abstractProductB = factory.createProductB();
    }
    public test(): void {
      console.log(this.abstractProductA.methodA());
      console.log(this.abstractProductB.methodB());
    }
  }
}
```

#### 呼び出し

- `ConcreteFactory1`や`ConcreteFactory2`はどちらも`AbstractFactory`型なので、結局どのFactoryなのかクライアント側で気にする必要はない
- 気にする必要があるのは、生成されたオブジェクトが`test`メソッドを持つということだけ
- 生成ロジックは隠蔽されている

```typescript
namespace AbstractFactoryPattern {
  export namespace Demo {
    export function show() {
      // Abstract factory1
      var factory1: AbstractFactoryPattern.AbstractFactory =
        new AbstractFactoryPattern.ConcreteFactory1();
      var tester1: AbstractFactoryPattern.Tester =
        new AbstractFactoryPattern.Tester(factory1);
      tester1.test();

      // Abstract factory2
      var factory2: AbstractFactoryPattern.AbstractFactory =
        new AbstractFactoryPattern.ConcreteFactory2();
      var tester2: AbstractFactoryPattern.Tester =
        new AbstractFactoryPattern.Tester(factory2);
      tester2.test();
    }
  }
}
```

### 所感

単一責任の原則に従っているし、クライアントと生成ロジックが密結合しないのはメリットだと感じた

ただ、関連するオブジェクトの集まりが少ない場合は、普通に`Factory Method`パターンで良いと思った

似たUIが複数生成する必要がある場合は、このパターンを採用しても良さそう

仮にこのパターンを採用する場合、コードが複雑になるのは避けられないので、トレードオフを丁寧に評価する必要がある

## Bridgeパターン

抽象部分と実装部分を切り離し、両者を独立して変更できるようにしたパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/blob/main/bridge/bridge.ts](https://github.com/torokmark/design_patterns_in_typescript/blob/main/bridge/bridge.ts)

### Bridgeパターンの定義

![image of bridge pattern](https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/44f2a99ed7a84cd0b44c1a37ccf0d420/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-05-21%209.47.35.png?w=1000&h=348)

- `Abstraction`は実装から独立した操作を定義したクラス
  - `Implementator`への参照を保持し、メソッドを定義
- `RefinedAbstraction.*`は`Abstraction`クラスの具体的なサブクラス
  - `Abstraction`クラスで定義したメソッドの具体的な動作を定義
- `Implementor`は抽象化から独立した操作を定義したクラス
- `ConcreteImplementor.*`は`Implementor`クラスの具体的なサブクラス
  - `Implementor`クラスで定義したメソッドの具体的な動作を定義

```typescript
namespace BridgePattern {
  export class Abstraction {
    implementor: Implementor;
    constructor(imp: Implementor) {
      this.implementor = imp;
    }
    public callIt(s: String): void {
      throw new Error('This method is abstract!');
    }
  }

  // ... 以下のコードは省略 ...
}
```

### 呼び出し

```typescript
namespace BridgePattern {
  export namespace Demo {
    export function show(): void {
      var abstractionA: BridgePattern.Abstraction =
        new BridgePattern.RefinedAbstractionA(
          new BridgePattern.ConcreteImplementorA(),
        );
      var abstractionB: BridgePattern.Abstraction =
        new BridgePattern.RefinedAbstractionB(
          new BridgePattern.ConcreteImplementorB(),
        );

      abstractionA.callIt('abstractionA');
      abstractionB.callIt('abstractionB');
    }
  }
}
```

### 所感

ここまでやるかは別として、抽象と実装を切り分けることで、コアロジックと詳細なロジックを分離できる点はメリットだと思う
それにより変更容易性がある程度担保されている
デザインパターンは単一責任の原則が色濃く出ているなと思う

## Strategyパターン

同じインターフェースだが振る舞い(アルゴリズム)をユースケースごとに分離して実行できるようにしたパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/tree/main/strategy](https://github.com/torokmark/design_patterns_in_typescript/tree/main/strategy)

### Strategyパターンの定義

- それぞれの振る舞い(アルゴリズム)を`Strategy.*`クラスに分離する
- `Strategy.*`クラスは`Strategy`インターフェースを持つ
- `Context`クラスは渡された`Strategy.*`クラスを呼び出す

```typescript
namespace StrategyPattern {
  export interface Strategy {
    execute(): void;
  }

  export class ConcreteStrategy1 implements Strategy {
    public execute(): void {
      console.log('`execute` method of ConcreteStrategy1 is being called');
    }
  }

  export class ConcreteStrategy2 implements Strategy {
    public execute(): void {
      console.log('`execute` method of ConcreteStrategy2 is being called');
    }
  }

  export class ConcreteStrategy3 implements Strategy {
    public execute(): void {
      console.log('`execute` method of ConcreteStrategy3 is being called');
    }
  }

  export class Context {
    private strategy: Strategy;

    constructor(strategy: Strategy) {
      this.strategy = strategy;
    }
    public executeStrategy(): void {
      this.strategy.execute();
    }
  }
}
```

### 呼び出し

```typescript
namespace StrategyPattern {
  export namespace Demo {
    export function show(): void {
      var context: StrategyPattern.Context = new StrategyPattern.Context(
        new StrategyPattern.ConcreteStrategy1(),
      );

      context.executeStrategy();

      context = new StrategyPattern.Context(
        new StrategyPattern.ConcreteStrategy2(),
      );
      context.executeStrategy();

      context = new StrategyPattern.Context(
        new StrategyPattern.ConcreteStrategy3(),
      );
      context.executeStrategy();
    }
  }
}
```

### 所感

個人的にはかなり現実的なパターンだと考えている。

生成ロジックの分離に重きを置いたPrototypeやFactory、Bridgeパターンより、Strategyパターンのような振る舞いを分離する方がコスパよく変更の影響範囲を最小化できそうな気がしている。

最初からPrototypeやFactoryパターンなどを実装しているプロジェクトは少ないと思っていて、そうなるとStrategyパターンで振る舞いを分離して置いた上で他のデザインパターンを適用していくという考え方もあるのでは。

## まとめ

デザインパターンを愚直に適用するのは良くないけれど、考え方自体を知っておくのはとても有用だと思う。

残りのデザインパターンは別記事にまとめる。

- Compositeパターン
- Visitorパターン
- Facadeパターン
- Mediatorパターン
- Proxyパターン
- Commandパターン
- Interpreterパターン


<書評> Java言語で学ぶデザインパターン入門第3版 第1弾


## 概要

本書籍では、オブジェクト指向や設計パターンなどソフトウェア設計に関する基本的な概念が紹介されている。

章ごとに読んだ感想を述べていく。

## CHAPTER1: 小さくまとめてわかりやすくする

ソフトウェアは常に変更され得るから、変更しやすいコードを書くには何を意識すべきかがまとめられている。

分かりやすさに主眼が置かれており、変数名を明確にしたり、値オブジェクトを使うことやイミュータブルなデータに関して言及されている。

「クラス名やメソッド名と業務の用語を一致させること」これはかなり大事。異音同義語があると認識のズレとか生まれやすいし、話していてツラミ感じる。

## CHAPTER2: 場合分けのロジックを整理する

ソフトウェア変更容易性を妨げるのが複雑なロジックなので、簡単に書こうという内容や方法がまとめられている。

メソッドに切り出すとか、ifのネスト、ガード節による早期returnなど。

switch文などで分けるより、クラス化しロジックをカプセル化して呼び出すだけにすると見通しが良くなるなど。

使う側のクラスが使われる先のクラスに関する知識が少ないほど疎結合になって良い。

Railsで開発しているとどうしても密結合になりがちなので、改めて意識したいと思った。

## CHAPTER3: 業務ロジックをわかりやすく整理する

1,2章が部品レベルの話だったが、この章ではアプリケーション全体の組み立てレベルでのロジックの分かりやすさについてまとめている。

ドメインオブジェクトをクラスとして管理していく際に下記のことに気をつける。

- メソッドをロジックの置き場所にする
  - getter / setterメソッドだけになっていないか？（=ドメインモデル貧血症）
- ロジックを、データを持つクラスに移動する
  - ロジックが点在していないか？共通化できないか？
- 使う側のクラスにロジックを書き始めたら設計を見直す
- メソッドを短くして、ロジックの移動をやりやすくする
- メソッドでは必ずインスタンス変数を使う
  - Railsの文脈だとクラス内のカラム等
  - 受け取った引数だけ使っているのであればそのクラスに定義する意味がない
- クラスが肥大化したら小さく分ける
- パッケージを使ってクラスを管理する

上記を組み立てる段階で、プレゼンテーション層にドメインロジックが書かれていないか？

アプリケーション層との結合はどうか？等の責務を意識していく。

基本的にドメインオブジェクトにロジックをまとめることで凝集性を高める方が好ましい。

## CHAPTER4: ドメインモデルの考え方で設計する

ドメインの関心事を適切にモデルに落とし込んで独立した単位として扱えるようにする重要性についてまとめられている。

ドメイン内のユビキタス言語を定めてクラス名に落とし込むことや、「コト」を中心に考えることで関心事を特定しやすくなるなど。

特に学びだったのがドメインオブジェクトの基本設計パターンと業務の関心事パターン

### ドメインオブジェクトの基本設計パターン

- 値オブジェクト
  - 数値、日付、文字列などをラップしてロジック整理する
- コレクションオブジェクト
  - 配列やコレクションをラップしてロジック整理
- 区分オブジェクト
  - 区分の定義と区分ごとのロジックを整理
- 列挙型の集合操作
  - 状態遷移ルールなどを列挙型の集合として整理

この4種類で業務ロジックを整理していくと業務ロジックがドメインモデルに集約できる。

### 業務の関心事パターン

- 口座パターン
  - 現在の値を表現し妥当性を管理
    - 数値の増減や現在の値を保持
    - 銀行の口座や在庫数量の管理など時系列が重要なパターン
- 期日パターン
  - 約束の期日と判断を表現
    - 期日が適切に守れているかを管理
      - 期限切れの場合はどうするかなどの表現
- 方針パターン
  - 様々なルールが複合する複雑な業務ロジックを表現
- 状態パターン
  - 状態と、状態遷移できる/できないを表現
    - 決済ステータスなどで利用される
      - ある状態ではどうなるべきなのかを表現

上記4種類が主な関心事パターンとして挙げられるが、ドメイン理解をしていくことが適切に関心事を扱えるようになるポイント。

異音同義語に注意したい。あと、話を深掘り真の課題を抽出すること。

## CHAPTER5: アプリケーション機能を組み立てる

サービスクラスに業務ロジックを書かないようにする。

防御的プログラミングの形式で多くのガード節があると、ドメインモデルにロジックを移すかクラスを用意するなりした方が良い。

あくまでサービスクラスは処理を呼び出すだけ。尋ねるな命じろ。

## CHAPTER6: データベースの設計とドメインオブジェクト

データベース設計がうまくいくとアプリケーションロジックも書きやすくなる。

NOT NULL制約だったり、一意性制約、外部キー制約など。詳細はSQLアンチパターンなどの書籍に譲る。

というよりDB設計の細かい話より、ドメインの中でテーブル単位をどう切り分けるのかという話の方が重要。

「コトの記録」を徹底すると本書には書かれている。

実体があるものはモデリングしやすいが、実体の無いものこそ業務ロジックの中ではモデリングすることが大事。

texta.fmというラジオでも和田さんが同じことをおっしゃっていた。

## CHAPTER7: 画面とドメインオブジェクトの設計を連動させる

汎用画面は複数の関心事が混ざっておりロジックを複雑にしてしまう。

何事も関心事の分離が肝とあるが、ビジネスサイドからは1つの画面で全部行いたいという要望もあるので落とし所は難しいなと思う。

逆に言うと、1つの画面で共通の関心事をまとめられていないという側面もあるのかもしれない。

複数の関心事が混ざっていることだけでなく、同じ関心事が複数画面に点在していないかも意識できると良さそう。

## CHAPTER8: アプリケーション間の連携

APIの粒度を適切に保つことが再利用性や利用容易性を高める。

本書では大は小を兼ねるAPIはビジネスの発展を阻害するとあるが、まさにその通りだと思う。

ユースケース上では不要なパラメータや戻り値など、複雑にする要因があると連携がスムーズにいかない。

将来的な拡張性も難しくしてしまうと感じる。

関心事の不一致が起きていないかどうかはこういう場面でも意識したい。

## CHAPTER9: オブジェクト指向の開発プロセス

オブジェクト指向らしく分析と設計を一体にすることで、変更が楽で安全なソフトウェア開発を進められる。

業務ロジックをドメインモデルに集約して整理することが肝。

分析工程と設計工程を分割せずに一貫して行うことや、コードが自己文書化すべき等の記載がある。

兎にも角にもドメインを深く理解してモデリングすることが大事。

## CHAPTER10: オブジェクト指向設計の学び方と教え方

オブジェクト指向設計の考え方を習得するには、リファクタリングが手っ取り早い。

コードの重複や巨大なメソッド/クラス、引数が多すぎるメソッドなどをリファクタリングすることでなぜ使いやすくなるのかを肌で感じることが大事。

話は少し逸れるが、最近は脱オブジェクト指向が主流になりつつあるような気がするので別途ブログにまとめたい。

## まとめ

再利用性が高くDRYなコードを書くのはもちろん、ドメインを適切にモデリングすることを意識したい。


<書評> 現場で役立つシステム設計の原則


## 所感

ドメイン駆動設計に関して本格的に学ぼうと思って読んだ1冊
ドメインモデルをうまく表現することの利点や技法などをバラバラだった知識をまとめられた印象
ビジネスドメインを丁寧にモデリングして扱えるようにしたい

## Chapter2

### 「システムに最適な値が必ずしもプリミティブな値であるとは限らない」

ドメイン固有の値をどう扱うと良いのかにフォーカスすることが大事。

イミュータブルであることによりデータの信頼性が向上されるし、それにより交換可能になる。（逆に言うと交換以外で値を変更できない）

クラスとして実装していくことで値オブジェクト固有のバリデーションロジックも内包できるというのも扱いやすくなるポイントかなとも思う。

### 値オブジェクトとして扱う基準

また、値オブジェクトとして扱うべきかどうかの判断基準として「そこにルールが存在しているか」「それ単体で取り扱いたいか」という点を筆者が重視しているという点も印象に残った。

ドメイン内で特別視されている（ドメイン固有の呼び名が付いているなど）の場合は、値オブジェクトになり得るのかなと思った。

値オブジェクトに関しては下記のpodcastもとても参考になる。

[https://anchor.fm/textafm/episodes/2--The-Power-of-Constraints-ejufu0](https://anchor.fm/textafm/episodes/2--The-Power-of-Constraints-ejufu0)

## Chapter3

### 値の同一性

- エンティティは識別子(ID)で同一性を判断
- 値オブジェクトは値で同一性を判断
  - 別のオブジェクトだとしても値が同じであれば同一とみなす

### エンティティの判断基準

「ライフサイクルが存在し、そこに連続性が存在する」ことがエンティティかどうかの基準。

作成されて誕生し、削除されて死を迎える。つまりCRUD処理が発生し得る可変なオブジェクト。

値オブジェクトは不変であるため、エンティティではないということが分かる。

### ドメインオブジェクトを定義するメリット

印象に残ったのは「仕様書というのはマクロな要件については有効であってもミクロな要件については無力であることが多い」ということ。

その通りであるし、そこまで記述する必要がないからそうなっているはず。

だからこそ、コードからその要件を汲み取りやすくしておく必要があるなと再認識した。

クラスにドメインオブジェクトのルールを記述して凝集度は高く保つというのは、ドキュメンテーションという文脈においても重要。

## Chapter4

### サービスへのロジック切り出しはドメインモデル貧血症を引き起こす

ドメインモデルの振る舞いをサービスに切り出しすぎると、ドメインモデルがデータだけを保持している無口なオブジェクトになってしまう。

れによってドメインモデル自身が語るべきことを語っていない状態が出来上がってしまう。

データと振る舞いが点在してしまうことで可読性や保守性に欠けてしまう。

そうならないために、ドメインモデルに不自然な振る舞いのみサービスに切り出すことが重要。

複数のモデルを横断する操作を行う際など、ドメインモデル固有ではないロジックが出てきた場合は検討の余地あり。

## Chapter5

### ビジネスロジックをより純粋なものに昇華する

リポジトリパターンを利用して永続化処理を抽象化して隠蔽することで、ビジネスロジックを簡潔にできる。

自分の会社のフロントエンドアプリケーションはリポジトリパターンを利用しており既知の知識としてある。

だからこそ、今一度下記のようなアンチパターンを実装してしまわないように意識したい。

[https://qiita.com/mikesorae/items/ff8192fb9cf106262dbf](https://qiita.com/mikesorae/items/ff8192fb9cf106262)

## Chapter6

### アプリケーションサービスはオブジェクトの操作に徹する

ドメインロジックの責務外の振る舞いを記述することに徹する。

サービスオブジェクトはロジックが雑多になりがち（ドメインロジックが記述されてる / 責務が複数等）なので、今一度サービスクラスを作る際は注意したいと思う。

[Qiitaのリンク](https://qiita.com/joker1007/items/25de535cd8bb2857a685)

## Chapter7

### 依存を避けるよりコントロールせよ

抽象に依存することが重要。依存関係逆転の原則。

抽象に依存することで変更箇所が最小になる。

改めて思うのは良い設計は変更容易性が担保されていること。

## Chapter12

### オブジェクトの境界線が秩序をもたらす

デメテルの法則（最小知識の原則）を元にコード設計する。

Wikipediaによると、デメテルの法則の基本骨子は下記である。

> 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべき

[デメテルの法則 - Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%A1%E3%83%86%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87)

つまり、他のオブジェクトの情報（どういう状態/値であるのか等）を知らなくて良いということ。

「尋ねるな、命じろ」というソフトウェアの格言があるが、その通りに設計していけばルールが漏れ出すのを防げる。

変更が面倒な時は大体同じロジックが書かれているので、改めて意識してコードを書いていきたい。

[Qiita](https://qiita.com/TakeshiFukushima/items/0b16aef3d320a2ccb7c3#%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87%E3%81%8C%E5%AE%88%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E4%BE%8B)

## Chapter13

### 仕様オブジェクトがドメインルールの点在を防ぐ

#### 仕様オブジェクトについて

ドメインの重要なルールだが処理が複雑になってしまうロジックを格納するオブジェクト

目的としては、ロジックの点在を防ぐこと。

例えば、こういったロジックはサービス層で実装されがちだが、それだとドメインルールが点在してしまう。

そういった状況を防ぐために仕様オブジェクトでロジックをラップする。

#### リポジトリのフィルターとしても機能する

リポジトリに仕様オブジェクトを渡してメソッドを呼び出すようにすることで、ドメイン知識を記述せずに済むようになる。

```java
// 仕様オブジェクト
public class CircleRecommendSpecification {
  private readonly DateTime executeDateTime;

  public CircleRecommendSpecification(DateTime executeDateTime) {
    this.executeDateTime = executeDateTime;
  };

  public bool IsSatisfiedBy(Circle circle) {
    if(circle.CountMembers() < 10) {
      return false;
    }
    return circle.Created > executeDateTime.AddMonths(-1);
  };
}

// リポジトリ
public class CircleRepository: CircleRepository {
  private readonly ICircleRepository circleRepository;
  private readonly DateTime now;

  public CircleGetRecommendResult GetRecommend(CircleGetRecommendRequest request) {
    var circleRecommendSpecification = new CircleRecommendSpecification(now);
    // リポジトリに仕様を引き渡して抽出(フィルタリング)
    var recommendCircles = circleRepository.Find(circleRecommendSpecification).Take(10).ToList();
    return new CircleGetRecommendResult(recommendCircles);
  };
}
```

## Chapter14

### レイヤーの隔離と責務の分割

本書ではドメイン駆動設計がアーキテクチャに求めることは、ドメインオブジェクトが渦巻くレイヤーを隔離して、ソフトウェア特有の事情からドメインオブジェクトを防衛することと説明されている。

レイヤードアーキテクチャやクリーンアーキテクチャなどのアーキテクチャも依存の方向を定めて、レイヤーごとに責務を分割している。

ドメイン駆動設計の文脈上で最も重要なのはドメインの隔離を促すこと。

## Chapter15

### 軽量DDDに陥らないこと

デザインパターンなどを盲目的に利用してそれで終わらないこと。

重要なのはドメインの本質に向き合い続けること。

ユーザーを知り対話を続けドメインを改善していくことを意識したい。

## まとめ

依存の方向性 / 責務の分割 / ロジック隠蔽を意識したいと思った。

パターンはある程度分かったが、エリックエヴァンスの書籍を読んで根本的な思想の部分を知りたい。


<書評> ドメイン駆動設計入門: ボトムアップでわかる!ドメイン駆動設計の基本


## 概要

発売前から気になっていたこの書籍を読んだので学びをつらつらと書いていく。

自分が業務で担当しているアプリケーションもパフォーマンスがボトルネックとなることがあるので、少しでも何か吸収できれば。

## 1章: チューニングの基礎知識

本書ではリクエストレスポンス一連の動作が完了するまでの時間（RTT: Round Trip
Time）が短いWebサービスを高速なWebサービスと定義している。

Webサービスのキャパシティは単純化すると個々の性能×数になり、それを調整するアプローチは**垂直スケーリング（スケールアップ:
性能UP）**か**水平スケーリング(スケールアウト: 数増やす)**の2種類がある。

パフォーマンスチューニングの基本は下記2点

- ボトルネックだけにアプローチする
- ボトルネックの特定は外側から順番に
  - 2021年の一般的なWebサービスにおいてボトルネックになりがちな箇所はCPU、メモリ、ディスクI/O、ネットワークI/Oとのこと

負荷試験を実施して改善してのサイクルになる。負荷試験と言えるほどちゃんとしたものをやったことが無いな。

## 2章: モニタリング

モニタリングは外形監視と内部監視の2種類がある。

- 外部監視
  - アプリケーションの外側からモニタリングする手法。
  - 外部からリクエストを行って期待通りのレスポンスが返ってくるか確認。
- 内部監視
  - アプリケーション内部からモニタリングする手法。
  - CPU利用率やメモリなどの状態をウォッチ。

本書では[Prometheus](https://prometheus.io/)というPull側のモニタリングツールを使用している。

基本的には内部監視の方が多いんじゃないかなと考える。外部監視だとネットワークの状態に左右されるから再現性が低そう。

## 3章: 基礎的な負荷試験

各種指標をどう見るかが大事。
本書では下記の数値が紹介されており、MySQLのボトルネックになっている箇所を調査していく流れ。
（スロークエリの発見。実行計画を見ていく）

- CPU2コアのうち50%程度が利用されている
- MySQLのプロセス(mysqld) がCPUを100%(1コア)程度利用
- WebアプリケーションのプロセスはCPU1% / Webサーバーのプロセスは0.3%

実務でもスロークエリログがあってCPU使用率が跳ね上がった経験がある。

あのような事象はかなりインシデントにつながるので、普段からパフォーマンスをより意識したい。

## 4章: シナリオを持った負荷試験

この章の内容は自分の勤務先でもやりたい...！

どの画面表示時に遅いのかをシナリオを使って調査して可視化できるのはとても良い。

よりユーザー目線に立ったテコ入れができると感じる。

テスト環境ではデータ量が足りず、どうしてもクライアントのボトルネックに気付けないという問題がある。

ローカルだと開発生産性に影響するのでやりたくないから、それ用の環境を作るとかになるのかな。
コスパとの相談かも

それを事前に検知できる仕組みが欲しい。

書籍だとOSSの[k6](https://k6.io/open-source/)というツールを紹介している。

## 5章: データベースのチューニング

特に印象に残ったのはインデックス周りのこと。二分探索に適した構造であるBツリーについて。

インデックスの走査についてかなり丁寧に説明されていた。

- `Covering Index`
- インデックスを貼る基準として頻繁に使われるカラム。それ以外は「ORDER BY」で並び替えを行うカラムに貼る

### Covering Index について

ref. [https://dev.mysql.com/doc/refman/5.6/ja/glossary.html#glos_covering_index](https://dev.mysql.com/doc/refman/5.6/ja/glossary.html#glos_covering_index)

> クエリーによって取得されたすべてのカラムを含むインデックス。完全なテーブル行を見つけるためのポインタとしてインデックス値を使用する代わりに、クエリーはインデックス構造から値を返し、ディスク I/O
> を節約します。InnoDB セカンダリインデックスには主キーカラムも含まれるので、InnoDB は MyISAM よりも多くのインデックスにこの最適化方法を適用できます。InnoDB
> は、トランザクションが終わるまで、そのトランザクションによって変更されたテーブルに対するクエリーにこの方法を適用できません。正しいクエリーの場合、どのカラムインデックスまたは複合インデックスでも、カバリングインデックスとして機能できます。可能な場合は必ず、この最適化方法を活用するようにインデックスおよびクエリーを設計してください。

usersテーブルのnameカラムにindexが貼ってあるとする。

これだとidがプライマリーインデックス / nameがセカンダリインデックスとなる。

下記のSQLクエリ結果セットで利用しているカラムはidとnameだけなので`Covering Index`が有効になる。（EXPLAIN結果のExtraにUsing
Indexが付与される。）

これにより、テーブルフルスキャンでなくインデックススキャンのみで結果を返すのでパフォーマンスが良くなる。

`SELECT *`の場合は、全てのカラムにインデックスを貼っていないので `Covering Index` は無効となる。

```sql
SELECT id
FROM users
WHERE users.name = 'hoge'
```

## 6章: リバースプロキシの利用

リバースプロキシが必要な理由としてアプリケーション側のHTTPコネクションでは捌ききれないというものがある。

本書では例としてunicornを利用したRubyアプリケーションのマルチプロセス・シングルスレッドを紹介している。

- クライアントからの1リクエストを1プロセスが処理する。
  - そのプロセスは処理を行なっている間に他のリクエストを処理できない。（プロセス数 = 最大リクエスト数）
    - 大量リクエストの場合、パフォーマンスが極端に低下するC10K問題を抱えている（1万リクエストを受け取ると処理が急激に悪化する問題）
      - プロセス切り替え時のコンテキストスイッチが大量発生。新しいプロセス用のキャッシュ切り替え => 処理悪化
      - 異なるプロセス同士では通常メモリ共有ができないためメモリ使用量が多くなる

このように大量のリクエストを捌くのが難しいので、リバースプロキシでクライアントとのHTTPコネクションを解決する。

代表的なものとしてNginxがある。

マルチプロセス・シングルスレッドは同じだがイベント駆動アーキテクチャであるため、1プロセスが複数クライアントのリクエストを処理できる。

ノンブロッキングI/O（他の処理でのファイル読み書きが完了するまで待たない）と多重I/Oを活用し、イベント駆動でリクエスト・レスポンスを大量に捌くことでC10Kを解決している。

業務でもNginxを利用しているがあまり触っていないため色々と忘れがちなので、適宜振り返っていきたいと思う。

## 7章: キャッシュの活用

この章を読んでキャッシュは慎重に利用したいと感じた。

- 古いデータが表示されるリスク
- 想定外データを表示して情報流出のリスク
- キャッシュミドルウェアがシステムの障害点に
- プログラムの実装が複雑になる

本書ではこのような問題があるのでまずはキャッシュを使わない方法を模索してみようと記述されている。

確かに扱い方によってはリスクを孕んでいる。

また、アプリケーションのインメモリで管理するか外部のミドルウェア（Redis等）で管理するかも考慮ポイント。

- キャッシュの生存時間（TTL）
- Thundering herd problem
  - キャッシュ無い状態で大量リクエスト
    - => キャッシュ生成するまで処理が続くかつ大量リクエスト
    - => パフォーマンス悪化

などの問題をちゃんと考慮しないといけないということを認識できた。

## 8章: 抑えておきたい高速化手法

特に印象深かったものだけ

- 同一ホストへのコネクションを使い回す
  - イテレーションで毎回コネクションを作るなどナンセンス。毎度TCPのハンドシェイクが必要になり大量のオーバーヘッドが発生してしまう。確立したコネクションを変数に入れて使い回すなどの対応が必要
- 適切なタイムアウトを設定
  - 常に通信が成功するとは限らないので、ネットワーク障害などに備えて処理時間上限を設けておかないとそこがボトルネックになる。
- HTTPヘッダーを活用してクライアント側にキャッシュさせる
  - 画像ファイルやCSSファイルなどは更新頻度が低く、参照頻度が高いためCache-Controlヘッダーを活用してキャッシュデータを使いまわせるようにする
  - Cache-Controlヘッダーの期限切れの場合にのみリクエストを行うことで、無駄なリクエストを減らせる
- 静的ファイル配信をリバースプロキシから直接配信する
  - RDBMSに画像データを持たずに静的ファイルにしてNginxから配信させると、無駄な処理を省ける（RDBMSの場合大きなデータを読み込むのでMySQLのメモリを圧迫したり、ネットワーク帯域を圧迫するなど）
- CDN上にHTTPレスポンスをキャッシュする
  - キャッシュしたレスポンスを返すことでアプリケーションサーバーへのリクエストを減らせる。
  - クライアントから近いCDNエッジからレスポンスを直接返せるので、高速な処理が実現できる

最近、CDN周り（特にCloudflare Workers）をちゃんと触ってみたい欲がすごい。

## 9章: OSの基本知識とチューニング

割とOS周りが詳しく記述されているがポイントだけ。Linux周りがまだ分からないことだらけなのでもっと学びたい。

- Linux Kernelの基礎知識
  - カーネル空間 / ユーザー空間
    - System Callを発行する側（アプリケーションやブラウザなど）: ユーザー空間
    - System Callを受け取ってハードウェアを制御する側: カーネル空間
  - プロセス
    - ユーザー空間で実行中のプログラム単位（Webサーバー等）
  - init / systemd
    - Linuxにはinitという親プロセスがありその下に子プロセスが紐づく（initの実装は最近systemdが多い）
  - コンテキストスイッチ
    - 複数のプロセスを動作させるため、超高速でプロセスを切り替えることで擬似的に複数プロセスが同時に動作しているように見せる => コンテキストスイッチ
  - ディスクI/O
    - 逐次読み書き: シーケンシャルリード / ライト
    - 現代では保存領域を上から逐次読み書きするのは現実的ではなくランダムリード/ライトが重視
  - I/Oスケジューラ
    - ディスク読み書き制御用パラメータ
    - Ubuntu20.04では、mq-deadlineスケジューラが採用
  - ファイルディスクリプタ
    - プログラムがアクセスするファイルや標準入出力などをOSが識別するために用いる識別子
    - プロセス側からOSに対してこの識別子を指定することで読み書きできる
  - UNIX domain socket
    - 同じホスト内の別プロセスに対して高速にデータを送受信する仕組み
    - 同じホスト内であることが前提のためネットを介さないことを活かした高効率な通信。

## まとめ

パフォーマンスチューニングの書籍だけれど、ミドルウェアの設計やアーキテクチャの基礎知識に対する説明が丁寧にされていたのが好印象。

`Covering Index`の概念を知れたのはよかった。Linux周りがまだ分からないことだらけなのでもっと学びたい。あとCDNも。


<書評> 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践


## 概要

良いコード/悪いコードで学ぶ設計入門を読んで学びになったことをつらつらと書いていく。

改めてコードの書き方について見直すきっかけとなった。

また、デザインパターンがあまり理解できていないのでそこを学びたいと思った。

## 1章: 悪しき構造の弊害を知覚する

**低凝集は避ける**

データやロジックが分散して低凝集になっていると人間が認知できなくなる。

具体的に言うと、ある操作のロジックを追加するときに複数箇所を修正しないといけない場合、変更漏れが起こる可能性が高い。

そうなると、対応したのに対応していないというクレームが上がってきて追加修正しないといけない。

信頼も失ってしまうので、また、それを知らずに重複コードを書いてしまう可能性や可読性の低下を招いてしまう。

さらに、そのコード動作前に初期化処理が必要な場合、それを忘れてしまってnullに対してロジックを実行してしまって実行時エラーになったりとか。

個人だけでなくチーム全体の生産性にも悪影響なので、そういったコードは書かない方が良いなと改めて感じた。

## 2章: 設計の初歩

### 変数への再代入を避ける

変数を使い回すと期待通りの出力にならない可能性があり、バグを埋め込んでしまうことになる。

読み手も混乱させてしまうので、変数を使い回さずに目的ごとに変数を用意して処理した方が良い。

## 3章: クラス設計

クラス設計のエッセンス

- クラスが単体で正常動作するように疎結合を保つ（高凝集）
- 複雑な初期設定をせずとも使えるようにする
- 外部公開メソッドは慎重に

### コンストラクタで確実に正常値を設定する

これによりインスタンス化する際に正常値が確実に設定されることを担保できる。

### メソッド引数やローカル変数を不変にする

途中で値が変化すると追うのが難しくなるのでバグを引き起こしてしまう。

### 値の渡し間違いを型で防止する

関数は通貨の数字が渡されるのを期待しているのに、number型で定義しているので通過以外の数字が渡ってきてしまう。

```js
// NG
const totalMoney = (money: number) => {
// 処理
}
totalMoney(3)
// OK
const totalMoney = (money: Money) => {
// 処理
}
totalMoney(3)
```

上記例ではMoney型の変数を渡しているが、この変数は正常値だけを持つインスタンスを生成するためのコンストラクタ。

「**完全コンストラクタ + 値オブジェクト（**値そのものとクラスとして切り出し表現する**）**」

オブジェクト指向設計の基本形。

異常値をいかに生み出さないかに焦点が置かれていると思った。

"クラス設計とは、インスタンス変数を不正状態に陥らせないための仕組みづくりと言っても過言ではありません"
と筆者が述べているように、いかに異常値を防ぐかがポイント。

確かに普通に考えて設計図から意図しないものが生まれてきたら設計図の意味を成してないよなと思う。

## 4章: 不変の活用

### 副作用のデメリット

副作用とは、関数が戻り値を返す以外に外部の状態（変数など）を変更すること副作用ってどこまで許容するべきなのかは割と難しいかもしれないと感じる。

影響範囲を留めるべきというのは分かるが関数内で引数を操作して返すというのは割とやっている気がする。

クラスやサービス横断して副作用を生み出すのは良くなさそう。

## 5章: 低凝集

### 共通処理クラスを安易に作らない

**Common**とか**Util**とか**神クラス**とか

ログ出力やエラー処理、デバッグや例外処理などの横断的関心事であれば
共通処理として切り出しても良いが、それ以外の場合は本当に共通処理が必要か考えた方が良い。

共通処理という名の雑多なロジック生まれがち。

### 引数は少なく

引数が多すぎると低凝集に陥りがち。

引数が多いとそれだけ処理内容が増えるのでロジックの複雑化や重複コードにつながってしまう。

そういう場合、データを引数として扱うのではなくそのデータをインスタンス変数としてもつクラスへと変更してみる。

この考え方は学びになった。

メソッド内で複数のオブジェクトを操作している状態から、クラスとして切り出し関心事を分離していく。

そうすることで全体として見通しが良くなるなと感じた。

### 尋ねるな命じろ

他のオブジェクトの状態を問い合わせるのではなく、呼び出し側はただメソッドを呼び出すだけにする。

オブジェクトの状態を判定するロジックなどは呼ばれる側で実装するべき。

こうすることでロジックの高凝集につながる。

この考え方はAPI設計に通ずるものがあると感じた。外部インターフェースとして呼び出すものを与えるだけで、内部状態は気にさせない。呼び出す時も余計なロジックを考えずに済む。

## 6章: 条件分岐

この章は条件分岐はinterfaceに書き換えると良いということが学びになった。

## 8章: 密結合

継承はなるべく非推奨とのこと。サブクラスがスーパークラスに依存するので密結合やロジック混乱などになりがちとのこと。

書籍には「ある継承クラスにとっては関係があっても、別の継承クラスには無関係なメソッドが登場し始めると問題」とあったけれど、これは単一責任の原則を破っているからだと思う。

[Qiita](https://qiita.com/tonluqclml/items/c0110098722763caa556)とかに参考記事があったけれど、共通メソッドや変数を共有するためなどの安易な継承は避けるべきだというのを見て納得した。

## 10章: 名前設計

書籍では目的駆動名前設計を推してる。

目的ベースでの命名。確かに商品や顧客にもいろいろな切り口があるのでしっかりと目的を検討して区別する必要ある。

ドメイン理解と元に切り分ける大事さ。

特に印象に残ったのが、「**形容詞で区別が必要なときはクラス化のチャンス**」ということ。

正しくその通りだなと思ったので、今後意識していきたいなと考えている。

## 12章 メソッド

### CQS（コマンドクエリ分割）

メソッドはコマンド（変更）またはクエリ（問い合わせ）のどちらか一方だけを行うようにするという考え方らしい。

これは自然と意識するようにしてるなと思う。パターン名があったというのが発見かも。

## 13章 モデリング

10章名前設計の章と被るところだが、任意のモデルが適切に分割されていることが大事だなと思う。

単一責任の原則をどれだけ意識できているか？自分達のドメインでCustomerモデルはどういう種類の顧客を扱っているのか？

それをするには事業ドメインを深く理解することが大事。

## 16章: 設計を妨げる開発プロセスとの戦い

色々記述されているが「**既存コードを信用せず、冷静に正体を見破る**」を意識したい。

既存実装を模倣することが多いけれど、その実装は本当にベストなのか？は今一度冷静になって見極める意識を持ちたい。

## まとめ

今のチームが拡大するにあたって保守性を第一に考えたいと思っていて、設計周りをきちんと抑えておきたかったので読んだ。

筆者の主張がいくらか強い部分もあったけれど、クラス設計やCQSなど勉強になった。今一度良いコードとは何かを考え直すきっかけになったと思う。次はドメイン駆動設計やデザインパターンをちゃんと抑えたい。


<書評> 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方


## 概要

[type-challenges](https://github.com/type-challenges/type-challenges) というTS文法の練習問題リポジトリがある。

興味本位で解いてみたら楽しくなってきてeasyレベルからmediumレベルまで81問解いてしまった。

その際にTSについての学びが色々あったので共有する。

## 学び一覧

- mapped types
- conditional types
- infer
- minus operator
- union distribution
- never
- template literal types
- length property
- index(numeric) signature
- bottom type

### mapped types

公式doc: [https://www.typescriptlang.org/docs/handbook/2/mapped-types.html](https://www.typescriptlang.org/docs/handbook/2/mapped-types.html)
型引数が主にユニオン型orオブジェクトの場合に利用することが多い。型引数をイテレーションして結果出力する。

```typescript
type MappedTypes<T extends object> = { [P in keyof T]: T[P] };
type s = MappedTypes<{ key: 'test'; value: 'test' }>;
// type s = {
//   key: 'test';
//   value: 'test';
// }

type MappedTypes2<T extends string> = { [P in T]: string };
type t = MappedTypes2<'test' | 'tt'>;
// type t = {
//   test: string;
//   tt: string;
// }
```

### conditional types

公式doc: [https://www.typescriptlang.org/docs/handbook/2/conditional-types.html](https://www.typescriptlang.org/docs/handbook/2/conditional-types.html)
型の条件分岐を実現する。

```typescript
TypeA extends TypeB ? true : false
```

公式docによるとこの条件はextendsの左の型が右の型に代入可能かどうかを判定している。

> When the type on the left of the extends is assignable to the one on the right, then you’ll get the type in the first branch (the “true” branch); otherwise you’ll get the type in the latter branch (the “false” branch).

そのためこれはもちろんfalse

```typescript
type test = string extends number ? true : false;
// => false
```

こちらは原則から考えてtrueになる。

```typescript
type test = 't' extends string ? true : false;
// => true
```

bottom typeの節でneverやundefinedをconditional typesで比較検証する。

### infer

[公式doc](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#type-inference-in-conditional-types)
型を割り出してその後利用できる。

conditional typesとセットで利用する。

例えば、type-challengesの[Last of Array](https://github.com/type-challenges/type-challenges/blob/main/questions/00015-medium-last/README.md) の問題では下記のように解ける。

型引数Tをconditional typesで分岐させ、その中でinferを利用して推論した変数L（配列の最後の要素）を利用する。

```typescript
type Last<T extends any[]> = T extends [...infer _, infer L] ? L : never;
type s = Last<[]>;
// => never

type t = Last<[1, 2, 3]>;
// => 3
```

### minus operator

[公式doc](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#improved-control-over-mapped-type-modifiers)
mapped types内のreadonlyや?を削除するための修飾子例えば、type-challengesの[Mutable](https://github.com/type-challenges/type-challenges/blob/main/questions/02793-medium-mutable/README.md) の問題では下記のように解ける。

```typescript
type Mutable<T> = {
  -readonly [K in keyof T]: T[K];
};

type s = Mutable<{ readonly test: 1 }>;
// type s = {
//   test: 1;
// }
```

### union distribution

**conditional types**や**mapped types**にunion型を渡すと1つずつ処理される。

conditional typesでは条件の左部分が型変数である場合にunion型が分配される。

```typescript
type Equal<U> = U extends 1 ? U : never;
type s = Equal<1 | 2>;
// type s = 1
```

例のコードでは型変数Uにunion型が渡っており1だけを返す。つまり下記が行われている。

```typescript
type TypeA = (1 extends 1) ? U : never
type TypeB = (2 extends 1) ? U : never
```

mapped typesでは以下のような形の場合にunion distributionが発生する。

```typescript
{ [P in keyof T]: X}
```

```typescript
type Distribution<T> = { [P in keyof T]: T[P] };
type val = Distribution<{ foo: string } | { bar: number }>;
// type val = Distribution<{
//    foo: string;
// }> | Distribution<{
//    bar: number;
// }>
```

### never

[サバイバルTypeScript](https://typescriptbook.jp/reference/statements/never)より

> TypeScriptのneverは「値を持たない」型。
> 1️⃣特性1: neverへは何も代入できない
> 2️⃣特性2: neverは何にでも代入できる
> 💥常に例外を起こす関数の戻り値に使える

[TypeScript Deep Dive](https://typescript-jp.gitbook.io/deep-dive/type-system/never)より

> プログラミング言語の設計には、bottom型の概念があります。
> それは、データフロー解析を行うと現れるものです。
> TypeScriptはデータフロー解析(😎)を実行するので、決して起こりえないようなものを確実に表現する必要があります。
> never型は、このbottom型を表すためにTypeScriptで使用されます。

[Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%95%E3%83%AD%E3%83%BC%E8%A7%A3%E6%9E%90) より

> データフロー解析（英: Data-flow analysis）は、プログラム内の様々な位置で、取りうる値の集合に関する情報を収集する技法である。

制御フローグラフ (CFG)を使って変数の値が伝播するかどうかなどの情報を集め、利用する。

このようにして集められた情報はコンパイラが最適化に利用する。

データフロー解析の基本は到達定義 (reaching definition) である。

### template literal types

JSのテンプレートリテラルを使って展開した値をそのまま型として定義できる。

```typescript
type Join<T extends string, U extends string> = `${T}-${U}`;
type joinedStr = Join<'foo', 'bar'>;
// type joinedStr = "foo-bar"
```

conditional types + inferを利用していこんな風にも書ける。

```typescript
type TemplateLiteral<T extends string> = T extends `${infer F}${infer _L}`
  ? F
  : never;
type str = TemplateLiteral<'foo'>;
// type str = "f"
```

type-challengesで文字列操作するときに初めて知って表現力に驚いたな。

### length property

配列やタプルの要素数をカウントして返す

```typescript
type val = [1, 3]['length'];
// type val = 2
```

Arrayのinterfaceにlengthプロパティが存在する。

```typescript
interface Array<T> {
  /**
   * Gets or sets the length of the array. This is a number one higher than the highest index in the array.
   */
  length: number;
}
```

[https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L1220-L1402](https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L1220-L1402)

### index (numeric) signature

配列(orタプル)TにおいてT[number]がunion型で返ることから知った
[公式doc](https://www.typescriptlang.org/docs/handbook/2/conditional-types.html) にも記載ある。

[stackoverflow](https://stackoverflow.com/a/59188070) の記事では、Arrayは下記のようなinterfaceになっていて numberを使ってindexをまとめて取得できるよう。

[https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L388-L392](https://github.com/microsoft/TypeScript/blob/main/lib/lib.es5.d.ts#L388-L392)
かな？

### bottom type

neverは値を持たないということを表す型でありbottom型とも呼ばれる。集合論で表すと空集合。

never型には何も代入できない（値持たないから）が、never型は他の型に代入できる。

他の全ての型のサブタイプ（部分型）となる。

is-aの関係。逆はできない（他の型をnever型に代入）

```typescript
let neverVal: never = 1 as never;
// never 型は bottom type なのでstring型に代入可能

let str: string = neverVal;
```

ちなみにunkhownは全ての型のスーパータイプなのでどんな型でも代入可能

```typescript
let str = 'str';

// unkhown 型は super type なのでstring型を代入可能
let neverVal: unknown = str;
```

[TS型の階層性](https://zenn.dev/estra/articles/typescript-type-set-hierarchy#%E5%9E%8B%E3%81%AE%E9%9A%8E%E5%B1%A4%E6%80%A7) に詳しく説明がある。

## 今後知りたいこと

- type widening
- homomorphic mapped types
- union distributionをキャンセルする
- etc...

## まとめ

[type-challenges](https://github.com/type-challenges/type-challenges) でTSの型プログラミングにどっぷりハマった。

また再帰的に解く問題が多かったので自然と再帰的に考えられたのもとても良かった。

この経験を通じてTSが好きになったのでもっと深掘りたいと思えたのは大きな収穫。


<書評> type-challengesでeasyからmediumまで81問解いて学んだTSの型プログラミング


## 要約

TSの基礎的な内容が割と網羅されている印象。
抜けていた基礎知識を補えたのが良かった。

## 1章

TSバージョンの年表が面白かった印象。
TS 4.1から応用性の高いtemplate literal typesが導入されてお祭り騒ぎになったらしい。元[PR]("https://github.com/microsoft/TypeScript/pull/40336")はこちら。
template literal typesってinferと組み合わせると有用だなと思ったり。

あとはenum使わない方が良いみたいなのは知らなかった。JSには存在しない独自機能だからとのこと。

[LINE社の記事]("https://engineering.linecorp.com/ja/blog/typescript-enum-tree-shaking/")を見ると、
JSに存在しないenumを表現するためにIIFE(即時実行関数)を含んだコードをトランスパイルするらしい。それがバンドルされてしまうからtree-shakingできなくなるよとのこと。なるほど。

## 2章

値がない状況を表すのにundefinedの方が推奨されるとのこと。

[MicrosoftのTSコーディング規約]("https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined")にも **Use undefined. Do not use null.
**の記載がある。

[サバイバルTypeScript]("https://typescriptbook.jp/reference/values-types-variables/undefined-vs-null")にはこのような記述がある

- undefinedは「値が代入されていないため、値がない」nullは「代入すべき値が存在しないため、値がない」
- nullは自然発生しない
- undefinedは変数
- undefinedはtypeofの結果がプリミティブ名を表す\"undefined\"になるのに対し、nullは\"null\"ではなく\"object\"になります。

最後のは割とびっくりする挙動。言語仕様的にundefinedが自然発生してくれるのでそれに合わせにいくのが良さそう。

ただ外部APIとのやり取りでnullが渡ってくるのはあると思うので、そこの考慮が必要そう。

[Null 合体演算子 (??)&nbsp;]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing_operator") と [論理 OR 演算子 (||)&nbsp;]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_OR") の違いを知った。 **||** はnullやundefinedだけでなく空文字や0、falseなども \"ない\"と評価して右辺値を返すが、**??** はnull orundefinedの場合のみ右辺値を返す。


ES2021の新機能として [||=(論理和代入)]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_OR_assignment")[ \*\*\*\*]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_OR_assignment")や[**&&=**]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_AND_assignment")[(論理積代入)]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Logical_AND_assignment")演算子もある。

論理和代入はrubyの自己代入演算子と同じ。論理積代入は左辺がtruthyなものの場合に右辺の値を左辺に代入。

## 3章

### スプレッド構文とシャローコピー

スプレッド構文はシャローコピーであること。
下記よりスプレッド構文でコピーしてもネストしたオブジェクトは同じアドレスを共有している。

```typescript
const object = { name: 'test', type: { a: 'a' } };
const anotherObject = { ...object };
object.name = 'object';
anotherObject.type.a = 'b';

console.log('object', object);
// object { name: 'object', type: {a: 'b'} }
console.log('anotherObject', anotherObject);
// anotherObject { name: 'test', type: {a: 'b'} }
```

[ディープコピーをする方法]("https://developer.mozilla.org/ja/docs/Glossary/Deep_copy")の1つとして、**JSON.stringify()** でオブジェクトを JSON 文字列に変換し、
**JSON.parse()** で文字列から（完全に新しい） Javascript のオブジェクトに変換する方法がある。
また、ネストしたオブジェクトもスプレッド構文で展開する等々。

### インデックスシグネチャについて

[インデックスシグネチャ]("https://typescript-jp.gitbook.io/deep-dive/type-system/index-signatures")は型安全性を破壊する。
オブジェクトのkeyがstringの場合、obj.key でアクセスできるが、obj.foo /
obj.aなど任意のkeyにもアクセスできてコンパイルエラーにならないので型安全ではない。

```typescript
type Obj = { [key: string]: number };
const obj: Obj = { foo: 1 };

console.log(obj.t);
// => コンパイルエラーにならない
```

### 部分型関係について

型Sが型Tの部分型であるとは、S型の値がT型の値でもあることを指す。
下記の例ではFooBarBaz がFooBar
の部分型である。
FooBarBazはFooBarの要素を全て持つ。FooBarBaz型であればFooBar型でもあるということ。

```typescript
type FooBar = { foo: string; bar: number };
type FooBarBaz = { foo: string; bar: number; baz: boolean };
const obj: FooBarBaz = { foo: 'hi', bar: 1, baz: false };

console.log('obj', obj);
// "obj",{"foo":"hi","bar":1,"baz":false}

const obj2: FooBar = obj;
console.log('obj2', obj2);
// "obj2",{"foo":"hi","bar":1,"baz":false}
```

### タプル型

要素数が固定された配列型。
要素数が固定されている代わりに、それぞれの要素に異なる型を与えられる。

### オブジェクトの分割代入（destructuring assignment）について

型注釈つけられないで型推論していく

### プリミティブのプロパティ

文字列や数値などのプリミティブ型は、プロパティを持ったオブジェクトとして扱える。

プリミティブ型をまるでobjectのように扱えるのはJSの特徴。JSには、プリミティブ型をオブジェクトに自動変換するオートボクシングと呼ばれる機能がある。参考:
https://typescriptbook.jp/reference/values-types-variables/primitive-types

```typescript
'name'.length; // 4
```

## 4章

### contextual typing

逆方向の方推論のことで、型が事前に分かっている場合の推論。
通常の型推論は型注釈は無いけれど値から型を推論できる場合に発動

```typescript
const xRepeat = (arg: number): string => 'x'.repeat(arg);
// xRepeatの型が自動的にconst xRepeat: (arg: number) => string と判定される
```

逆方向の型推論は型を事前に割り当てているから式中の型を省略できる。

```typescript
type F = (arg: number) => string;
const xRepeat: F = (arg) => 'x'.repeat(arg);
// (arg: number): string の指定は不要
```

コールバック関数なども指揮中で引数の型を書かない場合が多い。
例えばfilterなどはレシーバを元に型引数が決まる。

```typescript
const nums = [1, 2, 3];
const ary = nums.filter((x) => x > 2);
// 式中xの変数をnumberとしなくても x>2 でコンパイルエラーが起きない
// (value: number) => unkhown
```

## 5章

protectedはクラス自身だけでなく子クラスからもアクセス可能。rubyと同じだな。

### プライベートプロパティについて

\#プロパティ名 と private修飾子をつけたもの両方で表現可能。

- privateはTS独自機能なのでトランスパイル後のランタイム上では普通のプロパティとして扱う。
- \#プロパティ名はJSの機能なのでランタイム上でもプライベート性が担保される

### this

thisはプロパティを参照することが多く、そのプロパティがundefinedであった場合にランタイムエラーが発生する可能性あり。

- アロー関数は外側のthisを引き継ぐ
- 普通の関数は呼び出し時のレシーバをthisとする

アロー関数への書き換えをするリファクタリングを業務で行ったなあ。

## 6章

### インターセクション型

T型でありかつU型でもある値を意味する型
参考: https://typescriptbook.jp/reference/values-types-variables/intersection
ちなみに string
& numberのプリミティブのインターセクション型は存在しないのでnever返る

### [Optional chaining]("https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Optional_chaining")

レシーバに対する参照が nullish (null または undefined) の場合にエラーとなるのではなく、式が短絡され undefined
が返される。
?.はそれ以降のプロパティアクセス・関数呼び出し・メソッド呼び出しをまとめて飛ばす効果を持つ。

```typescript
const adventurer = { name: 'Alice', cat: { name: 'Dinah' } };
const dogName = adventurer.dog?.name.t;
console.log(dogName);
// expected output: undefined
// dogが存在しないのでそれ以降の .name.t は評価されずにundefinedが返る
```

### リテラル型のwidening

リテラルが自動的に対応するプリミティブ型に変化する（広げられる）特徴。

constの場合はリテラル型なのにletの場合はプリミティブ型に変化している。

letは再代入が期待されるのでプリミティブ型に変化する。

ちなみにconstで宣言したオブジェクトリテラルも再代入可能なのでwideningされる。

```typescript
const test1 = 'test';
// const test1: "test"

let test2 = 'test';
// let test2: string

const test = { a: 'a', b: 1 };
// const test: { a: string; b: number; }
```

wideningを防ぎたい場合は、リテラル型を含む型注釈をつけるか as constを利用して宣言する。

### ユニオン型

型の絞り込みに対応している点が素晴らしいとのこと。なるほど、そういう解釈ができるのか。

関数の引数をユニオン型で取って、式中で型の分岐を行つつ処理をしていけるということに価値があるのか。

### lookup型

**T[K]** のようにオブジェクトプロパティにアクセスする際の型

### as const

asを使った型アサーションは型安全性を破壊しかねないけれど、as constはそれとは異なる。

1.  配列リテラルの型推論結果を配列型ではなくタプル型にする
2.  オブジェクトリテラルから推論されるオブジェクト型は全てreadonlyになる（配列リテラルも）
3.  プリミティブのリテラル型がwideningしない
4.  テンプレート文字列リテラルの方がstringではなくテンプレートリテラル型になる

```typescript
// readonly
const names = ['taro', 'jiro'] as const;
// const names: readonly ["taro", "jiro"]

const obj = { name: 'test', address: { city: 'xxxx' } } as const;
// const obj: {
//  readonly name: "test";
//  readonly address: {
//    readonly city: "xxxx";
//  };
// }
// wideningされない

const name1 = 'name' as const;
let name2 = name1;
let name2: 'name';
// let name2: "name"

let name3 = 'name3';
// let name3: string
// templateliteral type

const n: number = 1;
const value = `${n}px` as const;
// const value: `${number}px`
```

### any型とunkhown型

- any型
  - 型チェックを無効化する型。基本的に何でも代入可能なのでコンパイルエラーにならない。
  - JSからTSへの移行を支援するためや、型をうまく表現できないためのエスケープハッチとしての存在理由あり
  - anyよりasやユーザー定義型ガードの利用を検討した方が良い
- unkhown型
  - なんでも入れられる型。何かは入っているが何かは分からないような状況を表す
  - anyはコンパイルエラーにならないので、val.nameなどにアクセスできるがunkhownはできない。TSコンパイラがunkhownは値がないことを読み取ってできることを制限してくれる。

### **never型**

値を持たないことを表す型
never型には何も代入できない。（never型にnever型は代入可能）

他の型にnever型は代入できる。そのため、[TSではbottom型と呼ばれている]("https://typescript-jp.gitbook.io/deep-dive/type-system/never")。（[取りうる値の集合が一番大きい]("https://ja.wikipedia.org/wiki/%E3%83%9C%E3%83%88%E3%83%A0%E5%9E%8B#:~:text=%E3%83%9C%E3%83%88%E3%83%A0%E5%9E%8B%EF%BC%88%E3%83%9C%E3%83%88%E3%83%A0%E3%81%8C%E3%81%9F,%E3%81%84%E3%81%8B%E3%81%AA%E3%82%8B%E5%80%A4%E3%82%82%E8%BF%94%E3%81%95%E3%81%AA%E3%81%84%E3%80%82") => ボトム型は全ての型の部分型）

#### [voidとneverの違い]("https://typescriptbook.jp/reference/statements/never")

- voidはundefinedを代入できるがneverはできない（値を持たないから）
- どちらも戻り値がないことは同じ
  - voidは関数がreturnされるか、最後まで実行されることを表す
  - neverは中断されるか永遠に実行される

### **ユーザー定義型ガード**

型の絞り込みの一種
**引数名 is 型名** という形で引数を型名で絞り込んで処理する。
下記の関数は戻り値がbooleanであり、trueならば引数がstring or
numberであるということを意味する。

```typescript
function isStringOrNumber(value: unknown): value is string | number {
  return typeof value === 'string' || typeof value === 'number';
}

function useUnknown(v: unknown) {
  // v はここでは unknown 型
  if (isStringOrNumber(v)) {
    // v はここでは string | number 型
    console.log(v.toString());
  }
}
```

参考: [https://blog.uhy.ooo/entry/2021-04-09/typescript-is-any-as/]("https://blog.uhy.ooo/entry/2021-04-09/typescript-is-any-as/")
**asserts 引数名 is 型名** という型述語もある。
この場合は戻り値がvoidで「関数が無事に終了すれば引数名は型名である」

### **union distribution**

conditional typesの性質
conditinal typesを利用している型にユニオン型を渡すと分配して処理してくれる
[公式]("https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#distributive-conditional-types") のやつコピペしただけだけどこんな感じになる。

```typescript
type ToArray<Type> = Type extends any ? Type[] : never;

type StrArrOrNumArr = ToArray<string | number>;
//  ToArray<string> | ToArray<number>; と等しいので、string[] | numbe[]が返る
```

## 7章

### commonJS

[nodejsで利用されているソースコードをパッケージ化するモジュール。]("https://nodejs.org/docs/latest/api/modules.html")
最近はECMAScriptのESmodule形式も採用しているよう。
requireを利用してimportする。

```typescript
const circle = require('./circle.js');
console.log(`The area of a circle of radius 4 is ${circle.area(4)}`);
```

## 今後

(本書付録2の更なる学習の道しるべコピペしただけ)

### JS言語機能

- イテレータ・ジェネレータ
- メタプロ系
  - オブジェクトの操作（Object.keys）など
  - プロパティディスクリプタ・プロパティ属性
  - Reflect・Proxy
- シンボル
- prototype

### TSの言語機能

- 標準ライブラリに属する他の型（Record・Parameters・Awaitedなど）
- abstractクラス・abstract new シグネチャ
- 型レベルプログラミング
- mapped types conditionaltypes
  - infer / union distribution / homomophic typesなど


Kdevlog

<書評> Java言語で学ぶデザインパターン入門第3版第1弾

<書評> 現場で役立つシステム設計の原則

<書評> ドメイン駆動設計入門: ボトムアップでわかる!ドメイン駆動設計の基本

<書評> 達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践

<書評> 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい成長し続けるコードの書き方

<書評> type-challengesでeasyからmediumまで81問解いて学んだTSの型プログラミング

<書評> プロを目指す人のためのTypeScript入門安全なコードの書き方から高度な型の使い方まで

Kdevlog

<書評> Java言語で学ぶデザインパターン入門第3版 第1弾

<書評> 現場で役立つシステム設計の原則

<書評> ドメイン駆動設計入門: ボトムアップでわかる!ドメイン駆動設計の基本

<書評> 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践

<書評> 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方

<書評> type-challengesでeasyからmediumまで81問解いて学んだTSの型プログラミング

<書評> プロを目指す人のためのTypeScript入門 安全なコードの書き方から高度な型の使い方まで

<書評> Java言語で学ぶデザインパターン入門第3版第1弾

<書評> 達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践

<書評> 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい成長し続けるコードの書き方

<書評> プロを目指す人のためのTypeScript入門安全なコードの書き方から高度な型の使い方まで