OmniAICreator/Qiita-1.07M huggingface dataset:
Pythonで実装するFlyweightパターン：軽量オブジェクトによるメモリ最適化



## 概要

**Flyweight（フライウェイト）パターン**は、  
**多数生成されるオブジェクトのうち、共通部分を共有することでメモリ消費を抑える**ための設計パターンである。

特に、**同じ構造・状態を持つオブジェクトが大量に存在する状況**において、  
**内部状態の共有によって冗長なインスタンス生成を防ぎ、効率的なシステム構築を可能にする**。

---

## 1. なぜFlyweightが必要か？

### ❌ 同じ情報を持つ大量のオブジェクトを毎回生成すると、メモリ圧迫につながる

```python
char1 = Character("A", "Arial", 12)
char2 = Character("A", "Arial", 12)
char3 = Character("A", "Arial", 12)
```

→ 実体は同一なのに**全て別オブジェクトがメモリを消費**

---

### ✅ Flyweightで共通部分を共有し、インスタンス数を削減

```python
factory = CharacterFactory()
char1 = factory.get("A", "Arial", 12)
char2 = factory.get("A", "Arial", 12)
```

→ **同じプロパティを持つオブジェクトは再利用される**

---

## 2. 基本構造

### ✅ Flyweightクラス（共有される構造）

```python
class Character:
    def __init__(self, char, font, size):
        self.char = char
        self.font = font
        self.size = size

    def render(self, position):
        print(f"Rendering '{self.char}' at {position} with {self.font} ({self.size}px)")
```

---

### ✅ Flyweight Factory（インスタンス共有管理）

```python
class CharacterFactory:
    def __init__(self):
        self._pool = {}

    def get(self, char, font, size):
        key = (char, font, size)
        if key not in self._pool:
            self._pool[key] = Character(char, font, size)
        return self._pool[key]

    def count(self):
        return len(self._pool)
```

---

### ✅ 使用例

```python
factory = CharacterFactory()
positions = [(0,0), (1,0), (2,0), (3,0)]

for pos in positions:
    c = factory.get("A", "Arial", 12)
    c.render(pos)

print(f"生成されたインスタンス数: {factory.count()}")
```

出力:
```
Rendering 'A' at (0, 0) with Arial (12px)
Rendering 'A' at (1, 0) with Arial (12px)
Rendering 'A' at (2, 0) with Arial (12px)
Rendering 'A' at (3, 0) with Arial (12px)
生成されたインスタンス数: 1
```

---

## 3. Python的応用：`functools.lru_cache` による自動共有

```python
from functools import lru_cache

@lru_cache(maxsize=128)
def create_char(char, font, size):
    return Character(char, font, size)

c1 = create_char("A", "Arial", 12)
c2 = create_char("A", "Arial", 12)

print(c1 is c2)  # True
```

→ **Pythonの標準機能で簡易Flyweightが実現可能**

---

## 4. 実務ユースケース

### ✅ フォントレンダリングエンジン（PDF/ゲーム/エディタ）

→ 同じフォント・サイズ・文字を**何度も描画する場面で有効**

---

### ✅ 地図・座標系でのアイコン表示

→ 同一マーカー、アイコンなどを**共有インスタンスで管理**

---

### ✅ Webアプリのキャッシュ済み構成部品の使い回し

→ UI部品やレスポンステンプレートを**インスタンス化せずに使い回す**

---

### ✅ ゲーム開発での背景・敵・エフェクトパターンの共通化

→ **オブジェクトの描画・振る舞いの再利用と最適化**

---

## 5. よくある誤用と対策

### ❌ 状態をすべて内部に持たせてしまい、インスタンスごとの違いが出せない

→ ✅ **共有できる状態（内部）と固有状態（外部）を明確に分離する**

---

### ❌ Factoryが肥大化し、責務が曖昧になる

→ ✅ **取得・生成・破棄の責任を明確に分離して設計する**

---

### ❌ Flyweightを適用すべきでない状況に導入しすぎる

→ ✅ **「大量に重複するオブジェクト」が前提であることを再確認する**

---

## 結語

**Flyweightパターンとは、“繰り返される構造を賢く共有し、軽量な設計を実現する技法”である。**

- 重複構造を共有することで、**インスタンス生成コストを最小化**  
- 内部状態と外部状態を分離することで、**柔軟な管理と再利用を両立**  
- Pythonでは `dict` や `lru_cache` により、**直感的かつ軽量に設計可能**

**Pythonicとは、“冗長さを排し、必要なだけを扱うこと”。  
Flyweightパターンはその軽量性と再利用性を、構造の共有という形で表現する技法である。**
Pythonで実装するStrategyパターン：アルゴリズムを切り替え可能にする柔軟な設計



## 概要

**Strategy（ストラテジー）パターン**は、  
アルゴリズムや処理手順をオブジェクトとしてカプセル化し、**実行時に自由に切り替えられるようにする**設計パターンである。

条件分岐を排除しつつ、**動作の切り替えや拡張を柔軟に行いたいときに有効**。  
ソート手法、認証方法、価格計算、ログ戦略などに応用できる。

---

## 1. なぜStrategyが必要か？

### ❌ if/elseで処理パターンを切り替える設計はスケーラビリティに乏しい

```python
if method == "credit":
    pay_credit()
elif method == "paypal":
    pay_paypal()
```

→ **選択肢が増えるほど条件分岐が複雑化**

---

### ✅ Strategyに切り出すことで構造的に拡張可能に

```python
strategy = PayPalStrategy()
payment.set_strategy(strategy)
payment.process()
```

→ **アルゴリズム切替がクラス設計に組み込まれる**

---

## 2. 基本構造

### ✅ Strategyインターフェース

```python
class PaymentStrategy:
    def pay(self, amount):
        raise NotImplementedError
```

---

### ✅ Concrete Strategy（実装）

```python
class CreditCardStrategy(PaymentStrategy):
    def pay(self, amount):
        print(f"クレジットカードで {amount} 円支払い")

class PayPalStrategy(PaymentStrategy):
    def pay(self, amount):
        print(f"PayPalで {amount} 円支払い")
```

---

### ✅ Context（戦略を使う側）

```python
class PaymentProcessor:
    def __init__(self, strategy: PaymentStrategy):
        self._strategy = strategy

    def set_strategy(self, strategy: PaymentStrategy):
        self._strategy = strategy

    def process(self, amount):
        self._strategy.pay(amount)
```

---

### ✅ 使用例

```python
processor = PaymentProcessor(CreditCardStrategy())
processor.process(5000)

processor.set_strategy(PayPalStrategy())
processor.process(5000)
```

出力:
```
クレジットカードで 5000 円支払い  
PayPalで 5000 円支払い
```

---

## 3. Python的応用：関数ベースのストラテジー設計

```python
def credit_pay(amount):
    print(f"[関数] クレジットで {amount} 円")

def paypal_pay(amount):
    print(f"[関数] PayPalで {amount} 円")

class PaymentProcessor:
    def __init__(self, strategy):
        self.strategy = strategy

    def process(self, amount):
        self.strategy(amount)
```

```python
processor = PaymentProcessor(credit_pay)
processor.process(3000)

processor.strategy = paypal_pay
processor.process(3000)
```

→ **関数もStrategyとして機能できるのがPythonの強み**

---

## 4. 実務ユースケース

### ✅ 支払い、ログ出力、認証などの方式切替

→ **特定処理を柔軟に差し替え可能にする構造**

---

### ✅ データの変換・圧縮アルゴリズムの差し替え

→ 同じインターフェースで**異なる処理戦略を適用**

---

### ✅ システム構成に応じた動的な挙動制御

→ ローカル/クラウド、テスト/本番で**戦略を差し替え**

---

### ✅ 機械学習における予測モデルの統一インターフェース

→ モデルA, B, Cを同一戦略構造で扱い、**切替可能に設計**

---

## 5. よくある誤用と対策

### ❌ Contextクラスに戦略が固定実装されている

→ ✅ **戦略はContextの外部から注入できる構造にする**

---

### ❌ Strategyの責務があいまいで肥大化する

→ ✅ **1戦略 = 1アルゴリズム に限定してSRPを守る**

---

### ❌ Strategyの切り替えが実行中に許されない設計

→ ✅ **set_strategy()など明示的切替用メソッドを提供**

---

## 結語

**Strategyパターンとは、“やり方の違いを構造で受け入れ、選択可能にする設計”である。**

- アルゴリズムをオブジェクト化し、**選択・拡張・切替を柔軟に可能に**  
- 条件分岐を排除して、**開放/閉鎖原則に従ったスケーラブルなコードを実現**  
- Pythonでは関数・クラスの両スタイルで実装でき、**場面に応じた選択が可能**

**Pythonicとは、“処理の違いを柔らかく切り出し、選べるようにすること”。  
Strategyパターンはその柔軟さを、選択可能な知性として設計に宿す技法である。**
Pythonで実装するObserverパターン：通知と依存の明示化による反応的設計


## 概要

**Observer（オブザーバー）パターン**は、  
あるオブジェクトの状態変化を監視し、**変化に応じて他のオブジェクトが自動的に通知を受け取る**ようにする設計パターンである。

Pub/Subモデルやイベントリスナ、リアクティブプログラミングの基礎概念として広く活用される。

