答えは「スキャナーには状態があるから」です。
java.util.Scannerのコードを見ると、バッファーとそれに関連する情報、マッチャー、パターン、入力ソース、ソースが閉じているかどうかに関する情報、タイプなど、いくつかのプライベートフィールドが表示されます。最後に一致したもの、有効な一致であるかどうかに関する情報、数値に使用される基数、ロケール(千桁区切りを使用している.
かどうかに関する情報,
)、および最近使用されたパターン用の独自のLRUキャッシュ、最後に発生した例外に関する情報、数値の解析に関する情報、ブール値の解析に関する情報、整数の解析に関するかなり多くの情報...そしてそれについてだと思います。
ご覧のとおり、これはかなり大きなテキストブロックです。それがスキャナーの状態です。Scannerを静的クラスにするには、その状態を別の場所に保存する必要があります。Cによる方法では、実際にはそれほど多くの状態はありません。あなたは持っていfscanf
ます。FILEは、現在の位置に関するいくつかの状態を維持します(ただし、の呼び出しごとに渡す必要がありますfscanf
)。エラーが発生した場合、あなたはそれを処理する必要が(そして、あなたはのように見えるというコードを書き始めるこの) -そしてそれは、「私は整数を期待していたが、文字列を見つけました。」のようにあなたの情報を教えてくれありません
理論的に静的なスキャナーを見ると、すべての状態がクラスの外部で維持されており、クラス内にカプセル化されていません。他のコードは、これらの変数をいじくる可能性があります。他のコードがクラスの状態をいじくり回すことができるとき、与えられた状況でクラスが何をするかについて推論することは非常に難しくなります。
おそらく、次のようなScannerState { Locale loc; ... }
コードを記述して、次のような結果になるコードを作成できます。
ScannerState state = new ScannerState(a whole lot of arguments);
int foo = Scanner.nextInt(state);
しかし、これはそもそも状態をScannerオブジェクト内にカプセル化するよりもずっと面倒です(そして状態を渡す必要がない)。
最後に、スキャナーはインターフェースを実装しています。Iterator<String>
これは、次のようなコードで使用できることを意味します。
Scanner in = new Scanner(someFile);
whie(in.hasNext()) { ... }
Scannerクラスのインスタンスを取得できない場合、このタイプの構造はオブジェクト指向言語内ではより扱いにくくなります。