Java | オブジェクト指向：命名の重要性

Java Java
スポンサーリンク

なぜ命名がそんなに重要なのか

命名は、プログラムの「言葉」です。
コードは機械のためのものに見えて、実際には「人間が読む時間」の方が圧倒的に長いです。

だから、
変数名・メソッド名・クラス名は、そのまま「設計の説明書」になります。

名前が良ければ、コードを開いた瞬間に意図が頭に入ってくる。
名前が悪ければ、コードを読むたびに「これ何だっけ？」と推理ゲームが始まります。

命名が下手だと、ロジック自体は合っていても、
チーム全体の理解コスト・バグ率・設計の質が全部ジワジワ悪くなります。

悪い名前が生む「読みづらさ」の例

例1：何をしているか分からないメソッド名

次のメソッド、何をしているか一瞬で分かりますか？

public void process(User u) {
    // いろいろ処理
}
Java

process は「処理する」、程度の意味しかありません。
User をどう処理するのか、名前からはまったく分からない。

実際の中身がこうだったとします。

public void process(User u) {
    if (!u.isActive()) {
        throw new IllegalStateException("退会済み");
    }
    if (u.isPremium()) {
        sendPremiumMail(u);
    } else {
        sendNormalMail(u);
    }
}
Java

やっているのは「ユーザにメールを送る」です。
なら、こういう名前の方がはるかにいいです。

public void sendMailTo(User user) { ... }
Java

あるいはもっと具体的に、

public void sendWelcomeMail(User user) { ... }
Java

とすれば、「何のためのメソッドか」が一発で分かります。

名前が悪いと、「毎回中を開いて確認しないと意味が分からない」メソッドが増えます。
名前が良いと、そもそも中身を開かなくても意図が読み取れるようになります。

例2：何の値か分からない変数名

次のコードも、初心者がやりがちです。

int x = calc(a, b);
Java

x も a も b も、何の値か分かりません。
calc も「計算する」以上の意味が分かりません。

例えばこれは「商品の税込金額を計算している」コードだとします。

int totalPriceWithTax = calcTotalPriceWithTax(unitPrice, quantity);
Java

と書かれていれば、
「ああ、単価と数量から税込みの合計金額を出しているんだな」と一瞬で分かります。

名前の質次第で、「読者が頭の中で補わなきゃいけない情報量」が桁違いに変わります。

良い名前の基本：何を表しているか、何をするかを「日本語で説明」してみる（重要）

「日本語で説明してから英語（識別子）にする」

命名で失敗する人は、いきなり英単語を考えようとします。
そうではなく、まず日本語で自分に問いかけてください。

このクラスは、一言で言うと何者？
このメソッドは「何を、どうする」メソッド？
この変数は「何を表す値」？

例えば、こんなメソッドを書こうとしているとします。

「カート内の全商品合計から割引を引いて、最終的な支払い金額を計算するメソッド」

これを急に process() とか calc() とかにしないで、
日本語のまま縮めていくとこうなります。

「カートの支払い金額を計算」
→ calculateCartTotal
→ calculateCartTotal()

あるいは

「カートの支払金額」
→ calculatePayableAmount()

こういうステップを一回挟むだけで、命名の質が一気に変わります。

クラス名は「名詞」、メソッド名は「動詞＋目的語」が基本

クラス名：
User, Order, Cart, PasswordEncoder, DiscountPolicy のように「モノ・役割の名前」。

メソッド名：
addItem, removeItem, calculateTotal, sendMail, changeEmail のように「すること」。

これを守るだけでも、
UserManager, DataProcessUtil, CommonHelper みたいな「何者か分からない名前」を減らせます。

命名が設計そのものを変えてしまう話（深掘り）

名前をつけようとして「設計の違和感」に気づける

例えば、こんなメソッドを書こうとしているとします。

public void doUser() { ... }
Java

さすがに「doUser」はひどいので、考え直します。
「ユーザに何をするのか？」と言い換えると、

ユーザを保存する
ユーザを削除する
ユーザを検索する
ユーザのパスワードを変更する

など、いくつかの候補に分解されます。

もし、そのメソッドの中にこれらが全部詰まっているなら、
それは「一つのメソッドがやりすぎ」であり、
クラス設計を見直すべきサインです。

