Primitive Obsession
Primitive Obsession
Primitive Obsession(基本データ型への執着):
兆候と症状
- 単純なタスク(通貨、範囲、電話番号用の特別な文字列など)に小さなクラスを作る代わりにプリミティブ型(intやlongなど)を使用する。
- コーディング情報への定数の使用(管理者権限を持つユーザーを参照するための定数USERADMINROLE = 1など)。
- データ配列で使用するフィールド名としての文字列定数の使用。
問題の理由 他のほとんどのCode Smell同様、Primitive Obsessionは弱さの瞬間に生まれます。 例えば、クラス内にプリミティブフィールドを作成するような行為です。プリミティブフィールドの作成は、新しいクラスを作成するよりもはるかに簡単です。フィールドが必要になるたびにプリミティブフィールドが追加されます。追加を繰り返した結果、クラスは巨大で扱いにくくなっていきます。
プリミティブは、型に”似せる”ためにもよく使用されます。個別のデータ型の代わりに、いくつかのエンティティの許容値のリストを形成する一連の数値または文字列を定数で宣言します。これらの定数には、わかりやすい名前を付けることができます。これは広く普及してしまっているやり方です。
プリミティブ型を使用した別の質の悪い例は、フィールドシミュレーションです。多様なデータの大規模な配列をクラスに含め、このデータを取得するための配列インデックスとして、クラスで指定した文字列定数が使用されます。
対処 さまざまなプリミティブフィールドがある場合、それらのいくつかを論理的に独自のクラスにグループ化できる場合があります。さらに、このデータに関連付けられた振る舞いもそのクラスに移動するとより良いです。このタスクでは、「Replace Data Value with Object」を試してください。
- プリミティブフィールドの値がメソッド引数で使用されている場合は、「Introduce Parameter Object」または「Preserve Whole Object」を試してみましょう。
- 複雑なデータが変数でコーディングされている場合は、「Replace Type Code with Class」, 「Replace Type Code with Subclasses」または「Replace Type Code with State/Strategy」を試してみましょう。
- 1つの配列に複数の型が含まれている場合は「Replace Array with Object」を使用します。
効果
- プリミティブの代わりにオブジェクトを使用することで、コードがより柔軟になります。
- コードが理解しやすくなり、プログラムの構成が改善されます。特定のデータに対する操作が分散せず、同じ場所にあります。定数の意味と、それらが配列内にある意図について推測する必要がなくなります。
- 重複コードの発見が容易になります。
書籍としてはこの辺りが参考になると思います。
リファクタリング第2版

レガシーコード改善ガイド
