多くのクラスは、intやstringなどのプリミティブ値を消費または拡張する傾向があります。 そのようなプリミティブはどのプラットフォームにも存在しますが、それらを使用すると手続き型コードにつながる可能性があります。 さらに、通常はカプセル化に違反し、誤った値の割り当てを許可します。
この問題は何度も議論されてきました。 何年も前に、 ジミー・ボガード は問題の優れた解釈と、それを解決するためのガイドを提供しました 。 AutoFixtureの開発により、私はしばらく前にこの問題の影響も受けました 。 実際、この投稿はプレースホルダーです。
私の投稿とジミーの投稿の両方が、文字列と整数型が郵便番号や電話番号などの概念を十分にカプセル化していないことを示していることに注意してください。
- 郵便番号が文字列で表される場合、null、string.Empty、「foo」、非常に長い文字列などを割り当てることができます。 Jimmyによって作成されたZipCodeクラスは概念をカプセル化し、正しい値でのみインスタンスを作成できるようにします。
- デンマークの電話番号が整数の場合、98、0、int.MaxValueなどを割り当てることができます。 前の例のDanishPhoneNumberクラスは概念をカプセル化し、正しい値でのみインスタンスを作成できるようにします。
カプセル化は、プリミティブ値によって表される概念がプリミティブ型の可能な値のいずれかを取ることができる限り、壊れたままです。 ただし、これはまれです。
デザインの「におい」
クラスはプリミティブ型を消費します。 ただし、さらに分析すると、タイプのすべての可能な値が有効であるとは限りません。
改訂されたデザイン
有効なインスタンスのみを作成できるようにするために、対応するセキュリティ式などを含む値オブジェクトにプリミティブ値をカプセル化します。
プリミティブは信頼できない傾向がありますが、値オブジェクトはそうではありません。