偽APIのif/else地獄を、PerlとMooのクラス分割で抜けてFactory Methodにたどり着く全8回【目次】
Tags
9 ページ目
Api-Response-Simulator
ここまで作った偽APIの設計に名前を付ける。Scenario が Creator、create_response がファクトリメソッドだった【Factory Method】
429レート制限のシナリオを足す。既存のコードは1行も書き換えず、新しいクラスを足すだけで済む【オープン・クローズドの原則】
ログ出力と処理時間の計測がシナリオごとにコピペされる。共通の送信フローを基底クラスに集める【共通処理の集約】
シナリオごとに専用のレスポンスを返したい。create_response をサブクラスでオーバーライドする【オーバーライド】
レスポンスのクラスごとに render の有無がばらばら。Moo::Role で必須メソッドを決める【Moo::Role】
if/elseだらけの偽APIを、シナリオごとのクラスに分ける。継承で成功と404を独立させる【継承で分離】
偽APIにエラーレスポンスを足したら、メソッドが if/else だらけになる。分岐が増える限界を確かめる【if/elseの肥大化】
PerlとMooで偽APIを作る。成功レスポンスだけ返すミニAPIで、ResponseクラスとMockApiクラスの土台を置く【最小構成】