.NET 5およびC＃9.0の新しいアイテムについて

こんにちは。



.NETは当初から使用してきました。最初から最新の.NETCore 3.1まで、本番環境のフレームワークのすべてのバージョンでソリューションが作成されています。



11月にリリースが予定されている.NET5のバージョンは、リリース候補2の形でリリースされたばかりです。5番目のバージョンは画期的なものになると長い間警告されてきました。それで終わります。フレームワークにクラシックとコアの2つのブランチがあった場合の.NET統合失調症。今、それらはエクスタシーでマージされ、1つの連続した.NETがあります。RC2を



リリースすでに完全に使い始めることができます-リリース前に新しい変更は期待されていません。見つかったバグの修正のみがあります。さらに、RC2にはすでに.NET専用の公式ウェブサイトがあります。



また、.NET 5およびC＃9のイノベーションの概要を紹介します。コード例を含むすべての情報は、.NETプラットフォームの開発者の公式ブログ（および他の多くのソース）から取得され、個人的に検証されています。

新しいネイティブとちょうど新しいタイプ

C＃と.NETは同時にネイティブタイプを追加しました：

• C＃のnintとnuint
• BCL内の対応するSystem.IntPtrおよびSystem.UIntPtr

これらのタイプを追加するためのポイントは、低レベルのAPIを使用した操作です。そして秘訣は、これらのタイプの実際のサイズは実行時にすでに決定されており、システムのビット数に依存することです。32ビットのものの場合は4バイト、64ビットのものの場合はそれぞれ8バイトになります。



ほとんどの場合、実際の作業ではこれらのタイプに遭遇することはありません。ただし、別の新しいタイプの場合と同様に、半分です。このタイプはBCLにのみ存在し、C＃にはまだ類似物はありません。浮動小数点値用の16ビットタイプです。地獄のような精度が必要ない場合に便利です。また、float型とdouble型は4バイトと8バイトを占めるため、値を格納するためのメモリを獲得できます。最も興味深いのは、これまでのところ、このタイプの一般的なものです算術演算は定義されておらず、floatまたはdoubleに明示的にキャストせずに、Half型の2つの変数を追加することもできません。つまり、このタイプの目的は、スペースを節約するために、純粋に実用的なものになりました。ただし、.NETおよびC＃の次のリリースでは、それに算術を追加する予定です。一年で。

ローカル関数の属性

以前は禁止されていたため、不便が生じていました。特に、ローカル関数のパラメータの属性をハングアップすることは不可能でした。これで、関数自体とそのパラメーターの両方に属性を設定できます。たとえば、次のようになります。

#nullable enable
private static void Process(string?[] lines, string mark)
{
    foreach (var line in lines)
    {
        if (IsValid(line))
        {
            // Processing logic...
        }
    }

    bool IsValid([NotNullWhen(true)] string? line)
    {
        return !string.IsNullOrEmpty(line) && line.Length >= mark.Length;
    }
}

静的ラムダ式

この機能のポイントは、ラムダ式が式自体の外部に存在するコンテキストおよびローカル変数をキャプチャできないようにすることです。一般に、ローカルコンテキストをキャプチャできるという事実は、開発に役立つことがよくあります。ただし、これがキャッチしにくいエラーの原因となる場合があります。



このようなエラーを回避するために、ラムダ式をstaticキーワードでマークできるようになりました。そしてこの場合、ローカル変数からこれとベースまで、ローカルコンテキストにアクセスできなくなります。



これはかなり包括的な使用例です：

static void SomeFunc(Func<int, int> f)
{
    Console.WriteLine(f(5));
}

static void Main(string[] args)
{
    int y1 = 10;
    const int y2 = 10;
    SomeFunc(i => i + y1);          //  15
    SomeFunc(static i => i + y1);   //  : y1    
    SomeFunc(static i => i + y2);   //  15
}

定数は静的ラムダをうまくキャプチャすることに注意してください。

拡張メソッドとしてのGetEnumerator

これで、GetEnumeratorメソッドを拡張メソッドにすることができます。これにより、以前は反復できなかったforeachを反復処理できます。たとえば-タプル。



これは、foreachを介してValueTupleに対して記述された拡張メソッドを使用して、ValueTupleを反復処理できるようになった場合の例です。

static class Program
{
    public static IEnumerator<T> GetEnumerator<T>(this ValueTuple<T, T, T, T, T> source)
    {
        yield return source.Item1;
        yield return source.Item2;
        yield return source.Item3;
        yield return source.Item4;
        yield return source.Item5;
    }

    static void Main(string[] args)
    {
        foreach(var item in (1,2,3,4,5))
        {
            System.Console.WriteLine(item);
        }
    }
}

