場合わけのロジックを整理するを参考に、9年間ほど現場で設計やリファクタリングをしてきた自分なりの考えを交えながらまとめました。現場で役立つシステム設計の原則を読んでの気づきなどのまとめ記事を作ったのでこちらも合わせてご覧ください。支払方法が残高から支払い場合はポイント1.5倍で・・・このように種別や区分毎に業務ロジックが分かれることは開発の現場ではよくあります。分岐の取り扱い方が保守性を左右します。以下仕様を満たす場合取引実行のユースケースをどのようにコーディング記述するでしょうか。こんな感じでコーディングしたとします。(あくまで説明のためのコードくらいでざっくり見ていただければと。保守性がものすごいスピードで低下していきます。付与ポイント率ノーマル会員なら取引金額の0.5%シルバー会員なら取引金額の1%ゴールド会員なら取引金額の1.5%当日発送ノーマル会員なら利用不可シルバー会員なら利用不可ゴールド会員なら利用可能さらに、この辺りは頻繁に変更が入る前提とします。先ほどのコードを僕ならどのように保守性を考慮して分岐を丁寧に扱うかというのを説明していきます。会員には、ノーマル会員、シルバー会員、ゴールド会員があり、それぞれの会員は共通して送料、付与ポイント率、当日発送可否が算出できるように小さいシンプルなクラスに分けていきます。}}今まで分岐させていた会員のランクによる判定や計算を小さく分けることでシンプルで、変更時の影響範囲を小さくできます。後からシルバー会員だけポイント算出を特殊な方法で行うとなっても、SilverMemberのcalculatePointの部分のみに影響が留められます。後からプラチナ会員が増えても、PlutinumMemberクラスを増やせば既存へは影響は一切ありません。使う側がシルバー会員、ゴールド会員などを意識しなくて済むように、Interfaceを使ってそれぞれの会員種別を同じように扱えるようにします。個別に作成したノーマル会員やシルバー会員などはインタフェースを実装するようにします。最後は、ノーマル会員なのかシルバー会員なのかゴールド会員なのか、どれを生成すれば良いかを判定して会員インタフェースの実態を生成する部分です。会員生成ファクトリーを作ります。取引実行のユースケース(使う側)がシンプルになります。今回のサンプルコードの紹介はここまでとします。分岐を丁寧に扱うことで得られることと保守性わざわざクラスを小さく分けて、インタフェースを切ってファクトリを作って・・・ここまでやることによるメリットについて最後に見ていきます。追加機能対応や仕様変更などが行い続けることを想定しています。今回のようにインタフェースを切ったり、ファクトリーを作ったりそこまでやる必要はないので、最初のコードで十分。今回の話の目指す場所はリリース後の保守開発をやりやすくことにあるということを改めて持っていただければと思います。僕は以下のことを得られたと思っています。今回の作りにしたことによって、プラチナ会員のようなランクが増えた場合、PlutinumMemberクラスを追加して、memberFactoryの1箇所のみ分岐ロジックを追加するだけで済みます。使う側であるユースケースの修正は不要です。使う側であるユースケースは複数あるケースが多く、そういうケースではさらに効果を発揮します。特殊な取引実行ユースケースを作ることになり、そちらにもポイント算出がそちらでも必要だったとします。開発者はそれを参考にほぼ間違いなくコピペで同じ処理を特殊取引実行ユースケースにも作ると思います。特殊取引実行ユースケースの両方に対応が必要となります。技術負債がちょっとした変更で増加する危険性あるのに対して、リファクタリング後のコードだと、その危険性が抑えられていると思います。シルバー会員のポイント計算ロジックが変更になっても、ノーマル会員やゴールド会員のポイント計算ロジックに一切影響を与えることなくシルバー会員クラスのポイント計算メソッドが修正できます。この点でも保守性が良いと言えると思います。開発者は基本的に既存の似たようなコードや仕掛けを探して流用しようとします。綺麗にクラスを小さく分けて使いまわせるようにしておけばそれを使っている箇所を参考に同じように使い回してくれます。似たような汚い大きなクラスがいつの間にか量産されしまいます。最初に分岐を雑に扱うか、丁寧に扱うかで技術負債の増加スピードが全く違ってくるのです。保守開発を見据えて丁寧に分岐を扱うことの大切さについて僕はこのように考えています。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。