「パブリック/プライベート」静的メソッドの使用に反対する人はたくさんいます。私は運が悪かったので周りを検索し、静的メソッドの適切な使用を提唱している人を見つけようとしました。
メソッドが常にまとまりがあると仮定すると、パブリック静的メソッドを使用できる領域はどこにありますか?これらの方法はJavaと.NETで異なりますか(別名、どちらか一方の方が受け入れられますか)?
この最近のSO投稿は、このトピックに対する私の怒り/興味に拍車をかけました。
「パブリック/プライベート」静的メソッドの使用に反対する人はたくさんいます。私は運が悪かったので周りを検索し、静的メソッドの適切な使用を提唱している人を見つけようとしました。
メソッドが常にまとまりがあると仮定すると、パブリック静的メソッドを使用できる領域はどこにありますか?これらの方法はJavaと.NETで異なりますか(別名、どちらか一方の方が受け入れられますか)?
この最近のSO投稿は、このトピックに対する私の怒り/興味に拍車をかけました。
メソッドをユニットと見なすことができ、それ自体で効果的にテストできる場合は、パブリック静的メソッドを使用します。静的メソッドを使用する型に依存性注入やモックを実装するのは非常に困難です。
依存関係がほとんど/まったくなく、入力/出力が明確に定義されているユーティリティメソッドには静的メソッドを使用します。
静的メソッドは一般的にすべきではありません:
逆に、純粋関数(つまり副作用がない)は優れた静的メソッドになります。
もちろん、これは絶対的な教義と見なされるべきではありません。
静的メソッドを保持する型が返されるシナリオのような単純なファクトリでそれらを使用するのは公平だと思います。次の場合、それを言うのは大きな飛躍ではありません。
string.Empty;
正当な静的プロパティである場合:
string.GenerateRandomString();
正当な静的メソッドです。それでも、純粋なOOプログラマーはStringFactoryまたはRandomStringGeneratorクラスを好むかもしれませんが、それはすべて、線を引く場所に依存すると思います。
メソッドを静的としてマークすると、メソッドに渡されたオブジェクトの状態を変更しないことをコンシューマーに通知します。静的メソッドは、渡されたパラメーターに対して操作を実行する必要があり、内部フィールドに依存してはなりません。
あなたが参照している投稿で与えられている具体的なアドバイスは、静的メソッドの使用に反対するアドバイスではなく、静的メソッドが配置されている場所に関係していると思います。
典型的な使用法の1つは、シングルトンパターンを実装することです。
クラスのインスタンスの一部ではないメソッド、または「共有」変数を更新する場合は、静的/共有を使用します(スレッドセーフにすることを忘れないでください)。
通常、これは、これらのメソッドを含む別の「Manager」クラスにこれらのメソッドがあることを意味します。コンストラクターもプライベートとしてマークして、実装できないようにします。
補足:静的/共有メソッドはわずかに高速であり、CLRでの実装がOOPに関連しておらず、OOP言語(少なくとも.NET)の設計上の欠陥と関係があるインターフェイスでは許可されていないことを覚えています。 Javaに固有-ここで説明します。
静的メソッドは、グローバルオブジェクトインスタンスのインスタンスメソッドと同じセマンティクスを持っています。グローバルオブジェクトインスタンスに精通しているのでない限り、静的メソッドを使用するべきではありません。とはいえ、状況にもよります。時には、厄介なハックが正しいことです。