プログラミング: 名前設計の基本方針①

金田晃侑

概要

今回は、プログラミングにおける名前設計に関してシンプルにまとめます。
まずは、代表的な悪い命名パターンについて学び、
そのあとにどのような命名をすればよいのかを学びます。


悪い命名パターン ６つ

悪い命名パターン①：技術駆動命名

技術者しか分からないようなmemory、state、intといった名前を使用しています。これは、ビジネス概念に即していないので可読性が下がります。

class MemoryStateManager {
  void changeIntValue01(int changeValue) {
    intValue01 -= changeValue;
    if (intValue01 < 0) {
      intValue01 = 0;
      updateState02Flag();
    }
  }
...
}

悪い命名パターン②：連番命名

数字の連番だけではなくて、a、b、cといったアルファベットによる命名もこのパターンに含まれます。

class Class001 {
  void method001();
  void method002();
  void method003();
...
}

悪い命名パターン③：ロジックをなぞった命名

ロジックが変更されたら名前もその都度変更しなければならないため、悪い命名パターンです。

class Magic {
  boolean isMemberHpMoreThanZeroAndIsMemberCanActAndIsMemberMpMoreThanMagicCostMp(Member member) {
    if (0 < member.hitPoint) {
      if (member.canAct()) {
        if (costMagicPoint <= member.magicPoint) {
          return true;
        }
      }
    }
    return false;
}

悪い命名パターン④：tmp だらけで意味不明

tmpに値が再代入されて使われがちです。オブジェクト指向プログラミングにおいて、再代入はご法度であり、tmpやtempは何を指しているのかが分からず、使用してはなりません。

int tmp3 = tmp1 - tmp2;
if (tmp3 < tmp4) {
 tmp3 = tmp4;
}
int tmp5 = tmp3 * tmp6;
return tmp5;

悪い命名パターン⑤：省略された名前

省略されているため、変数が何を表しているのかが分かりません。可読性は低い状態です。

int trFee = brFee + LRF * dod;

悪い命名パターン⑥：
メソッド名から類推できないことをやっている
(驚き最小の原則 違反)

itemCount()という関数名であるけれども、お買い物ギフトポイントを追加しています。アイテムカウントとは関係がないロジックがあり、可読性は低下している状態です。保守・運用メンテナンスをする人は、何故、アイテムカウントにおいて、お買い物ギフトポイントが追加されるのかを考察しなければならなくなるため、可読性、生産性が下がります。

// オーダークラス 
class Order {
  private final OrderId id;
  private final Items items;
  private GiftPoint giftPoint;

  //アイテムカウント 
  int itemCount() {
    int count = items.count();
    // 注文商品数が10個以上ならお買い物ギフトポイントを100追加する。
    if (10 <= count) {
      giftPoint = giftPoint.add(new GiftPoint(100));
    }
  return count;
}

ではどう命名すれば良い？？？

命名方針: 目的駆動名前設計

ソフトウェアで達成したい目的をベースに名前を設計(命名)すること。

名前から目的や意図が読み取れることが特徴。

悪いパターンに出てきたのは、
目的不明オブジェクト(例.tmp)、
もしくは、
目的不明関数(例.method1、itemCount(お買い物ギフトポイント追加のロジックが追加されている))
と呼べるでしょう。
そのような命名はしてはいけません。
可読性が下がるためです。

気をつけること

・一つひとつのオブジェクト、変数、クラス名、関数名の目的を考えた命名をする。

・関数名は、可能な限り動詞1語で済む名前にする。

→目的語はクラス名またはコンポーネント名、
　またはフィールドに集約する( カプセル化を意識 )。

・関心の分離
　関心事それぞれに、クラス、またはコンポーネントへ分割が必要。
　例えば、アイテムカウントとギフトポイント追加のそれぞれの関心は
　分離して、別々のロジックとして定義すること。
　関心の分離の目安: classは100行以内、メソッド(関数)は10行以内。

・抽象化せず、具体的なビジネス概念を表すように名前を設計すること。

参考情報

https://gihyo.jp/dp/ebook/2022/978-4-297-12784-8

https://www.seshop.com/product/detail/20690


いいなと思ったら応援しよう！