8回かけて作った天気アグリゲーターの完成コードを通して読み、各パートが Adapter と Facade のどちらにあたるかを整理する。SOLID 原則との対応も確かめる。
ネットワークエラーやレート制限で全 API が落ちても、undef チェックを呼び出し側に強いることなく、デフォルトの天気データを返して動き続ける。Try::Tiny の例外処理と Null Object を組み合わせる。
ページ内で同じ都市を何度も取得して、API の上限や遅延に響く問題を、キャッシュで減らす。まず自前で実装し、期限切れの TTL を足してから、Cache::LRU に置き換える。
複数の Adapter の管理と、1つ目が失敗したら次を試すフォールバックを Facade にまとめる。呼び出し側は窓口を1回呼ぶだけで済む。Perl と Moo で実装して動きを確かめる。
Adapter を作っても、どの API を使うか、失敗したら次へ回すか、といった処理は呼び出し側に残る。Web アプリと CLI の両方に同じコードが散らばる様子から、次の設計の必要性を確かめる。
OpenWeatherMap と WeatherStack で違うレスポンスの形を、Adapter で同じメソッドに揃える。呼び出し側は API の違いを気にせず使える。Perl と Moo の Role で実装します。
WeatherStack を足すと、API ごとにレスポンスの形が違うため if-elsif の分岐と同じ処理の重複が増える。3つ目、4つ目を足す前に、どこで破綻が始まるのかを具体的に見る。
標準モジュールの HTTP::Tiny と JSON::PP だけで、天気 API にリクエストを送り、返ってきた JSON を読み取って表示する。API キーなしで動くモックデータで試せる。
Perl でバックアップツールを作りながら Template Method と Strategy を学ぶ全8回の連載。目次を兼ねた案内板で、読む順と各回の内容をまとめています。
Template Method に固定した流れと、Strategy で差し替えた部分を整理して振り返る。クラウド保存・暗号化・失敗時の通知を足すなら、どこに切れ目を入れるかも考える。
コピーが途中で失敗しても後から追えるように、ロガーと例外処理を Engine と Strategy に組み込む。一過性のエラー向けに、Sub::Retry で再試行する書き方も紹介する。
全ファイルを 1 つの tar.gz にまとめる圧縮戦略を足す。Engine にも他の戦略にも手を入れず、新しいファイルを置くだけで済むことを確かめる。
骨格の Engine と、差し替える Strategy を組み合わせる。ファイルを巡回するのがどちらかで迷う点を、全ファイルをまとめて扱う戦略も作れる側に決め、差分バックアップで動かす。
フル・差分・増分の 3 つを、同じ呼び出し方で入れ替えられる戦略クラスとして作る【Strategy】。10,000 ファイルで 2 回目以降の速度を比べ、呼び出し側を変えずに切り替えられることを確かめる。
コピーするかの判断と巡回が 1 つのループに混ざってきたので、準備・スキャン・同期・検証の流れを親クラスに固定し、中身を子クラスで差し替えられる形にする【Template Method】。