このコードは、1から5までの数字をコンソールに出力します。

ラムダ式と匿名関数のパラメーターのパターンを破棄します

マイクロ改善。ラムダ式または匿名関数でパラメーターが必要ない場合は、パラメーターをアンダースコアに置き換えて、以下を無視することができます。

Func<int, int, int> someFunc1 = (_, _) => {return 5;};
Func<int, int, int> someFunc2 = (int _, int _) => {return 5;};
Func<int, int, int> someFunc3 = delegate (int _, int _) {return 5;};

Cのトップレベルステートメント＃

これは単純化されたC＃コード構造です。さて、最も単純なコードを書くことは本当に簡単に見えます：

using System;

Console.WriteLine("Hello World!");

そして、それはすべてうまくコンパイルされます。つまり、コンソール出力ステートメントを配置するメソッドを作成する必要はなく、メソッドを配置するクラスを記述する必要も、クラスを作成する名前名を定義する必要もありません。



ちなみに、将来的には、C＃開発者は、単純化された構文でトピックを開発し、使用しているシステムを取り除くことを考えています。明らかな場合。それまでの間、次のように書くだけでそれを取り除くことができます。

System.Console.WriteLine("Hello World!");

そして、それは実際には単一行の作業プログラムになります。



より複雑なオプションを使用できます。

using System;
using System.Runtime.InteropServices;

Console.WriteLine("Hello World!");
FromWhom();
Show.Excitement("Top-level programs can be brief, and can grow as slowly or quickly in complexity as you'd like", 8);

void FromWhom()
{
    Console.WriteLine($"From {RuntimeInformation.FrameworkDescription}");
}

internal class Show
{
    internal static void Excitement(string message, int levelOf)
    {
        Console.Write(message);

        for (int i = 0; i < levelOf; i++)
        {
            Console.Write("!");
        }

        Console.WriteLine();
    }
}

実際には、コンパイラ自体がこのすべてのコードを必要な名前名とクラスにラップします。あなたはそれについて知らないでしょう。



もちろん、この機能には制限があります。主なものは、これは1つのプロジェクトファイルでのみ実行できるということです。原則として、これは、Main（string [] args）関数の形式でプログラムへのエントリポイントを以前に作成したファイルで行うのが理にかなっています。同時に、Main関数自体をそこで定義することはできません。これは2番目の制限です。実際、構文が簡略化されたこのようなファイル自体がMain関数であり、パラメーターを持つ配列であるargs変数も暗黙的に含まれています。つまり、このコードは配列の長さもコンパイルして表示します。

System.Console.WriteLine(args.Length);

一般に、この機能は最も重要ではありませんが、デモンストレーションやトレーニングの目的には、それ自体に非常に適しています。詳細はこちら。

ifステートメントでのパターンマッチング

特定のタイプ ではないオブジェクト変数をチェックする必要があると想像してください。これまでは、次のように書く必要がありました。

if (!(vehicle is Car)) { ... }

しかし、C＃9.0を使用すると、人間で書くことができます。

if (vehicle is not Car) { ... }

また、いくつかのチェックをコンパクトに記録することも可能になりました。

if (context is {IsReachable: true, Length: > 1 })
{
    Console.WriteLine(context.Name);
}

この新しい表記は、次のような古き良き表記と同等です。

if (context is object && context.IsReachable && context.Length > 1 )
{
    Console.WriteLine(context.Name);
}

または、同じことを比較的新しい方法で書くこともできます（ただし、これはすでに昨日です）。

if (context?.IsReachable && context?.Length > 1 )
{
    Console.WriteLine(context.Name);
}

新しい構文では、ブール演算子を使用することもできます。また、括弧を使用して優先順位を付けることもできます。

if (context is {Length: > 0 and (< 10 or 25) })
{
    Console.WriteLine(context.Name);
}

そして、これらは通常のifでのパターンマッチングの単なる改善です。スイッチ式のパターンマッチングに追加したもの-読み進めてください。

スイッチ式のパターンマッチングの改善

switch式（switchステートメントと混同しないでください）では、パターンマッチングが大幅に改善されています。公式ドキュメントの例を見てみましょう。例は、特定の時間における特定の輸送の運賃を計算することに専念しています。これが最初の例です：

public decimal CalculateToll(object vehicle) =>
    vehicle switch
{
    Car c           => 2.00m,
    Taxi t          => 3.50m,
    Bus b           => 5.00m,
    DeliveryTruck t => 10.00m,
    { }             => throw new ArgumentException("Unknown vehicle type", nameof(vehicle)),
    null            => throw new ArgumentNullException(nameof(vehicle))
};

