「原始的な強迫観念」を許す正当な理由は「ヨーヨーの問題を回避する」ことですか？

よると、原始的強迫観念ではないコードのにおいがある場合は？、Stringオブジェクトの代わりに郵便番号を表すZipCodeオブジェクトを作成する必要があります。

しかし、私の経験では、私は見たいです

public class Address{
    public String zipCode;
}

の代わりに

public class Address{
    public ZipCode zipCode;
}

後者では、プログラムを理解するためにZipCodeクラスに移動する必要があると思うからです。

そして、私はすべてのプリミティブデータフィールドがあるかのように感じているクラスに置き換えた場合、私は定義を参照するために多くのクラス間を移動する必要があると考えているから苦しみヨーヨー問題（アンチパターン）。

そこで、ZipCodeメソッドを新しいクラスに移動したいと思います。例えば：

古い：

public class ZipCode{
    public boolean validate(String zipCode){
    }
}

新着：

public class ZipCodeHelper{
    public static boolean validate(String zipCode){
    }
}

そのため、郵便番号を検証する必要があるのはZipCodeHelperクラスに依存するだけです。そして、私は原始的な強迫観念を保持する別の「利点」を見つけました。たとえば、文字列列zipCodeを持つアドレステーブルなど、クラスがシリアル化された形式のように見えます。

私の質問は、「ヨーヨーの問題を回避する」（クラス定義間を移動する）が「原始的な強迫観念」を許可する正当な理由ですか？

Addressクラスを理解するために、ZipCodeクラスにヨーヨーする必要はないという前提です。ZipCodeが適切に設計されている場合、Addressクラスを読み取るだけで、ZipCodeが何をするかが明確になります。

プログラムはエンドツーエンドで読み取られません-通常、プログラムは非常に複雑であるため、これを実現できません。プログラム内のすべてのコードを同時に念頭に置くことはできません。したがって、抽象化とカプセル化を使用してプログラムを意味のある単位に「チャンク」するので、依存するすべてのコードを読まなくてもプログラムの一部（Addressクラスなど）を見ることができます。

たとえば、コード内で文字列に遭遇するたびに、文字列のソースコードを読むことにヨーヨーをしないでください。

クラスの名前をZipCodeからZipCodeHelperに変更すると、2つの別個の概念が存在することが示唆されます。zipコードとzipコードヘルパーです。そのため、2倍複雑です。そして今、型システムは、同じ型を持っているため、任意の文字列と有効な郵便番号を区別するのに役立ちません。これが「強迫観念」が適切な場所です。プリミティブの周りの単純なラッパータイプを避けたいという理由だけで、より複雑で安全性の低い代替案を提案しています。

この特定のタイプに依存する検証やその他のロジックがない場合、プリミティブを使用することは正当です。しかし、ロジックを追加するとすぐに、このロジックがタイプでカプセル化されていると、はるかに簡単になります。

シリアル化に関しては、使用しているフレームワークの制限のように思えます。確かに、ZipCodeを文字列にシリアル化するか、データベースの列にマップできるはずです。

できる場合：

new ZipCode("totally invalid zip code");

また、ZipCodeのコンストラクターは次のことを行います。

ZipCodeHelper.validate("totally invalid zip code");

次に、カプセル化を解除し、ZipCodeクラスにかなり愚かな依存関係を追加しました。コンストラクターが呼び出さない場合、ZipCodeHelper.validate(...)実際に強制することなく、独自のアイランドでロジックを分離しています。無効な郵便番号を作成できます。

validateこの方法は、郵便番号のクラスの静的メソッドである必要があります。これで、「有効な」郵便番号の知識がZipCodeクラスにバンドルされます。コード例がJavaのように見えることを考えると、誤った形式が指定された場合、ZipCodeのコンストラクターは例外をスローする必要があります。

public class ZipCode {
    private String zipCode;

    public ZipCode(string zipCode) {
        if (!validate(zipCode))
            throw new IllegalFormatException("Invalid zip code");

        this.zipCode = zipCode;
    }

    public static bool validate(String zipCode) {
        // logic to check format
    }

    @Override
    public String toString() {
        return zipCode;
    }
}

コンストラクターは形式をチェックして例外をスローし、それによって無効な郵便番号の作成を防ぎます。また、静的validateメソッドは他のコードで使用できるため、形式をチェックするロジックはZipCodeクラスにカプセル化されます。

ZipCodeクラスのこのバリアントには「ヨーヨー」はありません。適切なオブジェクト指向プログラミングと呼ばれています。

