サンプルをみて「で、こんなことができて何のトクがあるの？」と感じる方もいらっしゃるだろう。
たとえばこんな用途。
事務手続きの決まっているもの、そう、たとえば定型的な書類が複数あり、データベースから選択して決裁／印刷したい場合なんかはどうでしょう。
共通部分は処理の流れになる。起票、押印、決裁、しかるべき提出先へ提出、といったところでしょうか。電子化されているなら、例えば雛形選択、情報付記＆登録、電子押印、電子決済、印刷と送付先ラベルシール印刷、というように置き換えられるとします。
相違部分は雛形が違えば、起票内容、決裁先、送付先、そもそもの帳票フォーマット、などがあります。
（今朝歯磨きしながら思いついた例で、電子決済なんか考えるとちょっと規模が大きくなりますが、そこのところは寛大に・・）
ポリフォーフィズムを使えば「相違部分をオブジェクト化し、共通部分を使い回す基本ロジックに」と整理できます。
さて、ダウンロードできるようにしたサンプルで、オプションボタンではなく、通常のボタンを３つにしたならどうだろう。それぞれのボタンイベント内でオブジェクトを指定することになるので、イベント内からIf文が消える、ということになります。構造化プログラミングでいうところの、順次、分岐、反復のうち、分岐が減らせることになるということです。
このことは、たとえば４つ目を追加した場合の従来ロジックへの影響度を考えますと、分岐のあるオプションボタン方式だと分岐を追加するので一通り従来の分もテストする必要がありますが、通常のボタン追加方式だと従来のロジックを変更するわけではないので追加分のテストのみですむことになります。
このあたり、インターフェースとの兼ね合いもあったりと、必ずしも後者でなければというつもりはありませんが、設計時の考慮点として知っておいて損はないかなと思います。
※書き直し ／八月末削除予定 ／クラスモジュール応用