新しいフィールドキーワードがC#プロパティをどう改善するか

Overview of C# Properties and the Upgrade in C# 14

Timは、C# 14でのC#プロパティには大規模なアップグレードがあり、ビデオの焦点は自動プロパティが内部でどのように機能するかに影響を与える新しいフィールドキーワードであることを説明しています。 Timはまた、C# 14が.NET 10およびVisual Studio 2026と共に提供されることを述べていますが、機能自体は以前 for .NETバージョンでも動作する可能性があります。

彼はビデオを"この新機能を実際のコードでどのように使用するのか"という1つの特定の質問に答えるための、短く、焦点を絞った説明として構成しています。これにより、プロパティ定義の理論的議論ではなく、実践的なウォークスルーのトーンが設定されています。

Personクラスの例とオートプロパティ

約0:23のところで、TimはコンソールアプリケーションにおいてシンプルなパブリッククラスPersonを紹介します。 この人クラスにはいくつかのパブリックプロパティが含まれており、次のようになっています：

• public string FirstName

• public string LastName

• public int Age

Timはこれらが自動実装プロパティ（または自動的に実装されたプロパティとも呼ばれる）であると説明しています。 コンパイラがバックアップフィールドを舞台裏で自動的に作成するため、可視のプライベート変数やプライベートフィールドはありません。

彼はまた、自動実装されていないDemoプロパティを含めています。 代わりに、それはプライベート文字列のバックアップフィールド（_demo）を使用し、getアクセサのみを使用して読み取り専用プロパティを公開します。 この対比はビデオの後半で重要になります。

Program.csでのプロパティの使用

Timは次にProgramクラスに移り、パブリックスタティックvoidメイン（またはスタティックvoidメイン文字列argsとして概念的に）内でPersonオブジェクトがどのように作成されるかを示します。 彼は以下を使用して新しい人をインスタンス化します：

new Person { FirstName = "Tim", LastName = "Corey" }

Timは、プロパティはプライベートデータメンバーを隠しつつ、クラス外部からのアクセスを可能にすることを指摘しています。 彼は、姓、年齢、デモなどの値を取得し、プロパティがフィールドのように見える方法を示していますが、それらは実際には内部で特別なメソッドです。

自動プロパティでの無効な値の問題

約1:23で、Timは故意に無効な値を割り当てます：

person.LastName = null;

LastNameは必要でありnull許容ではないとマークされていませんが、割り当てはランタイムでも動作します。Timは自動プロパティが無効な値に対して自動的に保護しないことを説明しています。 コンパイラは警告しますが、セットメソッドは引き続き値を受け入れます。

これは、自動実装プロパティの主要な問題を示しています： それらは簡潔である一方で、検証を追加する組み込みの方法を提供しません。 無効なデータは通過し、暗黙のうちに仮定を破ります。

バックフィールドを持つ従来の完全なプロパティ

約2:58で、Timは開発者が以前のC#バージョンで行っていたことを示します。 彼はLastNameを次のように完全に実装されたプロパティに変換します：

• プライベート文字列のバックアップフィールド

• プロパティ値をチェックするセットアクセサ

• 無効な値に対してスローされる例外

このアプローチはプロパティのアクセサに対して完全な制御を与えますが、Timはそれがどれほど冗長になるかを強調しています。 プロパティは今や数行を取り、自動プロパティの一行シンタックスと比較されます。

彼はまた、自動プロパティから完全なプロパティに切り替えても、プロパティ名、アクセスレベル、および外部使用法が同じであるため、既存のコードが壊れることはないと説明しています。

中間的な立場としての新しいフィールドキーワード

4:19で、TimはC# 14での重要な改善を紹介します。完全なプロパティを書く代わりに、自動プロパティの構造を維持し、フィールドキーワードを使用してセットアクセサだけを修正します。

Timはフィールドが通常は隠されているコンパイラ生成のプライベートフィールドを表すことを説明しています。 フィールド=値の割り当てにより、開発者は独自のプライベート変数を宣言せずにプロパティ値を傍受して検証できます。

これにより、開発者が慣れ親しんでいるシンタックスを維持しながら柔軟性が追加されます。 Timは、これが自動プロパティと完全なプロパティの間に位置し、コードを削減しながら検証ロジックを可能にすることを説明しています。

スコープ付きバックアップフィールドとプロパティの分離

Timはフィールドキーワードがそれが登場するプロパティにスコープ化されていることを説明しています。 各プロパティには独自のバックアップフィールドがあり、クロスプロパティの干渉のリスクはありません。

同じシンタックスが別のプロパティに使用される場合—例えばFirstName—それはそのプロパティの独自のバックアップフィールドを指します。 この機能は予測可能であり、複数のパブリックプロパティで安全に使用できます。

数値プロパティ（Age）を検証する

約6:16で、Timは同じアプローチをパブリックint Ageプロパティに適用します。 彼は無効な負数値を割り当て、なぜそれが許されるべきでないかを説明します。

例外をスローする代わりに、Timは異なる戦略を示します：無効な値を無視します。 セットメソッドは、値が有効な範囲内にあるかどうかをチェックしてから、フィールドにそれを割り当てます。

これは、新しいアプローチがプライベートint年齢、数値の検証、および条件付きロジックに対して、プロパティを完全な実装に変換せずに同様にうまく機能することを示しています。

fieldキーワードとの命名衝突

その後、ティムは命名衝突という潜在的なエッジケースについて議論します。 クラスにすでにfieldという名前の変数が含まれている場合、プロパティ内での新しいキーワードと衝突する可能性があります。

彼はこれがどのようにして混乱と予期しない動作を引き起こすかを示しています。 ティムは、変数をthis.fieldまたは@fieldを使用して明示的に参照することで解決することを説明します。 これは、変数名とバックフィールドキーワードを区別します。

ティムは、特に既存のコードベースをアップグレードする際には、良いプラクティスとしてそのような変数の名前を変更することを強くお勧めします。

命名衝突が適用されない場合

ティムは、fieldキーワードがプロパティアクセサ内でのみ特別な意味を持つことを明確にします。 コンストラクタ、メソッド、またはクラスの他の部分では、fieldは通常の変数のように振る舞います。

この区別は、コンパイラが生成したバックフィールドが存在する時と存在しない時を開発者が理解するのに役立ちます。

ティム・コーリーの最終的な考え

ティムは、新しいfieldキーワードがどのように機能し、なぜC#のプロパティを改善するのかを要約するビデオを終了します。 これは、開発者が自動プロパティを使用し続けながら、検証、制御、および明確さを追加できるようにします。

彼は視聴者にこの機能を試し、コードスタイルにどのように適合するかを探り、命名規則について慎重に考えることを奨励します。 ティムは、この変更が不要な複雑さを追加することなくプロパティをより表現豊かにすることを強調しながらビデオを終了します。