実務に即したファクトリ実装

もし、○○○ならば、XXXをする。

これは極めてソフトウェア工学の中ではポピュラーなモノの考え方です。
常に通奏低音のように鳴り響き、まるで呪縛のように私たちを取り巻いている、ひとつの習慣として醸成されています。

今回はここを取り崩そうと考えています。

上の if文 の中でさらに条件を想定して、もし、△△△ならば、□□□をする。というような構造を考えてみます。いわゆる入れ子構造です。

ここまでを整理します。
すると以下のような構造が見えてくると思います。

if ○○○ {
     if  △△△ {
          □□□
     }
     else {
          XXX
     }
}
else {
     // 何もしない。
}

ここでは、3つの処理系が存在することがわかります。
さらに、もし、△△△ならば…　という条件下でさらに入れ子になる構造…　と考えたところで、うんざりしますね。そしてバグの不安に駆られます。このような構造が（そう、構造そのものなのです！）ソースコードの平面的な世界観の中で表現された場合、人間の頭の中ではどのくらいの階層まで把握、管理ができるでしょうか？

いいえ、このような発想は、おそらくナンセンスなのでしょう。
もっと、シンプルに整理、管理できないのか？　ということに頭を使ったほうが、余程世のためなのだと思います。

皆さんであれば、どのような工夫をするでしょうか。

このように整理してみます。

if ○○○ {
     if  △△△ {
          □□□　Aの処理系
     }
     else {
          XXX　　Bの処理系
     }
}
else {
     // 何もしない。Cの処理系
}

この構造を階層で表現せずに、バラバラにしてまずはコンテキストで表します。
（表現が冗長になるのためコンストラクタの記述は割愛します）

まずは、AとBの処置系
class ABClass implements IFactory {
     public void Execute() {
          if △△△ {
               // Aの処理をする。
          }
          else {
               // Bの処理をする。
          }
     }
}

次にCの処理系
class CClass implements IFactory {
     public void Execute() {
          // Cの処理をする。
     }
}

この段階でAとBの処理系をドライブする表現を記述します。

IFactory target = null;
if ○○○ {
     target = new ABClass();
     target.Execute():
}
else {
     target = new CClass();
     target.Execute():
}

if文の入れ子構造をひとつ減らすことができました。
ポイントは、もし、○○○ならば、XXXをする　という考え方から脱却して、XXXという条件で○○○をする　というように捉え直します。
いわゆるポリモフィズムの実務に即した応用です。