共通化の罠とは

Posted at 2024-04-24

DRY原則とは

以下を読んでください

DRY原則を理解した私です。

同じような考えになったエンジニアの皆さん以下の動画を見てみてください
（はっとします）

共通化の罠は同じ意味を持たないものを共通化してしまった場合に発生する問題です

ここでいう問題は
変更容易性/理解容易性/テスト容易性を下げてしまいます

例えば、以下コードを共通化してしまうと想定しましょう。

1.CalenderAクラスで定義され利用されているaddメソッド（日を進める）

class CalenderA {
  void addメソッド(date）{
   cal.add(date);
}

2.CalenderBクラスで定義され利用されているaddメソッド（日を進める＋進めた日の合計値を計算する）

class CalenderB {
  void addメソッド(date）{
   cal.add(date);
   sum=sum+date;
}

1.2を共通化したCalenderUtilクラスをつくりaddメソッドを作ったとします
(まあこの時点でいけてないですが上手い例が出なかったので）

class CalenderUtil {
  void addメソッド(date）{
   cal.add(date);
   if(クラスBからの条件分岐){
    sum=sum+date;
   } 
}

上記の共通化メソッドでも、ひとまずCalemderAクラスでもCalenderBクラスでも動作はします。
ただ、CalenderBクラスに仕様の変更が発生して、修正が必要になったとしましょう。
仕様の変更により、CalenderUtilに修正が入ります。

class CalenderUtil {
  void addメソッド(date）{
   cal.add(date);
   if(クラスBからの条件分岐){
    sum=sum+date;
   } 
   if(追加された条件分岐){
    sum=sum+date*2;
   }
}

本来であれば、CalenderBクラスにのみ必要な修正なので（CalenderAには不要）
CalenderBクラスだけの動作確認で良いのに、CalenderAクラスの動作も考慮しながら修正を入れる必要があります。つまり変更する際のコストが高くなり、変更容易性を下げる内容になります。

テストに関してもCalenderBの動作確認だけでなくCalenderAの動作確認も必要になります。
テストの準備が多くなるので、テスト容易性を下げる内容になります。

CalnederB専用のクラス専用の条件分岐がCalenderUtilクラスに入るので理解容易性も下がります。
これらのように共通化の罠にはまると変更容易性・テスト容易性・理解容易性を下げてしまいます

上記の点から
DRY原則を遵守するためになんでもかんでも共通化すると共通化の罠にはまります。
罠にはまると、変更容易性・テスト容易性・理解容易性を下げて後々自分の首を絞めることになります。
なので共通化するものは同じ意味かどうかをまず判断することが重要です。