早とちりプログラマの失敗から学ぶデザインパターン(Factory Method:適用前)
このシリーズについて
このシリーズは
- 後先のことをなにも考えずに実装してしまう『早とちりプログラマ』
と
- すぐに仕様変更を加える『後出し上司』
のという魅力的な2人から、
デザインパターンの有用さを学んでいこうという素敵な企画です。
(早とちりプログラマのモデルは私です。。。)
要件
上司「コンサートでピアノが聴けるようにしてよ」
わたし「わっかりました〜!!!」
※ 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(); // 書き換え } }
わたし「3箇所変更かぁ〜。めんどいなぁ」
仕様変更
上司「ホントはさ、個人的にマンドリンがいいと思うんだよね。
変えちゃってよ」
わたし「(個人的にって。。クライアント大丈夫か?)わ、わかりました〜」
変更方法
マンドリンクラスの作成
コンサートクラスの3箇所を書き換え
わたし「なんか同じところばかり修正してる気がする、、、」
わたし「楽器が変わるたびにコンサートクラスの書き換えなきゃいけないのか。。。
なんか嫌な予感がするな。。。」
仕様変更
上司「やっぱピアノに戻してくれない?! 急いで!」
わたし「えぇ!」
上司「このコンサート会場マンドリン使えないらしいんだよ!
クライアントはカンカンだ!
すぐできるでしょ? 10秒で実装しな!」
わたし「そんなむちゃな!」
上司「急がないと納期に間に合わねーんだよ!!」
わたし「お前のせいじゃねーか!(わかりました!)」
上司「お、お前。。。上司になんて口を!」
〜終〜
どうしてこうなった
クラスの中で特定のクラスをnewしてしまっているから
あるクラスの中で、いろんなクラスを使用するような拡張が予想される場合、
特定のクラスをnewしてしまっている(今回でいうPiano)と、
やっぱり別の特定クラスを使いたい(今回でいうGuiter, Mandolin)、、、
となった時にかなりの書き換えが発生することが多いです。
解決方法
このような変更に対して、
修正を最小限におさえるためにはどうしたらよいでしょうか。
最小限の修正に抑えれば、バグも少なくなるし仕事もサボれるはず。
続きは次回。。。