コンストラクターパラメーターの検証のベストプラクティスは何ですか?
簡単なC#を考えてみます。
public class MyClass
{
public MyClass(string text)
{
if (String.IsNullOrEmpty(text))
throw new ArgumentException("Text cannot be empty");
// continue with normal construction
}
}
例外をスローすることは許容されますか?
私が遭遇した代替案は、インスタンス化する前の事前検証でした:
public class CallingClass
{
public MyClass MakeMyClass(string text)
{
if (String.IsNullOrEmpty(text))
{
MessageBox.Show("Text cannot be empty");
return null;
}
else
{
return new MyClass(text);
}
}
}
私はすべての検証をコンストラクターで実行する傾向があります。ほとんどの場合、不変オブジェクトを作成するため、これは必須です。あなたの特定のケースでは、これは許容できると思います。
if (string.IsNullOrEmpty(text))
throw new ArgumentException("message", "text");
.NET 4を使用している場合は、これを行うことができます。もちろん、これは、空白のみを含む文字列を無効と見なすかどうかによって異なります。
if (string.IsNullOrWhiteSpace(text))
throw new ArgumentException("message", "text");
多くの人が、コンストラクターは例外をスローすべきではないと述べています。 このページ のKyleGは、たとえばそれだけを行います。正直なところ、それができない理由は思いつきません。
C++では、コンストラクターから例外をスローすることはお勧めできません。参照されていない初期化されていないオブジェクトを含むメモリが割り当てられたままになるためです(つまり、従来のメモリリークです)。おそらくそれがスティグマの原因です-多くの古い学校のC++開発者がC#の学習を半分にアーシングし、C++から知っていることをそれに適用しました。対照的に、Objective-CではAppleは割り当てステップを初期化ステップから分離しているため、その言語のコンストラクターcan例外をスローします。
C#は、コンストラクタへの失敗した呼び出しからメモリをリークできません。 .NETフレームワークの一部のクラスでも、コンストラクターで例外がスローされます。
クラスをそのセマンティックの使用に関して一貫した状態にすることができない場合、例外IFFをスローします。それ以外の場合は行いません。オブジェクトが不整合な状態で存在することは絶対に許可しないでください。これには、完全なコンストラクターを提供しないことも含まれます(オブジェクトが実際に完全に構築される前に空のコンストラクター+ initialize()を用意するなど)...ただ言うだけです!
ピンチでは、誰もがそれを行います。先日、非常に狭い範囲で使用される非常に狭いオブジェクトについて行いました。いつの日か、私や他の誰かが実際にはそのスリップの代償を払うでしょう。
「コンストラクタ」とは、クライアントがオブジェクトを構築するために呼び出すものを意味することに注意してください。これは、 "Constructor"という名前の実際のコンストラクト以外の簡単なものでもかまいません。たとえば、C++でのこのようなものは、IMNSHOの原則に違反しません。
struct funky_object
{
...
private:
funky_object();
bool initialize(std::string);
friend boost::optional<funky_object> build_funky(std::string);
};
boost::optional<funky_object> build_funky(std::string str)
{
funky_object fo;
if (fo.initialize(str)) return fo;
return boost::optional<funky_object>();
}
funky_object
を作成する唯一の方法はbuild_funky
を呼び出すことであるため、実際の「コンストラクタ」がジョブを完了しなくても、無効なオブジェクトの存在を許可しないという原則はそのまま残ります。
それは疑わしい利益(多分損失さえ)のための多くの余分な仕事です。私はまだ例外ルートを好みます。
この場合、ファクトリーメソッドを使用します。基本的に、クラスにはプライベートコンストラクタのみを設定し、オブジェクトのインスタンスを返すファクトリメソッドを設定します。初期パラメーターが無効な場合は、nullを返し、呼び出し元のコードに処理を決定させます。
public class MyClass
{
private MyClass(string text)
{
//normal construction
}
public static MyClass MakeMyClass(string text)
{
if (String.IsNullOrEmpty(text))
return null;
else
return new MyClass(text);
}
}
public class CallingClass
{
public MyClass MakeMyClass(string text)
{
var cls = MyClass.MakeMyClass(text);
if(cls == null)
//show messagebox or throw exception
return cls;
}
}
条件が例外的でない限り、例外をスローしないでください。この場合、空の値を簡単に渡すことができると思います。その場合、このパターンを使用することで、MyClassの状態を有効に保ちながら、例外とそれに伴うパフォーマンスの低下を回避できます。
これらのガイドラインに合理的に疑問を投げかけ、「しかし、私はこれらの規則に従わないので、私のコードは正常に動作します!」それに対して、私は「そうでなくなるまで、それは本当かもしれない」と答えるでしょう。
私の好みはデフォルトを設定することですが、Javaにはこのようなことを行う「Apache Commons」ライブラリがあり、それもかなり良いアイデアだと思います。私はわかりません。無効な値がオブジェクトを使用できない状態にする場合に例外をスローすることに関する問題。文字列は良い例ではありませんが、貧しい人のDIの場合はどうなりますか?null
は、たとえばICustomerRepository
インターフェースの代わりに渡されました。このような状況では、例外をスローすることが処理の正しい方法だと思います。
MyClassが何をしているのかによります。 MyClassが実際にデータリポジトリクラスであり、パラメーターテキストが接続文字列である場合、ベストプラクティスはArgumentExceptionをスローすることです。ただし、MyClassが(たとえば)StringBuilderクラスの場合は、空白のままにしておくことができます。
したがって、それはメソッドに対するパラメーターテキストの重要性に依存します。オブジェクトはnullまたは空白の値で意味がありますか?