switchステートメントの最後の2行は新しいものです。中括弧は、null以外のオブジェクトを表します。また、matchingキーワードを使用してnullと照合できるようになりました。



これだけではありません。オブジェクトへのマッピングごとに、変数を作成する必要があることに注意してください。車の場合はc、タクシーの場合はtなどです。ただし、これらの変数は使用されません。このような場合、C＃8.0の破棄パターンをすでに使用できます。

public decimal CalculateToll(object vehicle) =>
    vehicle switch
{
    Car _           => 2.00m,
    Taxi _          => 3.50m,
    Bus _           => 5.00m,
    DeliveryTruck _ => 10.00m,
    // ...
};

ただし、C＃の9番目のバージョン以降、このような場合は何も記述できません。

public decimal CalculateToll(object vehicle) =>
    vehicle switch
{
    Car             => 2.00m,
    Taxi            => 3.50m,
    Bus             => 5.00m,
    DeliveryTruck   => 10.00m,
    // ...
};

スイッチ式の改善はそれだけではありません。より複雑な式を書くのが簡単になりました。たとえば、返される結果は、渡されたオブジェクトのプロパティ値に依存する必要があることがよくあります。これで、ifの組み合わせよりも短くて便利に書くことができます。

public static decimal CalculateToll(object vehicle) =>
    vehicle switch
{
    Car { Passengers: 0 } => 2.00m + 0.50m,
    Car { Passengers: 1 } => 2.0m,
    Car { Passengers: 2 } => 2.0m - 0.50m,
    Car => 2.00m - 1.0m,
    // ...
};

スイッチの最初の3行に注意してください。実際には、Passengersプロパティの値がチェックされ、等しい場合は、対応する結果が返されます。一致するものがない場合は、一般的なバリアントの値が返されます（スイッチ内の4行目）。ちなみに、プロパティ値は、渡された車両オブジェクトがnullでなく、Carクラスのインスタンスである場合にのみチェックされます。つまり、チェックするときにNull参照例外を恐れてはなりません。



しかし、それだけではありません。これで、switch式で、より便利なマッチングのための式を作成することもできます。

public static decimal CalculateToll(object vehicle) =>
    vehicle switch
{
    Bus b when ((double)b.Riders / (double)b.Capacity) < 0.50 => 5.00m + 2.00m,
    Bus b when ((double)b.Riders / (double)b.Capacity) > 0.90 => 5.00m - 1.00m,
    Bus => 5.00m,

    DeliveryTruck t when (t.GrossWeightClass >= 5000) => 10.00m + 5.00m,
    DeliveryTruck t when (t.GrossWeightClass >= 3000 && t.GrossWeightClass < 5000) => 10.00m,
    DeliveryTruck => 8.00m,
    // ...
};

そして、それだけではありません。スイッチ式の構文がネストされたスイッチ式に拡張され、複雑な条件の記述がさらに簡単になりました。

public static decimal CalculateToll(object vehicle) =>
    vehicle switch
{
    Car c => c.Passengers switch
    {
        0 => 2.00m + 0.5m,
        1 => 2.0m,
        2 => 2.0m - 0.5m,
        _ => 2.00m - 1.0m
    },
    // ...
};

その結果、すでに示したすべてのコード例を完全に接着すると、説明されているすべてのイノベーションをまとめた次の図が得られます。

public static decimal CalculateToll(object vehicle) =>
    vehicle switch
{
    Car c => c.Passengers switch
    {
        0 => 2.00m + 0.5m,
        1 => 2.0m,
        2 => 2.0m - 0.5m,
        _ => 2.00m - 1.0m
    },

    Taxi t => t.Fares switch
    {
        0 => 3.50m + 1.00m,
        1 => 3.50m,
        2 => 3.50m - 0.50m,
        _ => 3.50m - 1.00m
    },

    Bus b when ((double)b.Riders / (double)b.Capacity) < 0.50 => 5.00m + 2.00m,
    Bus b when ((double)b.Riders / (double)b.Capacity) > 0.90 => 5.00m - 1.00m,
    Bus => 5.00m,

    DeliveryTruck t when (t.GrossWeightClass >= 5000) => 10.00m + 5.00m,
    DeliveryTruck t when (t.GrossWeightClass >= 3000 && t.GrossWeightClass < 5000) => 10.00m,
    DeliveryTruck => 8.00m,

    null => throw new ArgumentNullException(nameof(vehicle)),
    _ => throw new ArgumentException(nameof(vehicle))
};

しかし、それだけではありません。別の例を次に示します。スイッチ式メカニズムを使用して、経過時間に基づいて負荷を決定する通常の関数：朝/夕方のラッシュアワー、昼と夜の期間：