また、ここでは国際化を無視します。これにより、ZipCodeFormatまたはPostalService（PostalService.isValidPostalCode（...）、PostalService.parsePostalCode（...）など）と呼ばれる別のクラスが必要になる場合があります。

この質問に何度も取り組んでいるなら、おそらくあなたが使用する言語は仕事にふさわしいツールではないでしょうか？この種の「ドメイン型のプリミティブ」は、たとえばF＃で簡単に表現できます。

たとえば、次のように書くことができます。

type ZipCode = ZipCode of string
type Town = Town of string

type Adress = {
  zipCode: ZipCode
  town: Town
  //etc
}

let adress1 = {
  zipCode = ZipCode "90210"
  town = Town "Beverly Hills"
}

let faultyAdress = {
  zipCode = "12345"  // <-Compiler error
  town = adress1.zipCode // <- Compiler error
}

これは、異なるエンティティのIDを比較するなど、よくある間違いを回避するのに非常に便利です。そして、これらの型指定されたプリミティブはC＃やJavaクラスよりもはるかに軽量なので、実際にそれらを使用することになります。

答えは、郵便番号で実際に何をしたいかによって完全に異なります。2つの極端な可能性があります。

（1）すべての住所は、単一の国にあることが保証されています。例外はありません。（たとえば、外国の顧客、または外国の顧客のために働いている間、個人住所が海外にある従業員はいません。）この国には郵便番号があり、深刻な問題が発生することはありません（つまり、自由形式の入力は不要です） 「現在はD4B 6N2ですが、これは2週間ごとに変わります」など）。郵便番号は、宛先指定だけでなく、支払い情報の検証などの目的にも使用されます。-これらの状況では、郵便番号クラスは非常に理にかなっています。

（2）住所はほぼすべての国に存在する可能性があるため、ZIPコードの有無にかかわらず（および数千の奇妙な例外や特殊なケースを含む）数十または数百のアドレス指定スキームが関連します。「ZIP」コードは、ZIPコードが使用されている国の人々に、忘れずに提供することを思い出させるためにのみ求められます。アドレスは、誰かがアカウントへのアクセスを失い、名前とアドレスを証明できる場合にのみ使用されるため、アクセスが復元されます。-これらの状況では、関連するすべての国の郵便番号クラスは多大な労力を費やします。幸いなことに、それらはまったく必要ありません。

他の回答では、OOドメインモデリングと、より豊富な型を使用して価値を表現する方法について説明しました。

特にあなたが投稿したコード例を考えると、私は同意しません。

しかし、それが実際にあなたの質問のタイトルに答えるかどうかも疑問に思います。

次のシナリオを検討してください（私が取り組んでいる実際のプロジェクトから抜粋）：

中央サーバーと通信するフィールドデバイス上にリモートアプリケーションがあります。デバイスエントリのDBフィールドの1つは、フィールドデバイスが存在する住所の郵便番号です。あなたは郵便番号（またはその問題の残りのアドレスのいずれか）を気にしません。それを気にするすべての人々はHTTP境界の反対側にいます：あなたはたまたまデータの唯一の真実の源です。ドメインモデリングには場所がありません。それを記録し、検証し、保存し、要求に応じてJSON blobでシャッフルして別の場所に移動します。

このシナリオでは、SQLの正規表現の制約（またはそのORMに相当）で、インサートの検証を超えて何の多くを行うことで、おそらく行き過ぎYAGNI品種の。

ZipCodeあなたの場合は抽象化にのみ意味を作ることができるAddressクラスも持っていなかったTownNameプロパティを。それ以外の場合は、抽象化が半分になります。郵便番号は町を指定しますが、これらの2つの関連情報は異なるクラスにあります。あまり意味がありません。

しかし、それでも、それはまだ正しいアプリケーション（またはむしろソリューション）ではありません。私が理解しているように、これは主に2つのことに焦点を当てています：

1. 特にプリミティブのコレクションが必要な場合、メソッドの入力（または出力）値としてプリミティブを使用します。
2. これらの一部を独自のサブクラスにグループ化する必要があるかどうかを再検討せずに、時間とともに余分なプロパティを成長させるクラス。

あなたの場合もそうではありません。住所は、明確に必要なプロパティ（通り、番号、郵便番号、町、州、国、...）を含む明確に定義された概念です。地球上の場所を指定するという単一の責任があるため、このデータを分割する理由はほとんどありません。アドレスが意味を持つためには、これらすべてのフィールドが必要です。アドレスの半分は無意味です。

