@nqounetです。
Markdown を HTML やプレーンテキストに変換するツールを、if/else を並べた素直な実装から作り始め、分岐が増え続ける問題に突き当たってから Visitor パターンで解く全8回の連載です。パターンを先に覚えるのではなく、困ってから直す順に進み、最終回で「ここまで作ったのが Visitor だった」と名前がつきます。
このページは目次を兼ねた案内板です。初めてなら「読み方」から、いま if/else の増殖に困っているなら「困りごとから探す」から選んでください。
対象読者
「Mooで覚えるオブジェクト指向プログラミング」シリーズを読了した方、または Moo でクラスを定義し、has 属性とメソッドが書ける方を対象としています。
読み方
- 通して読む: 第1回から順に。コードは前の回の続きなので、動かしながら進めるなら順番どおりが確実です
- if/else の増殖に困っているなら: 第3回で問題を、第5回で解き方を読めば要点がつかめます
- Visitor パターンの名前と定義が目的なら: 第8回から読み、気になった所だけ前の回に戻れます
全8回
- Markdownを読み込んで変換したい。まず段落をオブジェクトにする【Moo】
- 見出しもコードブロックも区別できない。継承で要素の種類を分ける【Moo】
- HTML変換を足したら if/else が要素の数だけ伸びる。限界を体験する【Perl】
- if/else だらけの変換処理を Converter クラスに切り出す【Moo】
- Converter に残った if/else をなくす。要素が自分で変換先を選ぶ【Double Dispatch】
- 出力形式を足すのに、既存コードは1行も直さない【OCP】
- 単語数カウントとリンク抽出も同じ仕組みで足す。変換以外の操作を増やす【Visitor】
- ここまで作ってきた設計の名前は【Visitor パターン】だった
困りごとから探す
要素の種類が増えるたびに if/else が伸びる
- 第3回 — 要素を1つ足すと、既存の変換関数まで直すことになる
- 第4回 — 変換処理を Converter クラスに切り出して整理する
- 第5回 — それでも残る分岐を、要素自身に選ばせて消す（Double Dispatch）
出力形式や操作を足すたびに既存コードを触りたくない
文字列をそのまま扱っていて、構造を持たせたい
仕組みに名前をつけて整理したい
- 第8回 — GoF の Visitor パターンの定義と、ここまでの実装の対応