private enum TimeBand
{
    MorningRush,
    Daytime,
    EveningRush,
    Overnight
}

private static TimeBand GetTimeBand(DateTime timeOfToll) =>
    timeOfToll.Hour switch
    {
        < 6 or > 19 => TimeBand.Overnight,
        < 10 => TimeBand.MorningRush,
        < 16 => TimeBand.Daytime,
        _ => TimeBand.EveningRush,
    };

ご覧のとおり、C＃9.0では、比較演算子<、>、<=、> =、および論理演算子and、またはnotを照合時に使用することもできます。



しかし、これは、くそー、終わりではありません。これで、switch式で...タプルを使用できます。これは、曜日、時刻、および移動方向（都市へ/から）に応じて、運賃の特定の係数を計算するコードの完全な例です。

private enum TimeBand
{
    MorningRush,
    Daytime,
    EveningRush,
    Overnight
}

private static bool IsWeekDay(DateTime timeOfToll) =>
    timeOfToll.DayOfWeek switch
{
    DayOfWeek.Saturday => false,
    DayOfWeek.Sunday => false,
    _ => true
};

private static TimeBand GetTimeBand(DateTime timeOfToll) =>
    timeOfToll.Hour switch
{
    < 6 or > 19 => TimeBand.Overnight,
    < 10 => TimeBand.MorningRush,
    < 16 => TimeBand.Daytime,
    _ => TimeBand.EveningRush,
};

public static decimal PeakTimePremiumFull(DateTime timeOfToll, bool inbound) =>
    (IsWeekDay(timeOfToll), GetTimeBand(timeOfToll), inbound) switch
{
    (true, TimeBand.MorningRush, true) => 2.00m,
    (true, TimeBand.MorningRush, false) => 1.00m,
    (true, TimeBand.Daytime, true) => 1.50m,
    (true, TimeBand.Daytime, false) => 1.50m,
    (true, TimeBand.EveningRush, true) => 1.00m,
    (true, TimeBand.EveningRush, false) => 2.00m,
    (true, TimeBand.Overnight, true) => 0.75m,
    (true, TimeBand.Overnight, false) => 0.75m,
    (false, TimeBand.MorningRush, true) => 1.00m,
    (false, TimeBand.MorningRush, false) => 1.00m,
    (false, TimeBand.Daytime, true) => 1.00m,
    (false, TimeBand.Daytime, false) => 1.00m,
    (false, TimeBand.EveningRush, true) => 1.00m,
    (false, TimeBand.EveningRush, false) => 1.00m,
    (false, TimeBand.Overnight, true) => 1.00m,
    (false, TimeBand.Overnight, false) => 1.00m,
};

PeakTimePremiumFullメソッドはマッチングにタプルを使用します。これはC＃9.0の新しいバージョンで可能になりました。ちなみに、コードをよく見ると、2つの最適化が示唆しています。

• 最後の8行は同じ値を返します。
• 昼と夜のトラフィックは同じ係数を持っています。

その結果、廃棄パターンを使用してメソッドコードを大幅に削減できます。

public static decimal PeakTimePremiumFull(DateTime timeOfToll, bool inbound) =>
    (IsWeekDay(timeOfToll), GetTimeBand(timeOfToll), inbound) switch
{
    (true, TimeBand.MorningRush, true)  => 2.00m,
    (true, TimeBand.MorningRush, false) => 1.00m,
    (true, TimeBand.Daytime,     _)     => 1.50m,
    (true, TimeBand.EveningRush, true)  => 1.00m,
    (true, TimeBand.EveningRush, false) => 2.00m,
    (true, TimeBand.Overnight,   _)     => 0.75m,
    (false, _,                   _)     => 1.00m,
};

よく見ると、このオプションを減らして、一般的な場合の係数1.0を取り出すことができます。

public static decimal PeakTimePremiumFull(DateTime timeOfToll, bool inbound) =>
    (IsWeekDay(timeOfToll), GetTimeBand(timeOfToll), inbound) switch
{
    (true, TimeBand.Overnight, _) => 0.75m,
    (true, TimeBand.Daytime, _) => 1.5m,
    (true, TimeBand.MorningRush, true) => 2.0m,
    (true, TimeBand.EveningRush, false) => 2.0m,
    _ => 1.0m,
};

念のため、明確にしておきます。比較は、リストされている順序で行われます。最初の一致で、対応する値が返され、それ以上の比較は行われません。

スイッチ式の更新タプルは、C＃8.0でも使用できます。この記事を書いた価値のない開発者は、少し賢くなっただけです。

そして最後に、タプルとオブジェクトプロパティの両方と照合するための新しい構文を示す別のクレイジーな例を次に示します。