---

## 1. なぜObserverが必要か？

### ❌ 状態変更を受け取るオブジェクトを明示的に呼び出す必要がある

```python
def update():
    label.text = model.value
    logger.log("updated")
```

→ **変更対象が増えると呼び出し側の責任が肥大化**

---

### ✅ 依存オブジェクトが自動的に通知を受ける構造に変更

```python
model.subscribe(label.update)
model.subscribe(logger.log)
```

→ **通知と依存の分離が実現し、保守性が向上**

---

## 2. 基本構造

### ✅ Subject（観察対象）

```python
class Subject:
    def __init__(self):
        self._observers = []

    def subscribe(self, observer):
        self._observers.append(observer)

    def unsubscribe(self, observer):
        self._observers.remove(observer)

    def notify(self, value):
        for observer in self._observers:
            observer(value)
```

---

### ✅ 使用する側のロジック

```python
class Logger:
    def log(self, value):
        print(f"[Logger] value changed to: {value}")

class Label:
    def update(self, value):
        print(f"[Label] displaying: {value}")
```

---

### ✅ 使用例

```python
subject = Subject()
logger = Logger()
label = Label()

subject.subscribe(logger.log)
subject.subscribe(label.update)

subject.notify("Hello World")
```

出力:
```
[Logger] value changed to: Hello World  
[Label] displaying: Hello World
```

---

## 3. Python的応用：@property に組み込むリアクティブ風モデル

```python
class ReactiveValue:
    def __init__(self, initial=None):
        self._value = initial
        self._observers = []

    def subscribe(self, fn):
        self._observers.append(fn)

    @property
    def value(self):
        return self._value

    @value.setter
    def value(self, new):
        self._value = new
        for fn in self._observers:
            fn(new)
```

```python
rv = ReactiveValue()
rv.subscribe(lambda v: print(f"Reactive update: {v}"))
rv.value = 42
```

→ **最小構成のリアクティブシステムとして活用可能**

---

## 4. 実務ユースケース

### ✅ GUIコンポーネントとモデルのバインディング

→ **モデル更新に応じて自動でUIを更新**

---

### ✅ イベント駆動アーキテクチャ

→ モジュール間の依存を明示せず、**非同期かつ柔軟な通信を実現**

---

### ✅ 状態管理ライブラリ（ReduxやMobXなど）での反応設計

→ 状態変化に応じて**サブスクライバが反応的に振る舞う**

---

### ✅ 通知システム（Slack通知、Webhook、メール送信など）

→ **システムイベントを検知し、対応処理を動的に定義**

---

## 5. よくある誤用と対策

### ❌ 監視対象と通知先の結合が強い

→ ✅ **関数/コールバック/イベント名などで疎結合を保つ**

---

### ❌ 無限ループになる（相互通知）

→ ✅ **通知元と通知先の依存関係を明示管理し、ループ対策を入れる**

---

### ❌ オブザーバが大量に増え、パフォーマンス劣化

→ ✅ **一度だけ通知される`once`、条件付き通知`filter`などの設計を導入**

---

## 結語

**Observerパターンとは、“変化に応じた反応を、構造として設計する技法”である。**

- 状態変化に応じた処理を自動通知することで、**直感的かつ柔軟な構造が可能に**  
- モデルと表示、データと処理の依存関係を明示的に切り離し、**保守性・再利用性を向上**  
- Pythonでは関数、メソッド、ラムダをそのまま使えるため、**最小構成でも実用的な設計が可能**

**Pythonicとは、“明示的に、変化を捉え、反応すること”。  
Observerパターンはその反応性を、構造として整え、拡張可能にする知恵である。**
Pythonで実装するCommandパターン：命令をオブジェクトとして抽象化する


## 概要

**Command（コマンド）パターン**は、  
アクション（命令）をオブジェクトとして抽象化し、**実行・取消・履歴管理を柔軟に制御できるようにする設計パターン**である。

UI操作、マクロ、Undo/Redo、タスクスケジューリングなどに非常に適しており、**“何をするか”をデータとして扱える**のが強み。

---

## 1. なぜCommandが必要か？

### ❌ 操作がイベントハンドラに直書きされて複雑化

```python
def on_click():
    db.save()
    ui.refresh()
    logger.log("saved")
```

→ 処理が肥大化し、**再利用や履歴記録が困難に**

---

### ✅ 処理をCommandオブジェクトとして切り出し、実行・管理を分離

```python
command = SaveCommand(db, ui, logger)
command.execute()
```

→ **処理単位をオブジェクトとして扱える構造に変換**

---

## 2. 基本構造

### ✅ Commandインターフェース

```python
class Command:
    def execute(self):
        raise NotImplementedError

    def undo(self):
        raise NotImplementedError
```

---

### ✅ Concrete Command（処理の実装）

```python
class SaveCommand(Command):
    def __init__(self, db, ui, logger):
        self.db = db
        self.ui = ui
        self.logger = logger

    def execute(self):
        self.db.save()
        self.ui.refresh()
        self.logger.log("保存完了")

    def undo(self):
        self.db.rollback()
        self.ui.refresh()
        self.logger.log("保存取り消し")
```

---

### ✅ Invoker（命令を使う側）

```python
class CommandManager:
    def __init__(self):
        self._history = []

    def run(self, command):
        command.execute()
        self._history.append(command)

    def undo(self):
        if self._history:
            command = self._history.pop()
            command.undo()
```

---

### ✅ 使用例

```python
command = SaveCommand(db, ui, logger)
manager = CommandManager()

manager.run(command)
manager.undo()
```

---

## 3. Python的応用：関数・クロージャでCommandを表現する

```python
class FunctionCommand(Command):
    def __init__(self, func, undo_func):
        self.func = func
        self.undo_func = undo_func

    def execute(self):
        self.func()

    def undo(self):
        self.undo_func()
```

```python
cmd = FunctionCommand(
    lambda: print("実行処理"),
    lambda: print("取り消し処理")
)
cmd.execute()
cmd.undo()
```

→ **関数型スタイルとの親和性も高く、柔軟に拡張できる**

---

## 4. 実務ユースケース

### ✅ GUI操作におけるコマンド（コピー、削除、貼り付け等）

→ 各アクションをCommandとして実装し、**Undo/Redoを可能に**

---

### ✅ バッチ処理やスケジューラにおけるタスク管理

→ **遅延実行やキューイングを構造的に表現**

---

### ✅ マクロ機能の記録・再実行

→ 実行されたCommandの**履歴を保存・再生**

---

### ✅ CLI/RESTなどの抽象化された操作層の設計

→ 各API操作をCommandとして定義し、**統一インターフェースを提供**

---

## 5. よくある誤用と対策

### ❌ Commandオブジェクトに過剰な責務が集中する

→ ✅ **単一責任原則を守り、1つのCommandに1つの処理を**

---

### ❌ 実行と取り消しの副作用が対称でない

→ ✅ **undoの意味と保証範囲を明確に設計すること**

---

### ❌ 状態管理（履歴や失敗復旧）が設計に含まれていない

→ ✅ **CommandManager等を使って履歴管理・例外対応を構造に組み込む**

---

## 結語

**Commandパターンとは、“命令をオブジェクトとして抽象化し、実行をコントロールする構造”である。**

- アクションをオブジェクト化し、**再利用・取り消し・記録が可能に**  
- 実行の詳細を隠蔽しながら、**柔軟な操作制御を実現**  
- Pythonでは関数・クラス・クロージャを活用し、**極めて簡潔に表現できる**

**Pythonicとは、“処理をデータとして扱う柔らかさ”。  
Commandパターンはその柔軟性と構造化の美を、命令という抽象に込める技法である。**
Pythonで実装するPrototypeパターン：インスタンス生成の柔軟性を高めるコピー構造



## 概要

**Prototype（プロトタイプ）パターン**は、  
既存のインスタンスをテンプレートとして、**同じ構造のオブジェクトをコピーして生成する手法**である。

インスタンス生成のコストが高い場合や、初期化の柔軟性が求められる場面で有効。  
**ファクトリパターンに似つつ、"コピーして生成"という思想に基づくのが特徴**。

---

## 1. なぜPrototypeが必要か？

### ❌ 毎回 new や __init__ で重い初期化を走らせる

```python
user1 = User(name="admin", role="root", settings=heavy_config)
user2 = User(name="admin", role="root", settings=heavy_config)
```

→ **同じ構成を複数用意するたびに非効率**

---

### ✅ 一度作成したプロトタイプをコピーして再利用

```python
template = User(...)
clone = template.clone()
```

→ **軽量な複製でインスタンス生成を効率化**

---

## 2. 基本構造

### ✅ Prototypeインターフェース

```python
import copy

class Prototype:
    def clone(self):
        return copy.deepcopy(self)
```

---

### ✅ 対象クラスの実装

```python
class User(Prototype):
    def __init__(self, name, role, settings):
        self.name = name
        self.role = role
        self.settings = settings

    def __str__(self):
        return f"User({self.name}, {self.role}, {self.settings})"
```

---

### ✅ 使用例

