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

JavaScriptライブラリ sugar

去年、JavaScriptの仕事をがりがりやった時にお世話になったライブラリsugar。 JavaScriptのライブラリというとunderscore.jsが有名ですが、こいつも結構使えるライブラリで …

no image

ログの設計指針について

今まで10以上近い現場で仕事をしてきましたが、どの現場でも絶対必要になる(かつどこもあまり対策が取られていない)技術としては 検証したい状態の復元がすぐにできる(テストデータ作成) ログの適切な設計 …

no image

トランザクション、ロールバックに関する考察

今までトランザクションの単位は基本的に処理の開始から終了までを範囲にすることが多かったのですが(ループがある場合はループ全体ではなく、1ループをトランザクションとみなします)、複数の処理が絡む場合、不 …

no image

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

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

no image

ダミーデータの作り方 まとめ

現在作っているアプリを顧客先で見せる機会があり、そのためダミーデータを入れる、という仕事がありました。 といっても画面からポチポチやったんでは時間もかかりますし、何より精神的にやられてしまいます。(汗 …

アーカイブ