これは、さらに細分化する必要がないことを知る方法です。それ以上細分化すると、Addressクラスの機能的な意図が損なわれます。同様に、ドメインで（人が接続NameされていPersonないName）意味のある概念でない限り、クラスでサブクラスを使用する必要はありません。それは（通常）そうではありません。名前は人を識別するために使用され、通常、それ自体には価値がありません。

記事から：

より一般的には、ヨーヨーの問題は、人が概念を理解するために異なる情報源をめくり続けなければならない状況を指すこともあります。

ソースコードは、書かれているよりもはるかに頻繁に読み取られます。したがって、多くのファイルを切り替える必要があるというヨーヨーの問題が懸念されます。

しかし、なし（互いの間で前後に呼び出す）深く相互に依存するモジュールやクラスを扱うとき、ヨーヨー問題は、はるかに関連した感じ。これらは読むべき特別な種類の悪夢であり、ヨーヨーの問題の考案者が念頭に置いていたものと思われます。

ただし、はい、抽象化の層が多すぎないようにすることが重要です！

すべての非自明な抽象化は、ある程度、漏れやすいです。-漏れのある抽象化の法則。

たとえば、mmmaaaの答えにある「Addressクラスを理解するためにZipCodeクラスに[（visit）]ヨーヨーする必要はない」という仮定に同意しません。私の経験では、あなたはそうしている -少なくとも最初の数回はコードを読んだ。他の人が指摘しているようしかし、そこにある時はZipCode、クラスが適切です。

YAGNI（Ya Ai n't Gonna Need It）は、ラザニアコード（レイヤーが多すぎるコード）を避けるために従うべき優れたパターンです-型やクラスなどの抽象化はプログラマーを支援するために存在し、そうでない場合は使用しないでください援助。

私は個人的に「コードの行を保存する」ことを目指しています（そしてもちろん関連する「ファイル/モジュール/クラスを保存する」など）。私は「プリミティブに取りつかれた」という言い回しを適用する人がいると確信しています- ラベル、パターン、アンチパターンを心配するよりも、推論しやすいコードを持つことが重要です。関数、モジュール/ファイル/クラスを作成するとき、または関数を共通の場所に配置するときの正しい選択は、非常に状況的です。私は、3-100行関数、80-500行ファイル、および再利用可能なライブラリコード（SLOC-コメントや定型文を含まない。通常、必須の行ごとに少なくとも1つの追加SLOCが必要です。ボイラープレート）。

最もポジティブなパターンは、開発者が必要なときにまさにそれを行っている開発者から生じています。同じ問題を解決せずにパターンを適用しようとするよりも、読み取り可能なコードを記述する方法を学ぶことがはるかに重要です。優れた開発者であれば、ファクトリパターンを実装することができます。これは、問題に最適な珍しいケースでは、これまで見たことがないものです。私はファクトリー・パターン、オブザーバー・パターン、そしておそらく何百もの名前を知らずに使用しました（つまり、「変数割り当てパターン」はありますか？）。楽しい実験のために、JS 言語にいくつのGoFパターンが組み込まれているのかを確認します。2009年に12〜15後にカウントを停止しました。Factoryパターンは、たとえばJSコンストラクターからオブジェクトを返すだけです。 WidgetFactory。

そう- はい、時には ZipCode良いクラスです。しかし、いや、ヨーヨーの問題は厳密には関係ありません。

ヨーヨーの問題は、前後に反転する必要がある場合にのみ関係します。これは、1つまたは2つのもの（時には両方）によって引き起こされます。

1. 悪いネーミング。ZipCodeは問題ないように見えますが、ZoneImprovementPlanCodeでは、ほとんどの人（および感心しない人）による外観が必要になります。
2. 不適切なカップリング。ZipCodeクラスに市外局番のルックアップがあるとします。便利だから理にかなっていると思うかもしれませんが、実際にはZipCodeとは関係ありません。

名前を見て、それが何をするのかについて合理的な考えを持ち、メソッドとプロパティが合理的に明白なことをすることができるなら、コードを見に行く必要はなく、ただそれを使うことができます。それがそもそもクラスの重要なポイントです。これらは、単独で使用および開発できるモジュール式のコードです。クラスのAPI以外を調べて、クラスの機能を確認する必要がある場合、せいぜい部分的な障害です。

覚えておいて、特効薬はありません。高速でクロールする必要がある非常にシンプルなアプリを作成している場合は、シンプルな文字列で十分です。ただし、98％の時間で、DDDでEric Evansが説明したValue Objectが最適です。値オブジェクトが提供するすべての利点を簡単に見ることができます。