```python
default_settings = {"theme": "dark", "language": "jp"}
admin = User("admin", "root", default_settings)

admin_clone = admin.clone()
admin_clone.name = "clone_admin"

print(admin)        # User(admin, root, {'theme': 'dark', 'language': 'jp'})
print(admin_clone)  # User(clone_admin, root, {'theme': 'dark', 'language': 'jp'})
```

→ **構造も含めて完全に複製できる**

---

## 3. Python的応用：プロトタイプレジストリで汎用管理

```python
class PrototypeRegistry:
    def __init__(self):
        self._prototypes = {}

    def register(self, name, prototype):
        self._prototypes[name] = prototype

    def clone(self, name):
        return self._prototypes[name].clone()
```

```python
registry = PrototypeRegistry()
registry.register("admin", admin)

copy1 = registry.clone("admin")
copy2 = registry.clone("admin")
```

→ **プロトタイプを名前付きで登録・複製できる柔軟な設計**

---

## 4. 実務ユースケース

### ✅ テンプレートベースのフォーム・オブジェクト生成

→ **一度設定した構成を複製して使いまわす**

---

### ✅ 大量オブジェクトの初期状態量産（ゲーム・UI）

→ 敵キャラやボタンなど**同じ構造のインスタンスを高速に複製**

---

### ✅ 設定済みのインスタンスをベースに派生インスタンス作成

→ **初期値の違いをわずかに与えたクローンを量産可能**

---

### ✅ ファイル/DBから読み込んだ設定のクローンを使う

→ **一度読み込んだオブジェクトを動的にコピーして扱う**

---

## 5. よくある誤用と対策

### ❌ clone が浅いコピー（shallow copy）で不整合発生

→ ✅ **必ず deepcopy を使用し、参照共有を避ける**

---

### ❌ 複製後の属性変更がオリジナルに影響してしまう

→ ✅ **ミューテーションを伴うフィールドは必ず検証**

---

### ❌ clone ロジックがクラスごとにバラバラ

→ ✅ **共通の Prototype ベースクラスを導入して一貫性を保つ**

---

## 結語

**Prototypeパターンとは、“原型を鋳型として複製し、新たなオブジェクトを柔らかく生み出す設計”である。**

- 初期化コストの高いインスタンスを**効率よく再生成できる柔軟なアプローチ**  
- ファクトリでは表現しにくい“状態を含んだ生成”において**強力なパターン**  
- Pythonでは `deepcopy()` と柔軟なクラス定義により、**シンプルかつ効果的な実装が可能**

**Pythonicとは、“再利用と変化のバランスを、簡潔に保つこと”。  
Prototypeパターンはその柔軟性と効率を、複製という技法に込めている。**
Pythonで実装するMementoパターン：状態のスナップショットを安全に記録・復元する



## 概要

**Memento（メメント）パターン**は、  
あるオブジェクトの内部状態を**外部から安全に記録・復元できるようにする設計パターン**である。

特に**Undo/Redo機能**や、一時的な状態保持とロールバック処理に適しており、状態管理の柔軟性を構造化するのに役立つ。

---

## 1. なぜMementoが必要か？

### ❌ 状態をグローバル変数やdictなどでベタ保存

```python
backup = {
    "text": editor.text,
    "cursor": editor.cursor
}
```

→ **カプセル化を破壊し、変更に弱い構造**

---

### ✅ 状態をMementoとしてオブジェクト化・隠蔽して記録

```python
snapshot = editor.save()
...
editor.restore(snapshot)
```

→ **内部状態を安全に保持し、構造的に復元可能**

---

## 2. 基本構造

### ✅ Originator（状態を持つオブジェクト）

```python
class Editor:
    def __init__(self):
        self._text = ""
        self._cursor = 0

    def write(self, text):
        self._text += text
        self._cursor = len(self._text)

    def save(self):
        return Memento(self._text, self._cursor)

    def restore(self, memento):
        self._text = memento.text
        self._cursor = memento.cursor

    def show(self):
        print(f"[Editor] '{self._text}' | cursor at {self._cursor}")
```

---

### ✅ Memento（状態を保存するクラス）

```python
class Memento:
    def __init__(self, text, cursor):
        self.text = text
        self.cursor = cursor
```

---

### ✅ Caretaker（履歴管理者）

```python
class History:
    def __init__(self):
        self._snapshots = []

    def backup(self, memento):
        self._snapshots.append(memento)

    def undo(self):
        if self._snapshots:
            return self._snapshots.pop()
        return None
```

---

### ✅ 使用例

```python
editor = Editor()
history = History()

editor.write("Hello")
history.backup(editor.save())

editor.write(", World!")
editor.show()  # Hello, World!

editor.restore(history.undo())
editor.show()  # Hello
```

出力:
```
[Editor] 'Hello, World!' | cursor at 13
[Editor] 'Hello' | cursor at 5
```

---

## 3. Python的応用：Mementoをdeepcopyで代用する実用例

```python
import copy

history = []
editor = Editor()

editor.write("A")
history.append(copy.deepcopy(editor))

editor.write("B")
history.append(copy.deepcopy(editor))

editor = history[-2]
editor.show()  # A
```

→ **小規模アプリなら deepcopy によるスナップショットでも有効**

---

## 4. 実務ユースケース

### ✅ Undo/Redo 機能の実装（エディタ、フォーム、設定画面）

→ 操作の履歴を**構造化された状態で保持し、任意のタイミングで戻す**

---

### ✅ 安全なロールバック処理（DB/設定変更/ユーザー操作）

→ 設定前の状態を保持しておき、**異常時に復元可能**

---

### ✅ オブジェクトの一時的スナップショット保存

→ **テストや一時保存、比較検証などに活用**

---

### ✅ タイムトラベル型UIの実装

→ アプリケーションの状態遷移を**時間軸で記録・再生**

---

## 5. よくある誤用と対策

### ❌ Mementoが内部構造を公開してしまう

→ ✅ **読み取り専用属性とし、直接操作を避ける**

---

### ❌ 状態復元の副作用が大きすぎる

→ ✅ **復元時の処理が明確に定義されていることを保証**

---

### ❌ 履歴管理（Caretaker）が肥大化・不整合

→ ✅ **履歴の最大数、メモリ制限、整合性検証を事前に設計**

---

## 結語

**Mementoパターンとは、“過去の状態を密やかに封じ込め、未来の柔軟性を担保する設計”である。**

- オブジェクトの内部状態を**安全・構造的に保存・復元可能**  
- Undo/Redo、ロールバック、履歴管理など、**時系列的状態制御の基盤を提供**  
- Pythonではクラスの柔軟性と動的属性によって、**直感的かつ安全にMementoが構築可能**

**Pythonicとは、“状態の変化を設計的に制御すること”。  
Mementoパターンはその制御を、スナップショットという静かな記憶に委ねる技法である。**
Pythonで実装するVisitorパターン：処理とデータ構造の分離を美しく保つ



## 概要

**Visitor（ビジター）パターン**は、  
データ構造（要素）と、それに対する処理（アルゴリズム）を分離し、**新しい処理を追加する際に構造を変更せずに済む設計**を実現するパターンである。

構文木の探索や、異なる型のノードに対して異なる処理を適用する際に特に有効。  
**OOPにおけるダブルディスパッチの概念に基づく設計**。

---

## 1. なぜVisitorが必要か？

### ❌ 要素クラスが処理を内包しすぎて、追加変更が困難になる

```python
class Node:
    def evaluate(self): ...
    def render(self): ...
    def export(self): ...
```

→ 処理が増えるたびに**データ構造に手を加える必要が生じる**

---

### ✅ 処理をVisitorとして外部化することで柔軟に拡張

```python
node.accept(Evaluator())
node.accept(Renderer())
node.accept(Exporter())
```

→ **構造は固定、処理だけを独立に追加可能**

---

## 2. 基本構造

### ✅ Element（訪問される側）

```python
class Node:
    def accept(self, visitor):
        raise NotImplementedError
```

---

### ✅ Concrete Elements

```python
class NumberNode(Node):
    def __init__(self, value):
        self.value = value

    def accept(self, visitor):
        return visitor.visit_number(self)

class AddNode(Node):
    def __init__(self, left, right):
        self.left = left
        self.right = right

    def accept(self, visitor):
        return visitor.visit_add(self)
```

---

### ✅ Visitor（訪問者インターフェース）

```python
class Visitor:
    def visit_number(self, node):
        raise NotImplementedError

    def visit_add(self, node):
        raise NotImplementedError
```

---

### ✅ Concrete Visitor（処理の実体）

```python
class Evaluator(Visitor):
    def visit_number(self, node):
        return node.value

    def visit_add(self, node):
        return node.left.accept(self) + node.right.accept(self)
```

---

### ✅ 使用例

```python
# 3 + 7
tree = AddNode(NumberNode(3), NumberNode(7))
result = tree.accept(Evaluator())
print(result)  # → 10
```

---

## 3. Python的応用：関数ディスパッチを使ったシンプルなVisitor風設計

```python
def visit(node):
    if isinstance(node, NumberNode):
        return node.value
    elif isinstance(node, AddNode):
        return visit(node.left) + visit(node.right)
```

→ **小規模なら関数ベースで簡潔にVisitorのような振る舞いを表現可能**

---

## 4. 実務ユースケース

### ✅ 抽象構文木（AST）の走査と評価