public static bool IsAccessOkOfficial(Person user, Content content, int season) => 
    (user, content, season) switch 
{
    ({Type: Child}, {Type: ChildsPlay}, _)          => true,
    ({Type: Child}, _, _)                           => false,
    (_ , {Type: Public}, _)                         => true,
    ({Type: Monarch}, {Type: ForHerEyesOnly}, _)    => true,
    (OpenCaseFile f, {Type: ChildsPlay}, 4) when f.Name == "Sherlock Holmes"  => true,
    {Item1: OpenCaseFile {Type: var type}, Item2: {Name: var name}} 
        when type == PoorlyDefined && name.Contains("Sherrinford") && season >= 3 => true,
    (OpenCaseFile, var c, 4) when c.Name.Contains("Sherrinford")              => true,
    (OpenCaseFile {RiskLevel: >50 and <100 }, {Type: StateSecret}, 3) => true,
    _                                               => false,
};

これはすべてかなり珍しいように見えます。完全に理解するために、ソースを確認することをお勧めします。コードの完全な例があります。

新しい新しいだけでなく、基本的に改善されたターゲットタイピング

昔、C＃では、型自体がコンテキストから決定できるため、型名の代わりにvarを書くことが可能になりました（実際、これはターゲット型付けと呼ばれます）。つまり、次のエントリの代わりに：

SomeLongNamedType variable = new SomeLongNamedType();

よりコンパクトに書くことが可能になりました：

var variable = new SomeLongNamedType()

そして、コンパイラは変数自体のタイプを推測します。何年にもわたって、逆の構文が実装されました。

SomeLongNamedType variable = new ();

この構文は、変数を宣言するときだけでなく、コンパイラがすぐに型を推測できる他の多くの場合にも機能するという事実に特に感謝します。たとえば、パラメータをメソッドに渡し、メソッドから値を返す場合、次のようになります。

var result = SomeMethod(new (2020,10,01));

//...

public Car SomeMethod(DateTime p)
{
    //...

    return new() { Passengers = 2 };
}

この例では、SomeMethodを呼び出すときに、DateTimeタイプのパラメーターが簡略構文で作成されます。メソッドから返される値も同じ方法で作成されます。



この構文に実際にメリットがあるのは、コレクションを定義するときです。

List<DateTime> datesList = new()
{
    new(2020, 10, 01),
    new(2020, 10, 02),
    new(2020, 10, 03),
    new(2020, 10, 04),
    new(2020, 10, 05)
};

Car[] cars = 
{
    new() {Passengers = 2},
    new() {Passengers = 3},
    new() {Passengers = 4}
};

コレクションの要素を一覧表示するときに完全な型名を記述する必要がないため、コードが少しわかりやすくなります。

ターゲット型演算子?? そして？：

三元演算子？：C＃9.0で改善されました。以前は、返品タイプに完全に準拠する必要がありましたが、現在はよりスマートになっています。これは、以前のバージョンの言語では無効でしたが、9番目のバージョンではかなり合法であった式の例です。

int? result = b ? 0 : null; // nullable value type

以前は、ゼロからintに明示的にキャストする必要がありましたか？..現在は必要ありません。



また、新しいバージョンの言語では、次の構造を使用できます。

Person person = student ?? customer; // Shared base type

顧客と学生のタイプは、Personから派生していますが、技術的に異なります。以前のバージョンの言語では、明示的な型キャストなしでそのような構成を使用することはできませんでした。これで、コンパイラは意味を完全に理解します。

メソッドの戻りタイプをオーバーライドする

C＃9.0では、オーバーライドされたメソッドの戻りタイプをオーバーライドすることが許可されていました。要件は1つだけです。新しいタイプは、元のタイプ（共変）から継承する必要があります。次に例を示します。

abstract class Animal
{
    public abstract Food GetFood();
    ...
}
class Tiger : Animal
{
    public override Meat GetFood() => ...;
}

Tigerクラスでは、GetFoodメソッドの戻り値がFoodからMeatに再定義されました。肉が食物に由来するかどうかは今では大丈夫です。

initプロパティは実際には読み取り専用メンバーではありません

言語の新しいバージョンであるinit-propertiesに興味深い機能が登場しました。これらは、オブジェクトの初期初期化中にのみ設定できるプロパティです。これには読み取り専用のクラスメンバーが存在するように見えますが、実際には、さまざまな問題を解決できるさまざまなものです。initプロパティの違いと美しさを理解するために、次の例を示します。

Person employee = new () {
    Name = "Paul McCartney",
    Company = "High Technologies Center",
    CompanyAddress = new () {
        Country = "Russia",
        City = "Izhevsk",
        Line1 = "246, Karl Marx St."
    }
}

