skillup

技術ブログ

プログラミング全般

オブジェクト指向について その3

投稿日:

今回は場合分けによる変更コストとオブジェクト指向のメリットについてです。

例えば給付金が発生して、その金額を死亡時、退職時、通常時で場合分けするとき、if-elseで書けば下記のようになります。

この場合、早期リターンで書くと実はelseを書く必要はありません。

「死亡した時」はただちに「死亡時の金額」を返す、「退職した時」はただちに「退職時の金額」を返す、それ以外は「通常の金額」を返す。

金額が確定したらすぐにreturnをする場合のコードは下記のようになります。

これだけでもずいぶんすっきりしたコードになりましたが、さらにelse句を取り除くと、下記のように書けます。

特殊な場合をreturnで返し、else句を使わずに早期リターンするこの書き方をガード節といいます。

処理の独立性

ガード節と早期リターンを適用した最後の書き方は非常にコードがすっきりとわかりやすくなりました。

if節の中にさらにif節を書いていくような構造は非常にわかりにくくなります。単文を並べたコードのほうが見やすい処理となるでしょう。

また単文のほうが処理の独立性も高くなっています。

ここに離婚した時を加えても下記のように追加してあげればいいだけです。

この場合、3つの文はどこに入れてあげても処理が問題がありません。このように同じ場合分けでも、プログラムの影響度が低い単結合にすることがオブジェクト指向のアイディアです。

オブジェクト指向らしい場合分け

さらにオブジェクト指向を使った場合分けでは、場合ごとのロジック、それぞれ独立した別のクラスにすることが可能です。たとえば死亡時の金額を返すクラスDeadAmountクラスをつくってしまうのです。

この場合DeadAmountクラスを修正しても、他のクラスに影響がでません。場合ごとの処理が完全に独立されており、影響度が限定されるのです。

ただし、場合ごとにクラスを分けると複数のクラスを使い分けるのは大変になります。そこで3つの場合ごとのクラスの違いを意識せずに仕組みがインターフェイス宣言です。

給付金額を知りたいクライアントクラスは下記のようになります。

クラス図で書くと下記の通りです。

クラスクライアントはPayAmountという型を意識しているだけで死亡時、退職時、通常時の場合分けは意識していません。

しかしPayAmount型で参照する実装クラスのオブジェクトを静止するときに、ifかswitchが必要になります。Javaの場合はenumという便利な仕組みがあるため、ifなしで下記のように記述することができます。

-プログラミング全般

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

調査スキルについて

本日は実務でとても大切な不具合の発見方法について 通常のプログラマとして仕事をしておりますと、通常の実装よりは不具合時の調査のほうが難しいことが多々あります。 もちろんものによるんですが、経験のある人 …

no image

テストプロセスに関して

日々是テスト。 プログラマになってから数年がたちますが難点はずっと同じでテストですね(汗) 以前にかいたエントリーなどは下記参照。 参考 データベースによるテストデータ作成 Excelによるテストデー …

no image

オブジェクト指向 クラスの設計と業務ロジックの整理

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にクラスの作り方について。 Contents1 クラス設計と業務ロジック1.1 要点1.2 感想 クラス設計と業務ロジック …

no image

OSコマンドインジェクション

Contents1 OSコマンドインジェクションとは?2 被害3 対策4 参考リンク OSコマンドインジェクションとは? OSに対する命令文を不正に紛れ込ませて攻撃させる手法。 被害 サーバー内のファ …

no image

シェルの基礎+ユーザー切り替え関連

雑誌を見ていたらシェルの特集があったので、ちょっとメモリます。 補強したいところのみ要点をチェック。 Contents0.1 実行パスについて0.2 ビルドインコマンド0.3 シェル変数・環境変数0. …