→ コンパイラ、インタプリタにおける**コード解析・評価・変換**

---

### ✅ データツリーのシリアライズ（JSON/XML/HTML）

→ 要素構造を保持しながら**出力形式だけを柔軟に切り替え**

---

### ✅ バリデーションやリント処理の注入

→ 各要素への**検査ロジックをVisitorとして独立管理**

---

### ✅ グラフィカルUIコンポーネントへの操作適用

→ コンポーネントツリー全体に**共通操作（例：再描画・更新）を適用**

---

## 5. よくある誤用と対策

### ❌ Visitorクラスが肥大化しがち

→ ✅ **用途別に複数のVisitorへ分割し、単一責任を守る**

---

### ❌ accept メソッドの切り分けが曖昧

→ ✅ **ノードタイプごとに訪問メソッドを明示的に定義**

---

### ❌ Visitorの種類を動的に追加できない設計

→ ✅ **動的ディスパッチや関数型設計を併用して柔軟性を補完**

---

## 結語

**Visitorパターンとは、“構造はそのまま、振る舞いだけを外から静かに訪れる設計”である。**

- データ構造と処理を分離することで、**拡張性と保守性を飛躍的に向上**  
- 処理の差し替え・追加が構造に影響せず、**システムの安定性を高める**  
- Pythonでは動的なディスパッチやOOPの柔軟性を活かして、**実用的かつ読みやすいVisitorの実装が可能**

**Pythonicとは、“データと処理の独立性を保ち、変化に備えること”。  
Visitorパターンはその独立性を、訪問という優雅な構造に昇華した技法である。**
Pythonで実装するState Machineの設計原則と実装パターン



## 概要

**State Machine（状態機械）**は、  
あるオブジェクトが**明確な状態とその遷移ルールを持ち、入力に応じて振る舞いを変化させる構造設計パターン**である。

この構造は UI、ゲーム、プロセス制御、通信プロトコル、ワークフローなど、**状態依存ロジックが必要なあらゆる場面に登場する**。

---

## 1. なぜState Machineが必要か？

### ❌ 条件分岐で状態を管理するとコードが崩壊する

```python
if status == "login":
    ...
elif status == "confirm":
    ...
elif status == "completed":
    ...
```

→ 状態が増えるたびに**分岐地獄とロジックの重複が発生**

---

### ✅ 状態ごとに専用のクラスを定義し、責任を分離する

```python
state = LoginState()
state.handle(user_context)
```

→ **状態ごとの責務を明確化し、拡張・保守が容易に**

---

## 2. 基本構造

### ✅ Stateインターフェース

```python
class State:
    def handle(self, context):
        raise NotImplementedError
```

---

### ✅ Context（状態を管理する主体）

```python
class UserContext:
    def __init__(self):
        self.state = LoginState()

    def set_state(self, state):
        self.state = state

    def request(self):
        self.state.handle(self)
```

---

### ✅ 各Stateの具象クラス

```python
class LoginState(State):
    def handle(self, context):
        print("ログイン状態：確認画面へ遷移")
        context.set_state(ConfirmState())

class ConfirmState(State):
    def handle(self, context):
        print("確認状態：完了画面へ遷移")
        context.set_state(CompletedState())

class CompletedState(State):
    def handle(self, context):
        print("完了状態：処理終了")
```

---

### ✅ 使用例

```python
user = UserContext()
user.request()  # ログイン状態
user.request()  # 確認状態
user.request()  # 完了状態
```

出力:
```
ログイン状態：確認画面へ遷移
確認状態：完了画面へ遷移
完了状態：処理終了
```

---

## 3. Python的応用：辞書による簡易ステートマシン

```python
transitions = {
    "login": ("confirm", lambda: print("→ 確認へ")),
    "confirm": ("done", lambda: print("→ 完了へ")),
    "done": (None, lambda: print("→ 終了"))
}

state = "login"
while state:
    next_state, action = transitions[state]
    action()
    state = next_state
```

→ **状態と遷移をデータとして定義することで柔軟に再利用可能**

---

## 4. 実務ユースケース

### ✅ ユーザー登録フロー、購入ステップの制御

→ 各画面・段階の**状態と遷移を厳密に設計**

---

### ✅ ゲームやアニメーションのステート管理

→ キャラクターの行動状態を**「待機」「移動」「攻撃」などで管理**

---

### ✅ プロトコル通信ステータスの管理

→ クライアントの接続・認証・送受信・切断などを**状態として設計**

---

### ✅ フィニットステートマシンを使ったDSLパーサ

→ 入力文字列に応じて**状態を遷移しながら構文解析**

---

## 5. よくある誤用と対策

### ❌ 状態が増えるたびにif-elseが肥大化

→ ✅ **状態ごとのクラスまたは辞書ベースの遷移表で制御**

---

### ❌ 状態オブジェクトにビジネスロジックを混在

→ ✅ **Stateクラスは状態遷移の責務のみに集中**

---

### ❌ Contextクラスが状態に過度に依存する実装

→ ✅ **状態が自己完結的に責務を持ち、Contextに最小限の影響だけ与える**

---

## 結語

**State Machineとは、“状態と振る舞いを明確に分離し、制御の流れを構造化する設計技法”である。**

- 状態依存ロジックを**可読性と拡張性を維持したまま記述可能に**  
- 状態と遷移を独立管理することで、**高い保守性と変更耐性を確保**  
- PythonではOOPとデータ駆動を併用し、**柔軟かつ直感的なステートマシンが構築可能**

**Pythonicとは、“複雑さを管理し、変化を秩序に落とし込むこと”。  
State Machineはその秩序の設計を、状態というレンズでシンプルに見通すための技法である。**
...（スプレッド構文）って何？

TypeScriptの勉強をしていた時に出てきた謎の...について調べたのでまとめる。

## MDNドキュメントには
下記のように書かれていた。
> スプレッド (...) 構文を使うと、配列式や文字列などの反復可能オブジェクトを、0 個以上の引数（関数呼び出しの場合）や要素（配列リテラルの場合）を目的の場所に展開することができます。オブジェクトリテラルでは、スプレッド構文によりオブジェクトのプロパティを列挙し、作成するオブジェクトにキーと値の組を追加します。  

## 簡単に言うと
... は「配列やオブジェクトの中身を展開する」特殊な構文。

## 実際に使ってみた
#### 配列
配列の場合は下記のように使える。
```ts
const a = [1, 2, 3];
const b = [...a, 4]; // → [1, 2, 3, 4]
```
...a で [1, 2, 3] の中身を展開して新しい配列にする  
b は [1, 2, 3, 4] になる。

#### オブジェクト
オブジェクトだと下記。
```ts
const user = { name: "たろう", age: 20 };
const updated = { ...user, age: 21 };
```
...user でオブジェクトの中身を丸々コピー。
age: 21 で上書き。
updated → { name: "たろう", age: 21 }

#### まとめ
|　書き方　|　意味　|
| ---- | ---- |
| [...array] 　| 配列のコピーを作る |
| [newItem, ...array] 　| 配列の先頭に要素追加 |
| [...array, newItem] 　| 配列の末尾に要素追加 |
| {...object} 　| オブジェクトのコピー |
| {...obj, key: val} 　| 一部を上書きした新オブジェクト|

## よくある用途
ChatGPTによくある用途を聞いたところ下記が出てきた。
* useState での状態更新
* props のコピーや合体
* オブジェクトのマージ
* イミュータブルな変更（元を直接変えない）

## 使用上の注意点
スプレッド構文は「浅いコピー」なので、ネストが深いと仲間ではコピーされない。
「浅いコピー」とは __オブジェクトの一番上の階層だけ__ をコピーすること。

実際にソースコードで書いてみたところ、下記のように意図しない状態になった。
```ts
const original = {
  name: "Taro",
  info: {
    age: 20,
    city: "Tokyo"
  }
};

const copy = { ...original };
copy.info.city = "Osaka";
console.log(original.info.city); // → "Osaka" に変わった...
```
Pythonで実装するBuilderパターン：段階的な生成で複雑なオブジェクトを構築する



## 概要

**Builder（ビルダー）パターン**は、  
複雑な構造を持つオブジェクトの生成処理を、**段階的かつ分離された構造で提供する**デザインパターンである。

生成処理を構成要素ごとに分け、**読みやすく保守性の高いAPIで組み立てられるようにする**のが目的。  
オブジェクトの生成順序、依存性、初期状態を**コード上に明示的に表現できる**。

---

## 1. なぜBuilderが必要か？

### ❌ コンストラクタで引数が増えすぎて可読性が低下

```python
user = User("taro", 30, "tokyo", "engineer", "developer", True, False)
```

→ 引数の意味が不明、可読性とメンテナンス性に問題がある

---

### ✅ Builderを使って意図を明示しながら構築

```python
user = (
    UserBuilder()
    .set_name("taro")
    .set_age(30)
    .set_location("tokyo")
    .set_job("engineer")
    .build()
)
```

→ **各ステップで意味が明確な、流れるようなオブジェクト生成が可能に**

---

## 2. 基本構造

### ✅ Product（構築対象のオブジェクト）

```python
class User:
    def __init__(self, name="", age=0, location="", job=""):
        self.name = name
        self.age = age
        self.location = location
        self.job = job

    def __str__(self):
        return f"{self.name} ({self.age}) - {self.location} / {self.job}"
```