クラスのインスタンスを宣言するためのこの構文は、特にクラスのプロパティの中にオブジェクトが多い場合に非常に便利です。ただし、この構文には制限があります。対応するクラスプロパティは変更可能である必要があります。これは、これらのプロパティの初期化がコンストラクターの呼び出し後に行われるためです。つまり、例のPersonクラスは次のように宣言する必要があります。

class Person {
    //...
    public string Name {get; set;}
    public string Company {get; set;}
    public Address CompanyAddress {get; set;}
    //...
}

ただし、実際には、Nameプロパティは不変です。現在、この読み取り専用プロパティを作成する唯一の方法は、プライベートセッターを宣言することです。

class Person {
    //...
    public string Name {get; private set;}
    //...
}

ただし、この場合、中括弧内のプロパティに値を割り当てることで、クラスインスタンスを宣言するための便利な構文を使用する機能がすぐに失われます。また、Nameプロパティの値は、パラメータでクラスコンストラクタに渡すことによってのみ設定できます。ここで、CompanyAddressプロパティも実際には不変であると想像してください。一般的に、私は何度もそのような状況に陥り、常に2つの悪から選択しなければなりませんでした。

• たくさんのパラメータを備えた豪華なコンストラクタですが、読み取り専用クラスのすべてのプロパティ。
• オブジェクトを作成するための便利な構文ですが、読み取り/書き込みクラスのすべてのプロパティです。これを覚えておく必要があり、誤ってどこかで変更しないようにする必要があります。

この時点で、誰かがクラスの読み取り専用メンバーを思い出して、Personクラスのスタイルを次のように提案する可能性があります。

class Person {
    //...
    public readonly string Name;
    public readonly string Company;
    public readonly string CompanyAddress;
    //...
}

この方法はFengShuiによるだけでなく、便利な初期化の問題も解決しないと私は答えます。読み取り専用メンバーは、プライベートセッターを持つプロパティのように、コンストラクターでのみ設定できます。



しかし、C＃9.0では、この問題は解決されています。プロパティをinitプロパティとして定義すると、オブジェクトを作成するための便利な構文と、将来実際に不変のプロパティの両方が得られます。

class Person {
    public string Name { get; init; }
    public string Company { get; init; }
    public Address CompanyAddress { get; init; }
}

ちなみに、init-propertiesでは、コンストラクターと同様に、読み取り専用のクラスメンバーを初期化でき、次のように記述できます。

public class Person
{
    private readonly string name;
       
    public string Name
    { 
        get => name; 
        init => name = (value ?? throw new ArgumentNullException(nameof(Name)));
    }
}

レコードは合法化されたDTOです

不変のプロパティのトピックを続けて、私の意見では、言語の革新、つまりレコードタイプに行き着きます。このタイプは、プロパティだけでなく、不変の構造全体を便利に作成するように設計されています。別のタイプが登場する理由は単純です。すべての基準に従って機能し、アプリケーションのさまざまなレイヤーを分離するために常にDTOを作成します。 DTOは通常、ビジネスロジックを持たない、単なるフィールドのコレクションです。そして、原則として、これらのフィールドの値は、このDTOの存続期間中に変更されません。

.



DTO – Data Transfer Object. (DAL, BL, PL) - . «». -DTO' DAL BL, , DTO-, , DTO-, - ( HTML- JSON-).



— DTO-, - -, .



DTO- - . DTO-, AutoMapper - .



, DTO- .

そのため、何年にもわたって、C＃開発者は本当に必要な改善に到達しました。彼らはDTOモデルを別個のレコードタイプとして合法化しました。



これまで、私たちが作成した（そして大量に作成した）すべてのDTOモデルは通常のクラスでした。コンパイラーとランタイムについては、古典的な意味ではそうではありませんでしたが、他のすべてのクラスと違いはありませんでした。 DTOモデルに構造を使用した人はほとんどいません。これは、さまざまな理由で常に受け入れられるとは限りませんでした。



これで、レコード（以下、レコードと呼びます）を定義できます。これは、不変のDTOモデルを作成するために設計された特別な構造です。録音は、通常の意味で構造とクラスの中間に位置します。それはサブクラスとスーパーストラクチャーの両方です。レコードは依然として参照タイプであり、その後のすべての結果を伴います。ほとんどの場合、レコードは通常のクラスのように動作し、メソッドを含めることができ、継承を許可します（ただし、オブジェクトからではなく、他のレコードからのみです。ただし、レコードが明示的に何からも継承しない場合は、C＃のすべてと同じように暗黙的にオブジェクトから継承します）インターフェイスを実装できます。さらに、レコードを完全に不変にする必要はまったくありません。では、その意味はどこにあり、違いは何ですか？



