2011-01-12 3 views
4

私は何かに解決策を書くたびに、多くの静的なクラスを使用するか、まったく使用しない傾向があります。たとえば最近のプロジェクトでは、いくつかの文字列/ bool/datetimeデータをいくつかのフープで送信しなければならず、静的でないものはこのデータ保持クラスだけでした。他のすべて(3つの相当なクラスは処理責任が異なります)は静的でした。いつ静的なクラスのために行くか?

私がここで求めているのは、これらの「プロセスX、出力Y」の場合に静的なクラスを使用しないようにする必要があるときの入力です。彼らが働いている限り、いつもそれらを使用しても構わないのですか?スケーラビリティ、プラグインサポートなどについて足で自分を撃っていますか?

ここで質問するのはOKです。私は、静的なクラスが "より良い"かどうかについての議論を求めているわけではありません。

+1

私の頭に浮かぶ最初のことは、データに何らかの操作が必要であれば、「データ保持クラス」に責任を負わせることができなかった理由です。それは余分な静的クラスの必要性を避け、不要な結合を減らします。 –

+2

これはすでに広範にカバーされていますので、始めにこれらのリンクを試してください:[静的汎用クラスの使用?](http://stackoverflow.com/questions/2685046/uses-for-static-generic-classes)&[Extensionメソッド対静的ユーティリティクラス](http://stackoverflow.com/questions/4646328/extension-methods-vs-static-utility-class) – slugster

+1

VS 2008のコード解析ツールは、常にメソッド/クラスを静的にすることを推奨します。インスタンスデータを持っていない、または使用していない。これはいい練習ですか? – Polyfun

答えて

2

まだ2つの質問は同じままです。静的クラスの主な関心事は、継承とアクセシビリティです。

静的なクラス(最悪の場合はpublic)を使用すると、誰もがプロセスと関数にアクセスできます。ほとんどの時間はあなたが望むものではありません。いくつかのオブジェクトがあなたの関数にアクセスしていくつかの変更を行うのは容易ではありません。したがって、依存性注入は使いやすいです。 (変更するオブジェクトをパラメータに渡します。この場合はprocess-objectです)。

他の人があなたのprocess-objectを操作しないように、何らかのシングルトンパターン(あるいはシングルトンパターン)を使用しようとしないでください。何かを変更する必要がある場合は、関数のパラメータにオブジェクトを渡すことができます。そして、あなたはあなたのprocess-objectを保持する1人のマネージャーを持つことができます。他人は物に着くべきではありません。

また、静的クラスは継承が困難です。静的メソッドをオーバーライドするのはちょっと変わったようです。したがって、プロセスが唯一のプロセスではなく、より特定のプロセスが作成されることが確実であれば、静的なクラスも回避する必要があります。

1

静的クラスは、小さなデータコンテナや一般的なメソッドでよく使用されます。必要な場合を除き、大量のデータを含むべきではありません。これらのクラスは拡張不可能です。

4

私が書くコードのほとんど:

  • 依存性の注入/ IoCのを使用しますので、私はちょうどほとんどすべてのためのオブジェクトを使用

テスト可能/ mockableする必要があります。

私はまだのようなもののために静を使用してください:

  • 拡張メソッド
  • 定数
  • ヘルパー/ユーティリティメソッド(前拡張メソッド)
  • 演算子メソッド
1

メソッドが1つしかない場合は、静的メソッドを使用することをお勧めします。この場合、クラスのインスタンスを作成することはほとんど意味がありません

静的なプロパティは、フィールドが少しでもglobal variableのように動作するようにすることができます。これは一致するデザインパターンですSingleton pattern

アプリケーション全体で消費する必要があるトラッキング状態に静的プロパティを使用します。私の仕事のオブジェクトに関連した残りのすべてのための

は、(明らかにマイナーな例外を除いて)移動するための方法である

1

静力学の広範な使用を作り、コンクリートにあなたのアプリケーションをputingようなものです。非常に一般的なユーティリティ/ヘルパーメソッドのような非常に特殊な状況を除いて、それらは避けるべきです。素敵なリストがdjeegの以前の回答に掲載されました。

1

あなたが説明したように静的なクラスを使用する際の主な問題は、依存関係がハードワイヤードであることです。クラスAがクラスBのフィーチャを使用する必要がある場合は、明示的にそれを知っていなければなりません。

これは必ずしも問題ではありませんが、コードが大きくなるにつれて、新しい要件に対応するためにプログラムの動作を変更することがより困難になることがあります。たとえば、プログラムの動作を構成可能にしたい場合は、コード内に明示的に/ switchが必要となるため、困難になります。そうしないと、クラスをインターフェイスに依存させ、実装を入れ替えることができます。

要するに、遭遇する可能性のある問題を解決するための良い解決策として知られているよく知られているデザインパターンを使用しないようにしています。

1

私は通常、クラスで静的メソッドを使用しないようにします。私が何らかのデータにグローバルにアクセスする必要があるならば、少なくともシングルトンでクラスをラップするでしょう。大規模なプロジェクトの場合は、Inversion of Controlコンテナを使用して、「グローバル」インスタンスをインスタンス化してシングルトンの方法で注入することをお勧めします。

関連する問題