---

### ✅ Builderクラス

```python
class UserBuilder:
    def __init__(self):
        self._user = User()

    def set_name(self, name):
        self._user.name = name
        return self

    def set_age(self, age):
        self._user.age = age
        return self

    def set_location(self, location):
        self._user.location = location
        return self

    def set_job(self, job):
        self._user.job = job
        return self

    def build(self):
        return self._user
```

---

### ✅ 使用例

```python
user = (
    UserBuilder()
    .set_name("Hanako")
    .set_age(28)
    .set_location("Osaka")
    .set_job("Designer")
    .build()
)

print(user)
```

出力:
```
Hanako (28) - Osaka / Designer
```

---

## 3. Python的応用：辞書やJSON構造を段階的に組み立てる

```python
class QueryBuilder:
    def __init__(self):
        self._query = {}

    def filter(self, key, value):
        self._query[key] = value
        return self

    def sort(self, field):
        self._query["sort"] = field
        return self

    def limit(self, n):
        self._query["limit"] = n
        return self

    def build(self):
        return self._query
```

```python
query = QueryBuilder().filter("status", "active").limit(10).build()
print(query)
```

出力:
```python
{'status': 'active', 'limit': 10}
```

---

## 4. 実務ユースケース

### ✅ 複雑なフォームデータの組み立て

→ **途中でバリデーションや補完を加えつつ段階的に構築**

---

### ✅ DSL的なクエリビルダー（SQL, GraphQL, MongoDB等）

→ **構文木を段階的に積み上げて安全に組み立てる**

---

### ✅ 大量設定を伴うUI部品の生成

→ **スタイル・レイアウト・イベントを一貫した構文で設定可能**

---

### ✅ テスト用のダミーデータファクトリ

→ 様々な属性を**柔軟に組み合わせたオブジェクト生成が可能**

---

## 5. よくある誤用と対策

### ❌ Builderで生成するオブジェクトの責務が曖昧

→ ✅ **Builderは構築専用、ロジックはProductに持たせる**

---

### ❌ ステップが固定されており順序変更できない

→ ✅ **ステップは任意順・任意数で実行可能に設計する**

---

### ❌ build() でバリデーションせずに不完全なオブジェクトを返す

→ ✅ **最終段階で一貫性チェックを挟む**

---

## 結語

**Builderパターンとは、“設計図をもとに、順を追って構造を組み立てる柔らかな生成技法”である。**

- 大量の属性や依存性を持つオブジェクトを、**段階的かつ明示的に構築**  
- 引数の羅列による曖昧さを避け、**可読性・拡張性・保守性を向上**  
- Pythonではメソッドチェーンやデフォルト引数を駆使し、**洗練されたDSLのような生成コードを記述可能**

**Pythonicとは、“わかりやすく、流れるように意図を示す構造を持つこと”。  
Builderパターンはその意図と構築の過程を、コードに優雅に刻む設計技法である。**
Pythonで実装するFacadeパターン：複雑な処理を単純な窓口で隠蔽する



## 概要

**Facade（ファサード）パターン**は、  
複雑に絡み合った処理群を背後に隠蔽し、**簡素で統一された窓口（インターフェース）を提供する構造的パターン**である。

ユーザーやクライアントコードは、背後の構成要素を意識せず、**必要な操作だけを一貫した形で利用可能**になる。

---

## 1. なぜFacadeが必要か？

### ❌ クライアントが内部の構成要素すべてを知る必要がある

```python
cpu.start()
memory.load()
disk.read()
```

→ 呼び出し手が**処理順・依存関係・初期化などを全て把握しなければならない**

---

### ✅ 単一の窓口から必要な操作だけを行えるように抽象化

```python
computer.start()
```

→ **内部の詳細はFacadeが吸収し、利用者は高レベルなAPIを扱うだけ**

---

## 2. 基本構造

### ✅ サブシステム（複雑な部品群）

```python
class CPU:
    def start(self):
        print("CPU: 起動")

class Memory:
    def load(self):
        print("Memory: ロード")

class Disk:
    def read(self):
        print("Disk: 読み込み")
```

---

### ✅ Facade（簡潔な窓口）

```python
class Computer:
    def __init__(self):
        self.cpu = CPU()
        self.memory = Memory()
        self.disk = Disk()

    def start(self):
        print("=== システム起動 ===")
        self.cpu.start()
        self.memory.load()
        self.disk.read()
        print("=== 起動完了 ===")
```

---

### ✅ 使用例

```python
pc = Computer()
pc.start()
```

出力:
```
=== システム起動 ===
CPU: 起動
Memory: ロード
Disk: 読み込み
=== 起動完了 ===
```

---

## 3. Python的応用：Facadeをサービスモジュールとして提供する

```python
class AuthService:
    def login(self, user, password):
        print(f"[認証] {user} ログイン成功")

class PaymentService:
    def charge(self, user, amount):
        print(f"[課金] {user} に {amount} 円請求")

class AppService:
    def __init__(self):
        self.auth = AuthService()
        self.payment = PaymentService()

    def purchase(self, user, password, amount):
        self.auth.login(user, password)
        self.payment.charge(user, amount)
```

```python
service = AppService()
service.purchase("taro", "secure123", 500)
```

→ **ドメインロジックに依存せず、ユーザー視点の窓口を提供可能**

---

## 4. 実務ユースケース

### ✅ 外部ライブラリやフレームワークのラッピング

→ 利用者には**一貫したAPI**を提供し、内部の複雑さを隠す

---

### ✅ 複数サービス・サブシステムの統合操作

→ 認証→バリデーション→DB登録→通知といった**一連のフローを集約**

---

### ✅ CLI/GUI/RESTなどUI層とロジック層の切り離し

→ ユーザーインターフェースから見える**シンプルな入り口**

---

### ✅ SDKとしての公開API設計

→ **制限された安全な機能群をファサードとして提供**

---

## 5. よくある誤用と対策

### ❌ Facadeが過剰に肥大化し、すべての処理を飲み込む

→ ✅ **機能単位に複数のFacadeに分割して構成する**

---

### ❌ Facadeが単なるメソッドチェーンのラッパーになる

→ ✅ **内部の呼び出し順・依存性の制御も担う責任を持たせる**

---

### ❌ 背後の構成要素がFacadeに依存してしまう

→ ✅ **依存は一方向。Facadeが各部品を知っていても、その逆はない**

---

## 結語

**Facadeパターンとは、“複雑な仕組みの奥にある静かな入り口”を提供する設計である。**

- 背後の多層処理を吸収し、**ユーザーにとって最も自然な単純さを提供**  
- 外部との接点を整備することで、**システム全体の安全性と可読性を向上**  
- Pythonではモジュール・サービス・ユーティリティの設計において、**Facadeはアーキテクチャの要となる**

**Pythonicとは、“複雑さを包み隠し、シンプルで直感的にすること”。  
Facadeパターンはその配慮と設計の美を、インターフェースとして表現する技法である。**
Goのtime.Time型をGomockで扱ってたらハマった話

初めての技術記事書いてみます。
最近Goを業務で書き始めた初心者なので、あたたかく見守ってください。

## 状況

GoMockを使ったテストコードを書いてると、以下のようなGomockのエラーに遭遇しました。

```
sample.go:17: Unexpected call to *mock_sample.MockSample.Process([2025-04-08 00:00:00 +0900 JST]) at sample/sample.go:17 because:
    expected call at C:/Users/fuuta/Documents/home/program/study-go/app/sample/sample_test.go:34 doesn't match the argument at index 0.
    Got: 2025-04-08 00:00:00 +0900 JST (time.Time)
    Want: is equal to 2025-04-08 00:00:00 +0900 JST (time.Time)
```

抜粋してみると完全に一致していることがわかります。
```
Got: 2025-04-08 00:00:00 +0900 JST (time.Time)
Want: is equal to 2025-04-08 00:00:00 +0900 JST (time.Time)
```

## 原因

「何が違うねん！？」と最初思いましたが、どうやらTime型のフィールドの一つであるLocationが異なるようでした。
今回の例においては `Local` と `Asia/Tokyo` とで二つのLocation構造体があり、Got側とwant側で日時は同じだが異なるLocationを持ったTime構造体の比較を行っていたのが原因でした。

テスト落ちの出力で `JST` 表記になっている原因は、LocationにLocalが指定されていると日本にいる場合は `JST` と出る仕組みなんだろうと推測してます。

最後に簡単な検証用ソースを添付しておきます。