エントリを作成してみましょう。

public record Person 
{
    public string LastName { get; }
    public string FirstName { get; }

    public Person(string first, string last) => (FirstName, LastName) = (first, last);
}

そして今ここにそれを使用する方法の例があります：

Person p1 = new ("Paul", "McCartney");
Person p2 = new ("Paul", "McCartney");

System.Console.WriteLine(p1 == p2);

この例は、コンソールにtrueを出力します。Personがクラスの場合、オブジェクトは参照によって比較されるため、falseがコンソールに出力されます。2つの参照変数は、同じオブジェクトを参照している場合にのみ等しくなります。しかし、それは録音には当てはまりません。レコードは、プライベートフィールドを含むすべてのフィールドの値によって比較されます。



前の例を続けて、次のコードを見てみましょう。

System.Console.WriteLine(p1);

クラスの場合、コンソールにクラスのフルネームが表示されます。ただし、エントリの場合、コンソールに次のように表示されます。

Person { LastName = McCartney, FirstName = Paul}

実際のところ、レコードの場合、ToString（）メソッドは暗黙的にオーバーライドされ、タイプ名ではなく、値を含むパブリックフィールドの完全なリストを表示します。同様に、レコードの場合、==および！=演算子は暗黙的に再定義されます。これにより、比較ロジックを変更できます。



レコードの継承で遊んでみましょう：

public record Teacher : Person
{
    public string Subject { get; }

    public Teacher(string first, string last, string sub)
        : base(first, last) => Subject = sub;
}

次に、異なるタイプの2つの投稿を作成し、それらを比較してみましょう。

Person p = new("Paul", "McCartney");
Teacher t = new("Paul", "McCartney", "Programming");

System.Console.WriteLine(p == t);

TeacherレコードはPersonから継承されますが、p変数とt変数は等しくなく、falseがコンソールに出力されます。これは、レコードのすべてのフィールドだけでなく、タイプについても比較が行われ、ここでのタイプが明らかに異なるためです。



また、継承されたレコードタイプの比較は許可されていますが（ただし意味がありません）、一般に異なるレコードタイプの比較は原則として許可されていません。

public record Person
{
    public string LastName { get; }
    public string FirstName { get; }

    public Person(string first, string last) => (FirstName, LastName) = (first, last);
}

public record Person2
{
    public string LastName { get; }
    public string FirstName { get; }

    public Person2(string first, string last) => (FirstName, LastName) = (first, last);
}

// ...

Person p = new("Paul", "McCartney");
Person2 p2 = new("Paul", "McCartney");
System.Console.WriteLine(p == p2);    //  

エントリは同じように見えますが、最後の行にコンパイルエラーがあります。同じタイプまたは継承されたタイプのレコードのみを比較できます。



レコードのもう1つの優れた機能は、withキーワードです。これにより、DTOモデルに変更を簡単に作成できます。例を見てください：

Person me = new("Steve", "Brown");
Person brother = me with { FirstName = "Paul" };

この例では、兄弟レコードの場合、FirstNameフィールドを除くすべてのフィールドの値がmeレコードから入力され、Paulに変更されます。



これまで、コンストラクター、プロパティなどの完全な定義を使用して、レコードを作成する従来の方法を見てきました。しかし、今では簡潔な方法もあります。

public record Person(string FirstName, string LastName);

public record Teacher(string FirstName, string LastName,
    string Subject)
    : Person(FirstName, LastName);

public sealed record Student(string FirstName,
    string LastName, int Level)
    : Person(FirstName, LastName);

エントリを簡単に定義すると、コンパイラがプロパティとコンストラクタを作成します。ただし、この機能には追加の機能があります。簡略表記を使用してプロパティとコンストラクターを定義できるだけでなく、同時に独自のメソッドをエントリに追加できます。

public record Pet(string Name)
{
    public void ShredTheFurniture() =>
        Console.WriteLine("Shredding furniture");
}

public record Dog(string Name) : Pet(Name)
{
    public void WagTail() =>
        Console.WriteLine("It's tail wagging time");

    public override string ToString()
    {
        StringBuilder s = new();
        base.PrintMembers(s);
        return $"{s.ToString()} is a dog";
    }
}

この場合、レコードのプロパティとコンストラクターも自動的に作成されます。ボイラープレートコードはますます少なくなっていますが、投稿にのみ適用されます。これは、クラスと構造では機能しません。



すでに述べたすべてに加えて、コンパイラはレコードのデコンストラクタを自動的に作成することもできます。

var person = new Person("Bill", "Wagner");

