skillup

技術ブログ

アーキテクト設計全般

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

投稿日:2016年6月6日 更新日:

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

例えば給付金が発生して、その金額を死亡時、退職時、通常時で場合分けするとき、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

オブジェクト指向 値オブジェクトの活用と場合分けに関して

オブジェクト指向 その1 オブジェクト指向 その2 オブジェクト指向 その3 でオブジェクト指向に触れたんですが、基本から勉強しなおす必要があると思い、まとめ&追記 参考文献 現場で役に立つシステム設 …

no image

オブジェクト指向 アプリケーション層に関して

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にアプリケーション層(以下AP層)。MVCモデルでいうところのコントローラーに近い?)の考え方について。 Contents1 …

no image

スクラム開発をやってみて

アジャイルの定義に関してはエンジニアによって色々なものがあると思われますが、自分の場合一番綺麗に説明されているな・・・と感じたのは以下の記事でも紹介した書籍でした。 アジャイル開発について 現場ではた …

no image

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

前回のエントリーのように、データとロジックを一体で考えるのは、処理状の有効性のみならず、よりユーザー側に近い処理をかくということにもつながります。 日付の問題に関してもintやshortよりはLoca …

アーカイブ