```go:sample_test.go
package sample

import (
	"fmt"
	"test/mock_sample"
	"testing"
	"time"

	"github.com/golang/mock/gomock"
	"github.com/stretchr/testify/assert"
)

// gomock使った検証用
func Test1(t *testing.T) {
	location, _ := time.LoadLocation("Local")

	layout := "2006-01-02 15:04:05"
	value := "2025-04-08 00:00:00"

	time1, _ := time.ParseInLocation(layout, value, location)

	ctrl := gomock.NewController(t)
	defer ctrl.Finish()

	m := mock_sample.NewMockSample(ctrl)

	m.EXPECT().Process(time1)

	Process(m)
}

// gomock使わない検証用
func Test2(t *testing.T) {
	locationLocal, _ := time.LoadLocation("Local")
	locationJST, _ := time.LoadLocation("Asia/Tokyo")

	layout := "2006-01-02 15:04:05"
	value := "2025-04-08 00:00:00"

	time1, _ := time.ParseInLocation(layout, value, locationLocal)
	time2, _ := time.ParseInLocation(layout, value, locationJST)

	t.Logf("%v\n", time1)
	t.Logf("%v\n", time2)
	t.Logf("%v\n", time1 == time2)
	t.Logf("%v\n", time1.Equal(time2))
	t.Logf("%v\n", fmt.Sprintf("%v (%T)", time1, time1))
	t.Logf("%v\n", fmt.Sprintf("%v (%T)", time2, time2))

	assert.Equal(t, time1, time2)
    // expected: time.Date(2025, time.April, 8, 0, 0, 0, 0, time.Local)
    // actual  : time.Date(2025, time.April, 8, 0, 0, 0, 0, time.Location("Asia/Tokyo"))
}

```

```go:sample.go
package sample

import "time"

type Sample interface {
	Process(time time.Time)
}

func Process(sample Sample) {
	location, _ := time.LoadLocation("Asia/Tokyo")

	layout := "2006-01-02 15:04:05"
	value := "2025-04-08 00:00:00"

	time, _ := time.ParseInLocation(layout, value, location)

	sample.Process(time)
}

```

`Test2` の方を見ると分かりますが、 `testify/assert` の `assert.Equal` を使うとTime型も構造体としてフィールド単位で出力してくれるので違いが明確にわかります。
 `Gomock` は"%v"で出力する実装となっており、この場合Time型固有のフォーマットで出力されます。普段は見やすいものの今回はそれが裏目に出た形ですね。

## まとめ

どの言語も日付周りは厄介ですね。。。

## 参考

