"Do-er"クラスと静的ユーティリティメソッドの比較

Question

readメソッドを持つFileReaderクラスがあるとします。

私は、クラスレベルの属性がインスタンスを持つことを正当化できることを理解しています。しかし、対応するstaticreadメソッドの範囲内でこれらの同じ属性を引き出すことによって同等のクラスを作成することを止めているのは何ですか？

つまり、静的ユーティリティメソッドに関して「Doer」クラスを正確に正当化するものは何ですか？

Answer 1

OOPの本質は、関連する動作と共に状態/データをカプセル化しています。静的ユーティリティメソッドは、手続き型言語のグローバル関数に似ています。つまり、動作（静的メソッド）を状態（このメソッドへのパラメータ）から分離し、カプセル化を破棄しています。

実際にはどういう意味ですか？ reader.read()に電話する代わりに、ReaderUtils.read(file)に電話する必要があります。これは、実装に密接に結びついていることを意味します。常にReaderUtilsを使用し、常にファイルを渡すという暗黙の前提があります。

あなたの代わりに、一般的なReaderインタフェースを使用する場合は、今日FileReaderを使用しますが、他のコードを変更することなくDatabaseReaderまたはHttpReader明日のためにそれを交換することができます - すべてのreader.read()呼び出しは同じように機能し続けます。

Answer 2

インタフェースは実装できません - インタフェースの実装されたメソッドはインスタンスメソッドでなければなりません。このように、これは、サービスを実行するための実行時実装としてinjectionまたはJNDIの "ユーティリティクラス"の参照を禁止します。クラスのインスタンスでなければなりません。これは "doer"クラスが存在する主な理由の1つです。

コンパイル時に実装が分かっていて、静的メソッドである場合、ユーティリティクラスは正常です（通常は静的フィールドが不変/ステートレスであることを確認してください）。同時に要求します。

Answer 3

これは優先事項です。一般に、Javaは名詞を好んでいます（人々はこれがより多くの人に感じられるからです）。したがって、FileReader。

Jeffreyが指摘したように、時には名詞の執着は、ポイント・コールが静的メソッドでラップされる不必要な冗長性につながることがあります。