メソッドを持つFileReader
クラスがあるとしread
ます。
クラスレベルの属性がインスタンスを持つことを正当化できることを理解しています。しかし、対応するメソッドReaderUtils
のスコープ内でこれらの同じ属性を取得することによって同等のクラスを作成するのをやめるのは何ですか?static
read
要するに、静的ユーティリティ メソッドに関して「Doer」クラスを正確に正当化するものは何ですか?
インターフェイスを静的に実装することはできません。インターフェイスの実装メソッドはインスタンスメソッドである必要があります。そのため、これにより、サービスを実行するためのランタイム実装としての「ユーティリティクラス」のインジェクションまたはJNDIルックアップが禁止されます。これはクラスのインスタンスである必要があります。これが、「実行者」クラスが存在する主な理由の1つです。
ユーティリティクラスは、実装がコンパイル時に既知であり、静的メソッドである場合、自然にステートレスになる可能性が高くなります(静的フィールドが不変/ステートレスであることを確認してください)。これは、要求を同時に処理する一般的なサーバーで必要です。
OOP の本質は、関連付けられた動作と共に状態/データをカプセル化することです。静的ユーティリティ メソッドは、手続き型言語のグローバル関数に似ています。動作 (静的メソッド) を状態 (このメソッドのパラメーター) から分離しているため、カプセル化が解除されます。
これは実際にはどういう意味ですか?を呼び出すことができる代わりに、 を呼び出すreader.read()
必要があります。つまり、実装に密接に結合されていることを意味します。常にファイルを使用し、常にファイルを渡すReaderUtils.read(file)
という暗黙の仮定を行っています。ReaderUtils
代わりにジェネリックReader
インターフェイスを使用する場合は、today を使用できますが、他のコードを変更する必要なく、 FileReader
todayDatabaseReader
またはfuture に交換できます。すべての呼び出しは引き続き同じように機能します。HttpReader
reader.read()
それは好みの問題です。一般に、Javaは名詞を好みます(人々はこれがよりOOであると感じるため)、したがってFileReaderです。
Jeffreyが指摘したように、名詞の執着が不必要な冗長性につながることがあり、その時点で呼び出しは静的メソッドにラップされます。