早とちりプログラマの失敗から学ぶデザインパターン（Factory Method：適用前）

このシリーズについて

このシリーズは

• 後先のことをなにも考えずに実装してしまう『早とちりプログラマ』

と

• すぐに仕様変更を加える『後出し上司』

のという魅力的な２人から、

デザインパターンの有用さを学んでいこうという素敵な企画です。

（早とちりプログラマのモデルは私です。。。）

要件

上司「コンサートでピアノが聴けるようにしてよ」

わたし「わっかりました〜！！！」

※ typescriptでの実装となります。

ピアノクラス

class Piano
{
    public play()
    {
        console.log('ポロンポロン');
    }
}

コンサートクラス

class Concert
{
    private piano: Piano;
    
    constructor()
    {
        this.piano = new Piano();
    }
    
    public start()
    {
        this.piano.play();
    }
}

使い方

const concert = new Concert();
concert.start();

仕様変更

わたし「余裕じゃん。一発で終わったわ」

上司「クライアントがさ、やっぱりピアノじゃなくてギターじゃないとダメだって」

わたし「お安い御用です！」

変更方法

追加：ギタークラス

class Guitar
{
    public play()
    {
        console.log('ジャーン');        
    }
}

変更：コンサートクラス

class Concert
{
    private guitar: Guitar; // 書き換え
    
    constructor()
    {
        this.guitar = new Guitar(); // 書き換え
    }
    
    public start()
    {
        this.guitar.play(); // 書き換え
    }
}

わたし「３箇所変更かぁ〜。めんどいなぁ」

仕様変更

上司「ホントはさ、個人的にマンドリンがいいと思うんだよね。

　　　変えちゃってよ」

わたし「（個人的にって。。クライアント大丈夫か？）わ、わかりました〜」

変更方法

• マンドリンクラスの作成

• コンサートクラスの３箇所を書き換え

わたし「なんか同じところばかり修正してる気がする、、、」

わたし「楽器が変わるたびにコンサートクラスの書き換えなきゃいけないのか。。。

　　　　なんか嫌な予感がするな。。。」

仕様変更

上司「やっぱピアノに戻してくれない？！　急いで！」

わたし「えぇ！」

上司「このコンサート会場マンドリン使えないらしいんだよ！

　 　　クライアントはカンカンだ！

　 　　すぐできるでしょ？ 10秒で実装しな！」

わたし「そんなむちゃな！」

上司「急がないと納期に間に合わねーんだよ！！」

わたし「お前のせいじゃねーか！（わかりました！）」

上司「お、お前。。。上司になんて口を！」

〜終〜

どうしてこうなった

クラスの中で特定のクラスをnewしてしまっているから

あるクラスの中で、いろんなクラスを使用するような拡張が予想される場合、

特定のクラスをnewしてしまっている（今回でいうPiano）と、

やっぱり別の特定クラスを使いたい（今回でいうGuiter, Mandolin）、、、

となった時にかなりの書き換えが発生することが多いです。

解決方法

このような変更に対して、

修正を最小限におさえるためにはどうしたらよいでしょうか。

最小限の修正に抑えれば、バグも少なくなるし仕事もサボれるはず。

続きは次回。。。