c# - 日付構造が不変なのはなぜですか？

Question

C＃のDateTimeやObj-CのNSDateなどのDate構造とオブジェクトが不変になっている理由について疑問に思っています。

この設計の背後にある理由と、「できるから」だけでなく、この情報を不変にすることの利点を探しています。

更新： 私には素晴らしい答えがありますが、特にJavaを対象とした同様の質問があったようですが、ここで見つけることができます：なぜ不変のクラスが必要なのですか？

それは私の質問への答えと組み合わせて非常に有益でした

Answer 1

不変性により、多くのことが簡単になります。自分の下で何かが変わる可能性があることを心配する必要がない場合は、作成する必要のないガードコードがたくさんあります。あなたがする必要のない多くの仮定があります。物事がうまくいかない可能性はたくさんあります。

文字列、日付、およびその他の種類の一般的なオブジェクトは、コンパイラ、フレームワークを単純化し、コンパイラが最適化を行うときに自由に仮定できることを意味するため、現代語では不変であることが一般的です。

要点は、低価格（値を変更したい場合は新しいオブジェクトを作成する必要がある）で、多くの実際のパフォーマンス、安定性、および信頼性を得るということです。

Answer 2

Objective Cについてはよくわかりませんが、C＃では、日付は単純な数値型で裏付けられています。また、数値は不変であるため、それに基づく日付も不変です。

Answer 3

Objective-Cについてはよくわかりませんが、DateTime変更可能にすることは実際には正しく行うのが非常に難しいため、不変です。

これは、メソッド（これにはプロパティが含まれます）からそれらを返す場合、元のコピーではなくコピーを取得するためです。これは、次のコードが期待どおりに機能しないことを意味する可能性があります。

someObject.Timestamp.SetSeconds(10.0);

はvoidSetSecondsであり、基礎となる構造を変更します。

Timestampオブジェクトのコピーを取得し、それに10秒を追加してから、そのコピーに対して何もしないため、何も実行されません。

Answer 4

.netで使用するために記述された構造の大部分（99.99％）は、（フレームワークで定義されているかユーザーコードで定義されているかにかかわらず）独立した値の固定コレクションを表しており、タイプに適した値の任意の組み合わせを受け入れることができます（例： 、および）Pointを含む、または単一の抽象エンティティを表します。.netのMicrosoftの構造使用ガイドラインでは、すべての構造が2番目のパターンに適合すると仮定すると、これらの異なる使用シナリオを区別できません。残念ながら、最初のタイプの構造は、2番目のタイプの構造にのみ実際に適した方法で記述されることがよくあります。 。しかし、たまたま、XYDateTime.netの構造は確かに独立した値のコレクションとして適格ではないため、ガイドラインはそれに完全に適しています。

まず第一に、aDateTimeが任意のフィールドを直接公開できる良い方法は実際にはありません。構造がカプセル化する独立した値の明確なセットがないDateTimeため、フィールドのタイプがどうあるべきかが不明確です。さらに、プロパティの多くは独立していないため、適切に変更することはできません。たとえば、DateTime2012年2月29日を表すaがあり、年を2011に設定してから月を3に設定した場合、結果の日付はどうなりますか？使用するメソッドを変更することは意味がDateTimeあります。残念ながら、vb.netとC＃はどちらも、ひどく壊れたコードのように静かにコードを置き換えることで、読み取り専用の構造体インスタンスで変更メソッドを呼び出すことができるように見せかけます。MyList[3].MutatingMethod();var temp=MyList[3]; temp.MutatingMethod();。読み取り専用インスタンスで属性でタグ付けされたメソッドを呼び出すと、壊れたコードではなくコンパイラエラーが発生するように属性を定義することで、Microsoftがこの問題を修正するのはかなり簡単ですが、残念ながら、Microsoftの言語の人々はそれを宣言します。可変構造は、言語を修正するよりも邪悪です。