まずは問題を見ろ
→ javadrill.tech で出題された問題を見る(Step02)
問題のポイント
- staticメソッドは インスタンスを生成せずに呼び出せる
- 「状態を持たない処理」は、インスタンス化せずに使うべき設計
Math.abs()
やCollections.sort()
のような現場にあふれるユーティリティの発想
まず、日本語で考えろ
- 数値を受け取って、加算・減算する処理をまとめたい
- データ(状態)を持たず、ただ処理するだけの機能
- そのために new するのは無駄 → staticにしてクラス名から直接呼ぶべき
コメントを書け
// add(int a, int b): a + b を返す
// subtract(int a, int b): a - b を返す
// どちらも static として定義する(インスタンス化しない)
// Main から直接クラス名で呼び出す
コメントに従って、コードを書け
public class CalcUtil {
public static int add(int a, int b) {
return a + b;
}
public static int subtract(int a, int b) {
return a - b;
}
// インスタンス化を防ぐ
private CalcUtil() {}
}
public class Main {
public static void main(String[] args) {
int sum = CalcUtil.add(10, 3);
int diff = CalcUtil.subtract(10, 3);
System.out.println("10 + 3 = " + sum);
System.out.println("10 - 3 = " + diff);
}
}
コードの解説
add()
やsubtract()
は 状態(インスタンス変数)を一切使っていない- だから、インスタンスを生成する意味がない
static
にしておくことで、CalcUtil.add(...)
のように 道具のように使える
つまづきやすいポイント
- 「staticにしたら便利」ではなく、**「状態を持たないからstatic」**という逆の発想を持て
- メソッドがstaticかどうかは、「設計としてnewが必要か?」で決まる
- 状態を持たない処理は、全部まとめてstaticクラス化する方が明快
// tesh:
// 「便利だからstatic」って言うな。
// 「状態を持たない処理だからstaticであるべき」って言え。
//
// newして何も保持しないクラス──そいつはもう、工具箱や。
// 毎回ドライバーを買い直すバカはいねぇだろ?
//
// オブジェクトってのは、本来「状態を持ち、それを内側に閉じ込める」もんや。
// でも、状態を一切持たず、ただ処理するだけの道具があるなら、
// そいつはstaticでいい。いや、staticでなきゃ気持ち悪い。
//
// Javaにおける Math.abs() も Collections.sort() も、状態を持たずに処理をする道具。
// それを new してから使いたいか? ──オレはイヤや。
//
// 大事なのは、道具と器の見分けや。
// 何でもかんでもクラス化して、newして、満足してんじゃねぇ。
//
// newするってのは、「このインスタンスに意味がある」って言う覚悟なんや。
// 覚悟がないなら、潔く static にして、道具として徹しろ。
//
// その区別がつくようになったとき、
// オマエの設計は“クラス”から“構造”に昇華する。
//
// 設計に、言い訳を混ぜるな。
//
// 書け。意味を持って書け。
// そして、意味のない new は、今すぐ捨てろ。