- [[golang] time.ParseInLocation を用いたタイムゾーン付き文字列の解析時の注意点](https://medium.com/@goro.yanagi/golang-time-parseinlocation-%E3%82%92%E7%94%A8%E3%81%84%E3%81%9F%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%BE%E3%83%BC%E3%83%B3%E4%BB%98%E3%81%8D%E6%96%87%E5%AD%97%E5%88%97%E3%81%AE%E8%A7%A3%E6%9E%90%E6%99%82%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9-b6b7cfc0d662)
Pythonで実装するAdapterパターン：インターフェースの不一致をスマートに接続する



## 概要

**Adapter（アダプター）パターン**は、  
本来互換性のないインターフェース同士を、**ラッパー（Adapter）を介して接続可能にする構造的パターン**である。

異なるライブラリ・API・クラスを統一的に扱いたいときに、**既存コードを変更せずに一貫した使用方法を提供できる**のが特徴。

---

## 1. なぜAdapterが必要か？

### ❌ API仕様の違いを都度対応して使い分ける構造

```python
a.read_csv()
b.load_from_csv()
```

→ 呼び出し元に**多くの条件分岐や仕様知識が必要になる**

---

### ✅ アダプターを使って統一的なインターフェースに変換

```python
reader = CSVReaderAdapter(b)
reader.read()
```

→ **呼び出し元は一貫したメソッドで異なるクラスを扱える**

---

## 2. 基本構造

### ✅ Target（期待されるインターフェース）

```python
class Reader:
    def read(self):
        raise NotImplementedError
```

---

### ✅ Adaptee（既存の異なるインターフェース）

```python
class LegacyCSV:
    def load_from_csv(self):
        print("Loading CSV using legacy method.")
```

---

### ✅ Adapter（インターフェース変換）

```python
class CSVReaderAdapter(Reader):
    def __init__(self, legacy_csv: LegacyCSV):
        self._legacy_csv = legacy_csv

    def read(self):
        self._legacy_csv.load_from_csv()
```

---

### ✅ 使用例

```python
legacy = LegacyCSV()
adapter = CSVReaderAdapter(legacy)
adapter.read()
```

出力:
```
Loading CSV using legacy method.
```

---

## 3. Python的応用：Duck Typingで柔軟なAdapter実装

```python
class JSONLoader:
    def load_json(self):
        return {"data": "value"}

class JSONAdapter:
    def __init__(self, adaptee):
        self._adaptee = adaptee

    def read(self):
        return self._adaptee.load_json()
```

→ **インターフェースに厳密に準拠せずとも、read() さえ提供すれば動く構造**

---

## 4. 実務ユースケース

### ✅ 複数ライブラリ間のAPIインターフェース統一

→ 仕様の異なるクラス群を**一つの呼び出しインターフェースに変換**

---

### ✅ レガシーシステムと新システムの接続

→ 古いクラス群を**新仕様に適応させるブリッジとして活用**

---

### ✅ ユニットテスト用のモック・スタブ生成

→ テスト対象と同じインターフェースを持つ**テストダブルの注入**

---

### ✅ 外部APIクライアントの抽象化

→ バージョンや仕様変更に対応するための**アダプター層の挿入**

---

## 5. よくある誤用と対策

### ❌ Adapteeを変更してしまう

→ ✅ **Adapterの意義は「既存コードを一切変更しない」ことにある**

---

### ❌ アダプターが多すぎて構造が煩雑に

→ ✅ **同じパターンを繰り返す場合はファクトリ or メタクラスで集約**

---

### ❌ 使用者がAdapterを意識しすぎる実装

→ ✅ **使用側は「一貫したインターフェース」だけに依存する構造に**

---

## 結語

**Adapterパターンとは、“異なる世界を接続する通訳者”のような存在である。**

- インターフェースの不一致を**ラッパーとして包み込み、互換性を提供**  
- 既存クラスを変更せず、**新しい文脈でも自然に利用可能にする**  
- Pythonでは型より動作（Duck Typing）を重視することで、**非常に柔軟にAdapterを設計可能**

**Pythonicとは、“差異を包み、統一の中に調和を築く”こと。  
Adapterパターンはその融合を、コードの層で静かに実現する技法である。**
Pythonで実装するDecoratorパターン：機能の動的付与をシンプルに構築する



## 概要

**Decorator（デコレータ）パターン**は、  
あるオブジェクトや処理に対して、**元のコードを変更せずに機能を動的に追加する**ための構造的デザインパターンである。

Pythonにおける関数・クラスのラップ構造と極めて相性が良く、  
**ログ出力、認証、キャッシュ、再試行処理などの横断的関心事をシンプルに構築可能**となる。

---

## 1. なぜDecoratorが必要か？

### ❌ 機能を拡張するたびに元の関数やクラスを変更する

```python
def process():
    log()
    auth()
    core()
    cleanup()
```

→ 各処理が混在して**本質的な処理が埋もれてしまう**

---

### ✅ 中核の処理を保ったまま、外側から機能を被せる

```python
@logged
@authenticated
def process():
    core()
```

→ **主処理を美しく保ちながら、機能の追加・変更・差し替えが容易に**

---

## 2. 基本構造（関数デコレータ）

### ✅ デコレータ関数の定義

```python
def logged(func):
    def wrapper(*args, **kwargs):
        print(f"[LOG] Calling {func.__name__}")
        result = func(*args, **kwargs)
        print(f"[LOG] {func.__name__} finished")
        return result
    return wrapper
```

---

### ✅ デコレータの使用

```python
@logged
def greet(name):
    print(f"Hello, {name}!")

greet("Alice")
```

出力:
```
[LOG] Calling greet
Hello, Alice!
[LOG] greet finished
```

---

## 3. Python的応用：複数デコレータの組み合わせ

```python
def authenticated(func):
    def wrapper(*args, **kwargs):
        print("[AUTH] User authenticated")
        return func(*args, **kwargs)
    return wrapper

@logged
@authenticated
def process_data():
    print("Processing data...")

process_data()
```

→ **ログイン・認証・バリデーションなどを段階的にラップできる**

---

## 4. クラスに対するDecoratorパターン

### ✅ 抽象DecoratorとConcreteDecoratorによる構造的拡張

```python
class Coffee:
    def cost(self):
        return 300

class MilkDecorator:
    def __init__(self, coffee):
        self._coffee = coffee

    def cost(self):
        return self._coffee.cost() + 50

class SugarDecorator:
    def __init__(self, coffee):
        self._coffee = coffee

    def cost(self):
        return self._coffee.cost() + 30
```

```python
coffee = Coffee()
coffee_with_milk = MilkDecorator(coffee)
coffee_full = SugarDecorator(coffee_with_milk)

print(coffee_full.cost())  # 380
```

→ **装飾の順序で挙動を制御し、柔軟な構成が可能**

---

## 5. 実務ユースケース

### ✅ APIのレスポンスキャッシュ処理

→ デコレータで**戻り値をメモ化して再計算を回避**

---

### ✅ 再試行（retry）処理

→ 例外発生時に**自動的に再実行するデコレータを実装**

---

### ✅ タイミング計測・ベンチマーク

→ 実行時間を**自動的に記録・可視化**

---

### ✅ DjangoやFlaskでのビュー関数修飾

→ ログイン制御、認可、CSRF保護など**クロスカット処理を集約**

---

## 6. よくある誤用と対策

### ❌ デコレータ内部で副作用を起こす

→ ✅ **関心の分離を守り、副作用は明示的に設計**

---

### ❌ functools.wraps を忘れて関数のメタ情報が失われる

→ ✅ デコレータ定義時に明示的に付加

```python
from functools import wraps

def logged(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        ...
    return wrapper
```

---

### ❌ 複雑なネストでデバッグ困難に

→ ✅ **単機能ごとに分離し、テスト可能なデコレータを意識**

---

## 結語

**Decoratorパターンとは、“本体に触れず、機能を柔らかく重ねる洗練された設計”である。**

- 関数やオブジェクトの責務を保ったまま、**追加機能を柔軟に注入可能**  
- Pythonでは構文レベルでサポートされており、**可読性・再利用性・分離性に優れた実装が可能**  
- 横断的関心（ログ、認証、キャッシュ、検証）を**コードの外側で美しく制御する力**

**Pythonicとは、“本質を保ちつつ、変化を受け入れる柔軟さ”。  
Decoratorパターンはその柔らかな変化を、明示的かつエレガントに実現する技法である。**
Pythonで実装するStrategyパターン：アルゴリズムの切り替えを動的に実現する



## 概要

**Strategy（ストラテジー）パターン**は、  
ある処理の具体的なアルゴリズムをクラスとして切り出し、**実行時に動的に選択・切り替え可能な構造を提供する**パターンである。

アルゴリズムが複数存在する場合でも、**分岐や条件に依存せず、疎結合かつ柔軟に設計できる**。

---

## 1. なぜStrategyが必要か？

### ❌ アルゴリズムの分岐がコード中にべた書きされる

```python
if method == "bubble":
    sort_bubble(data)
elif method == "quick":
    sort_quick(data)
```

→ アルゴリズム追加のたびに**条件分岐が肥大化し、保守性が低下**

---

### ✅ アルゴリズムをクラス化し、戦略として注入

```python
context = SortContext(QuickSortStrategy())
context.sort(data)
```

→ **選択と実行を分離し、柔軟な戦略切り替えを実現**

---

## 2. 基本構造

### ✅ Strategyインターフェース

```python
class SortStrategy:
    def sort(self, data):
        raise NotImplementedError
```

---

### ✅ ConcreteStrategy（具体的アルゴリズム）

```python
class BubbleSortStrategy(SortStrategy):
    def sort(self, data):
        print("バブルソート実行")
        return sorted(data)  # 実装省略（例）

class QuickSortStrategy(SortStrategy):
    def sort(self, data):
        print("クイックソート実行")
        return sorted(data)  # 実装省略（例）
```

---

### ✅ Context（アルゴリズムの使用者）

```python
class SortContext:
    def __init__(self, strategy: SortStrategy):
        self._strategy = strategy

    def set_strategy(self, strategy: SortStrategy):
        self._strategy = strategy

    def sort(self, data):
        return self._strategy.sort(data)
```

---

### ✅ 使用例

```python
data = [5, 3, 8, 2]

context = SortContext(BubbleSortStrategy())
context.sort(data)

context.set_strategy(QuickSortStrategy())
context.sort(data)
```

出力:
```
バブルソート実行
クイックソート実行
```

---

## 3. Python的応用：関数を戦略として扱う

```python
class SortContext:
    def __init__(self, strategy_func):
        self._strategy = strategy_func

    def set_strategy(self, strategy_func):
        self._strategy = strategy_func

    def sort(self, data):
        return self._strategy(data)

def merge_sort(data):
    print("マージソート実行")
    return sorted(data)

context = SortContext(merge_sort)
context.sort([9, 1, 4])
```

→ **関数やラムダ式をそのまま戦略として注入可能**

---

## 4. 実務ユースケース

### ✅ ソートアルゴリズム・暗号化方式・圧縮方式などの切り替え

→ 各戦略を**モジュール化して選択可能に**

---

### ✅ 支払い戦略（クレジット/PayPay/現金）などの決済処理

→ UIや状況に応じて**戦略的に実装切り替え**

---

### ✅ ログ出力形式（テキスト/JSON/構造化ログ）

→ フォーマッターを**切り替えて再利用**

---

### ✅ 検索エンジンでのマッチング戦略（完全一致/部分一致/あいまい）

→ **ユーザーの意図に応じてアルゴリズムを切り替え可能に**

---

## 5. よくある誤用と対策

### ❌ コンテキストクラスにロジックを持たせすぎる

→ ✅ **処理はすべてStrategy側に委譲し、Contextは切り替えだけを担う**

---

### ❌ Strategyが実質的に共通コードを大量に持つ

→ ✅ **共通処理はBaseStrategyにまとめる or Mixin設計で分離**

---

### ❌ Strategyを使うほどの選択肢がない場面での濫用

→ ✅ **明確に切り替える必要がある処理にのみ適用する**

---

## 結語

**Strategyパターンとは、“振る舞いをアルゴリズムとして独立させ、状況に応じて動的に切り替える柔軟な設計手法”である。**

- 条件分岐を排除し、**アルゴリズムの切り替えを構造で制御**  
- 動的な選択・組み替えを可能にし、**テスト・拡張・再利用性を向上**  
- Pythonでは関数やクラスを柔軟に戦略として扱え、**軽量かつ明快にStrategyを実装できる**

**Pythonicとは、“選択を構造として設計に取り込むこと”。  
Strategyパターンはその選択の自由を、アルゴリズムのレベルで美しく表現する構造技法である。**
Pythonで実装するCommandパターン：操作をオブジェクトとして抽象化する



## 概要

**Command（コマンド）パターン**は、  
処理内容（操作）をオブジェクトとして抽象化・独立させることで、**呼び出しと実行の分離・Undo/Redoの実装・操作の履歴管理**を可能にするデザインパターンである。

この構造により、**GUIボタン、キーボードショートカット、メニュー操作などの振る舞いを柔軟に管理可能**となる。

---

## 1. なぜCommandが必要か？

### ❌ 操作とUIイベントが直結している設計

```python
def on_button_click():
    editor.clear()
```

→ UIがロジックに強く依存しており、**再利用・拡張・テストが困難**

---

### ✅ 操作をオブジェクトとして切り出し、UIはその実行を委ねる

```python
clear_command = ClearCommand(editor)
clear_command.execute()
```

→ **操作はCommandオブジェクトとして独立し、複数のトリガーから再利用可能に**

---

## 2. 基本構造

### ✅ Commandインターフェース

```python
class Command:
    def execute(self):
        raise NotImplementedError

    def undo(self):
        raise NotImplementedError
```

---

### ✅ Receiver（実際に処理される対象）

```python
class Editor:
    def __init__(self):
        self.content = ""

    def write(self, text):
        self.content += text

    def clear(self):
        self.content = ""

    def show(self):
        print(f"[Editor] {self.content}")
```

---

### ✅ ConcreteCommand（具体的なコマンド）

```python
class ClearCommand(Command):
    def __init__(self, editor):
        self.editor = editor
        self._backup = ""

    def execute(self):
        self._backup = self.editor.content
        self.editor.clear()

    def undo(self):
        self.editor.content = self._backup
```

---

### ✅ Invoker（コマンドを管理・実行する役）

```python
class CommandInvoker:
    def __init__(self):
        self._history = []

    def run(self, command: Command):
        command.execute()
        self._history.append(command)

    def undo(self):
        if self._history:
            command = self._history.pop()
            command.undo()
```

---

### ✅ 使用例

```python
editor = Editor()
editor.write("Hello, World!")
editor.show()

invoker = CommandInvoker()
clear = ClearCommand(editor)

invoker.run(clear)
editor.show()

invoker.undo()
editor.show()
```

出力:
```
[Editor] Hello, World!
[Editor] 
[Editor] Hello, World!
```

---

## 3. Python的応用：Lambdaベースの簡易コマンド

```python
class LambdaCommand(Command):
    def __init__(self, execute_fn, undo_fn):
        self.execute_fn = execute_fn
        self.undo_fn = undo_fn

    def execute(self):
        self.execute_fn()

    def undo(self):
        self.undo_fn()
```

→ **小規模な一時的コマンドも柔軟に定義可能**

---

## 4. 実務ユースケース

### ✅ GUI操作（ボタン/メニュー/ショートカット）に対する処理の抽象化

→ **同一コマンドを複数UIイベントから呼び出せる**

---

### ✅ Undo/Redo 機能の実装

→ **各操作を履歴として蓄積し、逆操作を実行**

---

### ✅ マクロ記録・再生機能

→ コマンドの列を**記録・シリアライズ・再実行可能に**

---

### ✅ リモート実行（キューに蓄積→バッチ実行）

→ 操作内容を**オブジェクトとして安全に転送・保存**

---

## 5. よくある誤用と対策

### ❌ Commandオブジェクトが複雑な状態を持ちすぎる

→ ✅ **状態は最小限に、処理の委譲先はReceiverに限定する**

---

### ❌ 実行とUndoが非対称で整合性が取れない

→ ✅ **Undo可能な処理のみをCommand化するか、明示的に不可とする**

---

### ❌ Invokerが複雑なロジックを持つ

→ ✅ Invokerは**コマンドの管理と呼び出しだけに集中させる**

---

## 結語

**Commandパターンとは、“操作そのものをオブジェクトとして表現し、自由に扱えるようにする設計手法”である。**

- 操作のカプセル化により、**UIとロジックの疎結合化と再利用性の向上を実現**  
- Undo/Redo、バッチ処理、リモートコマンドなど、**構造化された操作の応用が可能に**  
- Pythonではファーストクラスオブジェクトとしての関数やラムダ式により、**軽量かつ柔軟にCommand設計が可能**

**Pythonicとは、“ふるまいもまたデータである”という原則に基づいて構造を抽象化すること。  
Commandパターンはその設計思想を、操作としてのコードに昇華させる技法である。**
Pythonで実装するMediatorパターン：オブジェクト間の複雑な通信を一元管理する



## 概要

**Mediator（メディエーター）パターン**は、  
多くのオブジェクト間の直接的な相互参照を排除し、**中央に仲介者を設けて通信や協調処理を管理する構造パターン**である。

この設計により、**クラス間の依存を低減し、柔軟かつ拡張性の高いシステム構築**が可能となる。

---

## 1. なぜMediatorが必要か？

### ❌ オブジェクト同士が直接参照し合う密結合構造

```python
class Button:
    def click(self):
        textbox.clear()
        label.hide()
```

→ 関係が増えるごとに**依存関係がスパゲッティ化**していく

---

### ✅ 中央にMediatorを設置し、全てのやりとりを集約

```python
button.click()  # → mediator.notify(button, "click")
```

→ **構成要素はMediatorの存在だけを知り、他のオブジェクトを直接参照しない**

---

## 2. 基本構造

### ✅ Mediator（共通インターフェース）

```python
class Mediator:
    def notify(self, sender, event):
        raise NotImplementedError
```

---

### ✅ ConcreteMediator（具体的な仲介者）

```python
class UIControlMediator(Mediator):
    def __init__(self):
        self.button = None
        self.textbox = None
        self.label = None

    def notify(self, sender, event):
        if sender == self.button and event == "click":
            print("ボタンがクリックされました。")
            self.textbox.clear()
            self.label.hide()
```

---

### ✅ Components（各コンポーネント）

```python
class Button:
    def __init__(self, mediator):
        self.mediator = mediator

    def click(self):
        self.mediator.notify(self, "click")

class TextBox:
    def __init__(self, mediator):
        self.mediator = mediator

    def clear(self):
        print("テキストボックスをクリアしました。")

class Label:
    def __init__(self, mediator):
        self.mediator = mediator

    def hide(self):
        print("ラベルを非表示にしました。")
```

---

### ✅ 使用例

```python
mediator = UIControlMediator()

button = Button(mediator)
textbox = TextBox(mediator)
label = Label(mediator)

mediator.button = button
mediator.textbox = textbox
mediator.label = label

button.click()
```

出力:
```
ボタンがクリックされました。
テキストボックスをクリアしました。
ラベルを非表示にしました。
```

---

## 3. Python的応用：イベントベースアーキテクチャへの適用

```python
class EventBus:
    def __init__(self):
        self._subscribers = {}

    def subscribe(self, event, handler):
        self._subscribers.setdefault(event, []).append(handler)

    def publish(self, event, payload=None):
        for handler in self._subscribers.get(event, []):
            handler(payload)
```

→ **Mediatorの拡張形として、疎結合なPub/Subモデルを表現可能**

---

## 4. 実務ユースケース

### ✅ GUIコンポーネント間の連動動作制御

→ **ボタン・入力欄・ラベルなどの状態変化を一元管理**

---

### ✅ チャットルームの中継ロジック

→ 各ユーザーが**中央のMediatorを介してメッセージを交換**

---

### ✅ IoTデバイスの状態連携制御

→ 各センサー・デバイスの状態を**中央のハブが制御・同期**

---

### ✅ マイクロサービス間の連携処理

→ サービス間の**調停者としてMediatorを配置し、サービス境界の明確化**

---

## 5. よくある誤用と対策

### ❌ Mediatorにロジックが集中しすぎて巨大化

→ ✅ **Mediatorは調停役に徹し、処理は各コンポーネントに委譲する**

---

### ❌ コンポーネントが他のオブジェクトを知ってしまう

→ ✅ **各コンポーネントはMediator以外に依存しない設計とする**

---

### ❌ イベントが不明確で通知が曖昧

→ ✅ **イベント名・型を明示的に設計し、仕様を可視化する**

---

## 結語

**Mediatorパターンとは、“混線を調停し、秩序ある通信の中心を設計する技法”である。**

- オブジェクト同士の密結合を避け、**一元的な調停者に委ねることで構造を洗練**  
- 構成要素の独立性を保ちつつ、**全体として統制されたふるまいを実現**  
- Pythonでは柔軟なクラス設計とイベント駆動型アーキテクチャとの相性も高く、**明確な責務分離が可能**

**Pythonicとは、“絡み合う責任をひとつの中心に集約して解きほぐす”こと。  
Mediatorパターンはその仲裁と統制を、構造として美しく表現する設計法である。**
Pythonで実装するPrototypeパターン：オブジェクトの複製による効率的生成



## 概要

**Prototype（プロトタイプ）パターン**は、  
クラスからではなく**既存のオブジェクトから複製（コピー）して新しいインスタンスを生成する**ことを目的としたデザインパターンである。

大量生成や設定が複雑なオブジェクトを扱う際に、**一からインスタンス化せずに、既存のひな形をコピーすることで効率的に生成できる**。

---

## 1. なぜPrototypeが必要か？

### ❌ 毎回インスタンスを新規構築

```python
hero = Character(name="Archer", level=1, skills=["bow", "hide"])
```

→ 毎回同じ属性を初期化するのは非効率。  
設定もれや記述の重複が**保守性とパフォーマンスに悪影響**

---

### ✅ プロトタイプからクローンを生成して簡略化

```python
new_hero = archer_prototype.clone()
```

→ **構造も状態もコピーされ、再構成の手間が不要に**

---

## 2. 基本構造

### ✅ Prototype（インターフェース）

```python
import copy

class Prototype:
    def clone(self):
        return copy.deepcopy(self)
```

---

### ✅ ConcretePrototype（複製可能な具体クラス）

```python
class Character(Prototype):
    def __init__(self, name, level, skills):
        self.name = name
        self.level = level
        self.skills = skills

    def __str__(self):
        return f"{self.name} (Lv:{self.level}) Skills: {', '.join(self.skills)}"
```

---

### ✅ 使用例

```python
archer = Character("Archer", 1, ["bow", "hide"])
mage = Character("Mage", 1, ["fire", "teleport"])

archer_clone = archer.clone()
mage_clone = mage.clone()

print(archer_clone)  # Archer (Lv:1) Skills: bow, hide
print(mage_clone)    # Mage (Lv:1) Skills: fire, teleport
```

→ **全ての構造がディープコピーされ、独立したインスタンスとして動作**

---

## 3. Python的応用：Prototype Factory

```python
class PrototypeFactory:
    def __init__(self):
        self._registry = {}

    def register(self, key, prototype):
        self._registry[key] = prototype

    def create(self, key):
        return self._registry[key].clone()
```

```python
factory = PrototypeFactory()
factory.register("warrior", Character("Warrior", 1, ["sword"]))
factory.register("healer", Character("Healer", 1, ["heal", "barrier"]))

unit1 = factory.create("warrior")
unit2 = factory.create("healer")

print(unit1)
print(unit2)
```

→ **プロトタイプの定義と複製の呼び出しを疎結合に設計可能**

---

## 4. 実務ユースケース

### ✅ ゲームにおけるユニットテンプレート生成

→ **パラメータの共通化と複製による高速生成**

---

### ✅ フロントエンドUIコンポーネントのクローン生成（例：ツールチップ、ボタン）

→ 同一スタイル・構造の**複製による効率的UI再利用**

---

### ✅ 初期状態が複雑なデータ構造のテンプレート化

→ オブジェクト生成処理を**1回に集約し、後はクローンで分配**

---

### ✅ ドキュメント・設定ファイルのインスタンス管理

→ プリセットとしての元データから**カスタム版を複製**

---

## 5. よくある誤用と対策

### ❌ `copy.copy()` と `copy.deepcopy()` の違いを無視

→ ✅ **参照を共有すべきでない場合は deepcopy を明示的に使用**

---

### ❌ 複製元がミュータブルな状態を持つ設計

→ ✅ プロトタイプはできるだけ**イミュータブル設計**に近づけ、予期しない変更を防止

---

### ❌ コンストラクタで副作用を起こしている

→ ✅ **副作用のある処理は clone 後に明示的に再実行する構造に**

---

## 結語

**Prototypeパターンとは、“既存の知性をコピーし、反復可能な創造性を与える”構造設計である。**

- 状態を持ったひな形を複製することで、**構築の高速化と設計の統一が可能に**  
- コンストラクションコストや記述冗長性を抑制し、**テンプレートベースのオブジェクト生成を柔軟に構成**  
- Pythonでは `copy.deepcopy` や `__dict__` 操作により、**非常にシンプルかつ強力なPrototype実装が実現可能**

**Pythonicとは、“再利用性と効率性を設計段階から取り入れる”こと。  
Prototypeパターンはその創造的複製を、合理的かつ構造的に表現する技法である。**