上手。data.Count() != 3 || data.IsCorrect()
。カウントが3の場合、データが正しくないということです。では、内部でチェックを行う代わりに、追加のif条件を使用するのはなぜですか。
if (data == null || data.IsCorrect())
{
//error...
}
アップデート
検証ロジックをクラス内に移動することの意味について混乱しているようです。すべてのクラスは、適切なOOPで何が有効な状態であるかを判断する責任があります。これはカプセル化と呼ばれます。
クラス自体の代わりに呼び出し元に何が正しいかどうかを判断させるというこの全体的なアイデアは、OR / M、マッパーなどの導入以来、ますます出現しています。しかし、実際には、自分の情報を検証しないクラスはそうではありません。本当に適切に設計されたOOPクラス。それらはDTOのような単なるコンテナです。
それによる危険は、呼び出しコードのすべてのブロックが、DTOに正しく有効な情報が含まれていることを確認する責任があることです。つまりn
、コードには、だけでなくバグが発生する可能性のある場所があります1
。
そのため、すべての検証ロジックを、IsCorrect
またはそれを呼び出したいものの内部に移動することをお勧めします。しかし、本当に基本的なOOPの原則に従ってコーディングしたい場合は、クラスが一貫性のない状態にならないようにする必要があります。そして、それは私が以下のブログ投稿で説明するように行われます。
http://blog.gauffin.org/2012/06/protect-your-data/