http://qiita.com/takaaki4cards/items/23127bcda036229d653d
Fizz buzz に strategy や factory を使うのが適している理由やメリットを説明できる人はどなたかいらっしゃいますか?
率直な話としては、この単純さのコードでに strategy や factory を使うことは適していない。
しかしそれを使う理由やメリットは説明できるし、Fizz buzz に strategy や factory を使うことで、もっと規模の大きいプログラムに strategy や factory を使ったときにどのようなメリットが発生するかを説明できる。
・依存関係が逆転できる
手続き型：全体が、詳細（FizzやBuzzを表示する処理）に依存している。
OOP：詳細（FizzやBuzzを表示する処理）が、全体（全体処理＋表示処理インターフェース）に依存している。
・開放閉鎖原則が満たせる
手続き型：詳細の変更が、全体に影響する可能性がある。（これは関数に切り分ければいい話……なのか？）
OOP：(インターフェースに従う限り)詳細を変更しても、全体側のコードを変更する必要が無いことが保証される。
・つまり
詳細の変更を、詳細に閉じ込めることができる。
(fizzbuzzではたまたま詳細の変更が全体に影響しないようになっているが)手続き型ではそれが保証できない。
たとえばfizzbuzzを文字出力するのではなく、fizzやbuzzと音声で喋らせたいという修正をするとき、手続き型だと全体が詳細に依存するので、ロジック的には音声がどうとか関係ない部分である「1〜50についてfizzbuzzする」という部分が、音声出力ライブラリ無しにはビルドできなくなってしまう。
それに対してOOPで作った場合「fizzbuzzを出力する部分」に音声出力が必要になっても、「1〜50についてfizzbuzzする」の部分は音声出力ライブラリに依存しない。なんならリビルドすらせずに詳細側を変更するだけでも動かすこともできる。
