天気予報 API を Perl で呼ぶのは、1つなら簡単です。ところが2つ目を足した途端、レスポンスの形の違いで if 文が増えていきます。そこから、共通の窓口に揃える、複数の API をまとめて失敗時に次へ回す、キャッシュで呼び出しを減らす、全部落ちても止まらないようにする、と回を追って育てていきます。途中で使う設計に、GoF の Adapter と Facade という名前がつきます。
このページは目次を兼ねた案内板です。通して作るなら「全8回」を順に、特定の困りごとがあるなら「困りごとから探す」から選んでください。
読み方
- 通して読む: 第1回から順に。コードは前の回の続きで、各回の終わりに次回予告があります
- 設計パターンだけ知りたい: 第3回（Adapter）と第5回（Facade）です。第2回の破綻の例を先に読むと、なぜ必要かがつかめます
- 実務で使う部品だけ欲しい: 第6回のキャッシュと第7回の例外処理は、前の回のコードを読んでおくと流れがわかります
全8回
- Perl で外部の天気 API を呼びたい。HTTP::Tiny と JSON::PP で最初の1本を動かす
- 2つ目の天気 API を足したら if 文だらけになった。何が破綻するのかを確かめる
- API ごとに返す形が違って呼び出し側が分岐する。共通の窓口に揃える【Adapter】
- Adapter で揃えたのに、呼び出し側のコードがまだ長い。何が残っているのかを整理する
- API が落ちても天気を返したい。複数の Adapter をまとめて窓口を1つにする【Facade】
- 同じ都市の天気を何度も API に問い合わせている。Cache::LRU と TTL で呼び出しを減らす
- 全部の API が失敗したら呼び出し側は undef だらけになる。Try::Tiny と【Null Object】で止まらない設計にする
- 天気 API 連携の完成版を読み返す。使っていたのは Adapter と Facade、それと SOLID の関係
困りごとから探す
まず外部 API を呼んでみたい
- 第1回 — HTTP::Tiny で取得し、JSON::PP で読み取る最小版
2つ目の API を足したら if 文が増えた
呼び出し側が API の管理や失敗時の切り替えを抱えている
API の呼び出し回数や遅さを減らしたい
- 第6回 — 自前のキャッシュに TTL を足し、Cache::LRU に置き換える