var (first, last) = person; //    
Console.WriteLine(first);
Console.WriteLine(last);

ただし、ILレベルでは、レコードは依然としてクラスです。ただし、確認がまだ見つかっていない疑いが1つあります。レコードは、実行時レベルのどこかで大幅に最適化される可能性があります。おそらく、特定のレコードが不変であることが事前にわかっているためです。これにより、少なくともマルチスレッド環境では最適化の機会が開かれ、開発者はこれに特別な努力を払う必要さえありません。



その間、すべてのDTOモデルをクラスからレコードに書き直しています。

.NETソースジェネレータ

ソースジェネレーター（以下、単にジェネレーターと呼びます）は、非常に興味深い機能です。ジェネレーターは、コンパイル段階で実行されるコードの一部であり、既にコンパイルされたコードを分析する機能があり、コンパイルされる追加のコードを生成できます。完全に明確ではない場合は、ジェネレーターが必要になる可能性がある場合の1つのかなり適切な例を次に示します。



ASP.NET Coreで作成したC＃/。NETWebアプリケーションを想像してみてください。このアプリケーションを起動すると、このアプリケーションが何で構成されているのか、そして何をすべきかを分析するための初期化のバックグラウンド作業が大量にあります。反射は必死に使用されます。その結果、アプリケーションの起動から最初の要求の処理の開始までの時間がひどく長くなる可能性があり、これは高負荷のサービスでは受け入れられません。ジェネレータは、この時間を短縮するのに役立ちます。コンパイル段階でも、すでにコンパイルされたアプリケーションを分析し、さらに、起動時にはるかに高速に初期化するために必要なコードを生成できます。



また、リフレクションを使用して実行時に使用されるオブジェクトのタイプを決定するライブラリもかなり多数あります（その中には多くのトップNugetパッケージがあります）。これにより、ジェネレーターを使用した最適化の大きな可能性が開かれ、この機能の作成者は、ライブラリ開発者からの適切な改善を期待しています。



コードジェネレーターは新しいトピックであり、この投稿の範囲に収まらないほど珍しいものです。さらに、最も単純な「Hello、world！」の例を見ることができます。このレビューのジェネレータ。



コードジェネレータに関連する2つの新機能があり、以下で説明します。

部分的な方法

C＃の部分クラスは長い間存在しており、その本来の目的は、特定の設計者によって生成されたコードをプログラマーによって作成されたコードから分離することです。部分的なメソッドはC＃9.0で調整されています。それらは次のようになります。

public partial class MyClass
{
    public partial int DoSomeWork(out string p);
}
public partial class MyClass
{
    public partial int DoSomeWork(out string p)
    {
        p = "test";
        System.Console.WriteLine("Partial method");
        return 5;
    }
}

この代理の例は、部分的なメソッドが通常のメソッドと本質的に変わらないことを示しています。値を返すことができ、出力変数を受け入れることができ、アクセス修飾子を持つことができます。



入手可能な情報から、部分的なメソッドは、使用が意図されているコードジェネレーターと密接に関連しています。

モジュール初期化子

この機能を導入する理由は3つあります。

• 最小限のオーバーヘッドで、ユーザーが何かを呼び出す必要がなく、ライブラリが起動時に1回限りの初期化を行うことができるようにします。
• 静的コンストラクターの既存の機能は、この役割にはあまり適していません。雨季は、静的コンストラクターを持つクラスが使用されているかどうかを最初に把握する必要があり（これらはルールです）、これにより測定可能な遅延が発生します。
• コードジェネレータには、明示的に呼び出す必要のない、ある種の初期化ロジックが必要です。

実際、この機能がリリースに含まれるためには、最後の点が決定的になっているようです。その結果、初期化であるメソッドをコーティングする必要がある新しい属性を思いつきました。

using System.Runtime.CompilerServices;
class C
{
    [ModuleInitializer]
    internal static void M1()
    {
        // ...
    }
}

この方法にはいくつかの制限があります。

• 静的である必要があります。
• パラメータがあってはなりません。
• 何も返さないはずです。
• ジェネリックでは機能しないはずです。
• 含まれているモジュールからアクセスできる必要があります。
  
  
  • 内部または公開である必要があります
  • ローカルメソッドである必要はありません

そして、次のように機能します。コンパイラは、ModuleInitializer属性でマークされたすべてのメソッドを見つけるとすぐに、それらすべてを呼び出す特別なコードを生成します。イニシャライザメソッドの呼び出し順序は指定できませんが、各コンパイルで同じになります。

結論

すでに投稿を公開しているので、.NET自体のニュースよりもC＃9.0言語のニュースに専念していることに気づきました。しかし、それはうまくいきました。