Fujitsu The Possibilities are Infinite

 

オブジェクト指向プログラミングへの道
4日目:コード重複の解消


知史

知史さん

航祐

航祐君

また何日かたって…。 新人の航祐(こうすけ)君とそのチューターの知史(さとし)さんの会話です。

航祐君、前回教えてもらったinterfaceに感動したようですが、まだ肝心の問題が解決していないことを忘れてしまっています。


航祐

「知史先輩、こんにちは。 あの後デザインパターンの本を買って読みましたが、やはり難しいです」


知史

「そうだね。 全部を理解しようとすると難しいかもしれない。 少しずつできる範囲で読んで行けばよいと思うよ。 少し経験を積んでから読み直すと判ることもあるよ」


航祐

「はい。 判りました」


知史

「今日は前回の続きの話をしよう。 前回はPlanというinterfaceを使ってchargeメソッドを宣言し、それを実装(implement)した楽々プランと得々プランというサブクラスを作った」


航祐

「はい。 サブクラスに料金計算ロジックを入れたので、どんな仕様のロジックを追加しても、既存のサブクラスは影響を受けないのでした」


知史

「そうだね。 しかし、楽々プランと得々プランは同じロジックなので、同じプログラムコードが2箇所に分散していることには変わりない。 このようにすると、前に話したようにプログラムの保守性は低下するんだ。 この問題の解決はできていない」


航祐

「あっ、そうですね。 interfaceの出現に感心していて、元の問題が解決できていないのを忘れていました」

航祐君はしばらく考えて…。

「先輩、それは最初のように、楽々プランクラスと得々プランクラスに共通のスーパークラスを作ってそこにロジックを書けばよいのではないですか」


知史

「えらい。 良く気がついたね。 そのとおり。 このように作ればいいんだよ」

と言いながら知史さんは、新しいクラス図を書きました。


(知史さんのプログラム2のクラス図)
図解: プログラム2のクラス図


「このクラス図からプログラムが起こせるかな」


航祐

「そうですね。 できそうな気がします」


知史

「そうか、それは良かった。 このようにクラス図で書くと、具体的なプログラムコードを書かなくても、お互いに意志の疎通を図ることができる。 これはクラス図の優れた特長だね」


航祐

「はい。 僕も少し成長したような気がします。 先輩、もっとオブジェクト指向について教えてください」


知史

「そうだね。 今回は具体例から入ったので、一般論をあまりやっていないね。 次回は継承とオブジェクトコンポジションの一般的な得失について話をしよう」


航祐

「はい。 期待しています」