PoEAA ch18 Mapper

GoFPoEAAデザインパターン勉強メモ

出典: 


Mapper

An object that sets up a communication between two independent objects.

  • 2つのサブシステムをつなぐ
  • 疎結合に保ちたい

    • 変更できないから
    • 変更できるにしても、依存させたくないから
![20190519180433](../../../imgs/20190519180433.png)
Mapper

How It Works

  • サブシステムをつなぐ
  • コミュニケーションの詳細を制御する

    • 両サブシステムが意識しなくて良いように
  • shuffle
  • mapperをどうやって起動するか?

    • サブシステムからmapperを直接起動しては意味がない

      • サブシステムが何かに依存するのを避けるためのmapperなのだから
    • 第三のサブシステムを設けてmapper起動する
    • Observer Pattern取り入れる

      • サブシステム: Publisher
      • mapper: Observer
      • mapperはイベントをリッスンして起動する
  • mapperがどう動作するかは、マッピング対象の層の種類による

    • Data Mapperとか

When to Use It

  • システムの部品の結合をほぐす
  • MapperにするかGatewayにするか
![20190519180452](../../../imgs/20190519180452.png)
Gateway (Mapperとは依存の方向が異なる)
  • Gatewayのほうが、書くにも使うにもシンプル
  • サブシステム間で互いに依存がないことを保証する必要がある場合にのみMapper使え

    • 【補】片方向依存があってもいいならGateway
    • サブシステム間の相互作用がとりわけ複雑
    • それでいて、サブシステムの主要な目的には関係がない
  • 例えばどんなとき

    • Domain ModelとDBとのO/Rマッピング(Data Mapper)

      • データ変換は複雑
      • Domain ModelはDBのことは意識するべきではない
      • DBも誰に使われるか知っているべきではない
  • GoFのMediatorに似ている
  • 異なる点

    • Mediator Pattern: 各クラスはMediatorを知っている
    • Mapper Pattern: 各クラスはMapperを知らない
![20190519180510](../../../imgs/20190519180510.png)
GoFのMediator Pattern (双方向依存)