名前をちゃんと付けようとすると、

「このクラスは何をするクラスなの？」
「このメソッドは一つのことだけしている？」

と自分に問い直すことになります。
命名の試行錯誤は、そのまま設計の見直しにつながります。

無理に「短く」しようとしない

短さより「正確さ」を優先した方が、長期的には読みやすくなります。

例えば、こんな名前の違いを感じてみてください。

calc() vs calculateDiscountedPrice()
do() vs sendWelcomeMailToUser()
update() vs changeEmail()

5文字で意味不明な名前より、
20文字で意味が一発で分かる名前の方が、読み手には優しいです。

「長すぎて IDE で読みにくい」と思ったら、
それは名前ではなく設計が悪い（責務が多すぎる）可能性もあります。

ドメイン（業務）の言葉をそのまま使う

技術用語ではなく「業務の日本語」を英語化する

例えば、EC サイトを作っているとします。

業務で実際に飛び交う言葉は、

カートに商品を入れる
カートから商品を削除する
注文を確定する
送料を計算する

などです。

これを、そのままメソッド名に落とし込むと、

addItemToCart
removeItemFromCart
placeOrder
calculateShippingCost

のようになります。

逆に、技術寄りに寄せ過ぎると

execute()
process()
handle()

のようになり、ドメインの意味が消えてしまいます。

ドメインの言葉をコードに残すと、

業務の人とも話が通じやすい
仕様書や要件とコードをマッピングしやすい
自分が後で読み返したときにも意図を思い出しやすい

という大きなメリットがあります。

具体例：悪い名前 → 良い名前 にリファクタリングしてみる

例：ポイント加算処理

悪い例：

public class UserService {

    public void execute(User u, int p) {
        u.p = u.p + p;
        if (u.p > 10000) {
            u.p = 10000;
        }
    }
}
Java

ぱっと見、何をしているのか分かりにくいですよね。

これを日本語で説明すると、

「ユーザにポイントを加算する。ただし最大 10000 まで」

です。
では名前を変えていきます。

クラス名：UserService はまだ許せるとして、
メソッド名：addPoint の方が明らかに分かりやすい。

引数名：u ではなく user、p ではなく addedPoint など。

さらに、ポイントの上限 10000 は「User のルール」であり、
User クラスに持たせるべきです。

public class User {

    private int point;

    public void addPoint(int addedPoint) {
        if (addedPoint < 0) {
            throw new IllegalArgumentException("マイナス加算は禁止");
        }
        point += addedPoint;
        if (point > 10000) {
            point = 10000;
        }
    }

    public int point() {
        return point;
    }
}
Java

すると、呼び出し側はこうなります。

user.addPoint(100);
Java

この1行を見ただけで、
「ユーザにポイントを加算しているんだな」と分かります。

名前を整えることが、そのまま
「責務をクラスに戻す」「オブジェクト指向らしいコードにする」という設計改善にも繋がっています。

命名を良くするための、日々の小さな習慣

書いてから「声に出して読んでみる」

メソッドを一つ書いたら、頭の中で日本語にして読んでみてください。

user.addPoint(100);
→ 「ユーザにポイントを100追加する」

違和感がなければOKです。

user.process(100);
→ 「ユーザを100処理する…？ なにそれ？」

変な日本語になるなら、名前がよくないサインです。

「これ何？」と自分で突っ込む

変数名やメソッド名を書いた瞬間に、

これは何のこと？
この名前だけ見て意味が分かる？

と自分に突っ込む癖をつけてください。

自分で「分かりにくいな」と感じたところは、他人から見たらもっと分かりません。
その場で 10 秒考えて名前を良くするだけで、
未来の自分とチームメンバーの時間をかなり節約できます。

まとめ：命名は「一番コスパの良いリファクタリング」

命名を良くするだけで、

コードの意図が伝わりやすくなる
バグが減る
設計の違和感に早く気づける
ドメインの知識がコードに残る

という効果があります。

しかも、

中身のロジックを書き換えない
テストもほとんど書き換えなくていい
コンパイルエラーも IDE がほぼ自動で直してくれる

と、「コストの割に得るものが大きい」リファクタリングです。

スポンサーリンク
タイトルとURLをコピーしました