@nqounetです。
前回は、BBSに機能を追加する過程でif/elseが肥大化する問題を体験しました。
今回は、その問題を解決する第一歩として、ディスパッチテーブルを学びます。
ディスパッチテーブルとは
ディスパッチテーブルとは、キーと処理の対応をハッシュで管理する仕組みです。if/elseで条件を順番にチェックする代わりに、ハッシュから直接処理を取り出して実行できます。
flowchart LR
subgraph ディスパッチテーブル
H["list → show_list<br>form → show_form<br>thread → show_thread"]
end
A["action: 'list'"] --> H
H --> B["show_list() を実行"]
ハッシュに処理名を登録する
まずは、どのアクションでどのメソッドを呼ぶかをハッシュに登録してみましょう。
| |
%handlersというハッシュに、アクション名とメソッド名の対応を定義しています。これがディスパッチテーブルです。
ハッシュから処理を取り出して実行する
次に、このハッシュを使ってdispatchメソッドを実装します。
| |
$handlers{$action}でメソッド名を取り出し、$self->$method()で実行しています。if/elseが1つだけになりました!
新しい機能を追加するときは、ハッシュに1行追加し、対応するメソッドを書くだけです。dispatchメソッドを修正する必要はありません。
まとめ
- ハッシュを使った振り分けの仕組みをディスパッチテーブルと呼ぶ
- if/elseのチェーンがなくなり、コードがすっきりする
- 新しい機能の追加はハッシュに1行追加するだけで済む
- dispatchメソッドの修正が不要になる
次回予告
次回は、処理自体を変数に入れる「コードリファレンス」を学びます。メソッド名ではなく、処理そのものをハッシュに登録できるようになります。
