変数

【C#】dynamicとExpandoObjectで自由にプロパティを操る動的オブジェクト活用術

2025-04-30更新日: 2025-04-30

C#のdynamicはコンパイル時の型チェックを後回しにし、実行時にメンバー解決を行う特別な型です。

静的型の厳密さを手放す代わりに、XMLやJSON、COMなど多様なデータとシームレスにやり取りでき、柔軟なコードが書けます。

ただし補完機能の弱体化や実行時例外、速度低下の懸念があるため、用途を絞って使うのが安心です。

目次から探す

dynamicとは
- 動的バインディングの仕組み
- varとの違い
ExpandoObjectの基礎
基本的な使い方
典型的なユースケース
パフォーマンスと最適化
型安全性とメンテナンス
エラーハンドリング
- RuntimeBinderExceptionの対処
- 動的呼び出し失敗のデバッグ
非同期処理との組み合わせ
- async/awaitでの注意点
- タスク戻り値のラッピング
高度なトピック
代替アプローチ
よくある落とし穴
ベストプラクティス集
まとめ

dynamicとは

C#のdynamic型は、コンパイル時に型チェックを行わず、実行時に型が決定する特別な型です。

これにより、プログラムの柔軟性が大幅に向上し、動的にプロパティやメソッドを操作できるようになります。

ここでは、dynamicの基本的な仕組みや動的バインディングの背景について詳しく解説します。

動的バインディングの仕組み

C#は通常、静的型付け言語として知られており、変数の型はコンパイル時に決定されます。

しかし、dynamic型を使うと、コンパイル時には型のチェックを行わず、実行時にメンバーの解決を行う「動的バインディング」が適用されます。

これにより、実行時のオブジェクトの状態に応じて柔軟にメソッドやプロパティを呼び出せるようになります。

DLRの役割

dynamic型の動的バインディングは、.NET Framework 4.0から導入された「Dynamic Language Runtime(DLR)」によって実現されています。

DLRは、動的言語の特徴を.NET上でサポートするためのランタイムで、C#のdynamic型もこの仕組みを利用しています。

DLRは以下の役割を担っています。

動的なメンバーアクセスの解決

実行時にオブジェクトのメンバー(プロパティやメソッド)を調べ、呼び出し可能かどうかを判断します。

動的な型情報の管理

実行時にオブジェクトの型情報を保持し、必要に応じて型変換やメソッドのオーバーロード解決を行います。

パフォーマンスの最適化

動的呼び出しの結果をキャッシュし、同じ呼び出しが繰り返される場合のパフォーマンス低下を抑えます。

このように、DLRは動的言語の柔軟性を.NET環境に持ち込みつつ、できるだけ効率的に動作するよう設計されています。

コンパイラの処理フロー

dynamic型の変数に対する操作は、コンパイル時に通常の静的な型チェックをスキップします。

代わりに、コンパイラは動的呼び出しのための特別なコードを生成し、実行時にDLRが呼び出し先を解決します。

具体的な処理の流れは以下の通りです。

コンパイル時

dynamic型の変数に対するメンバーアクセスやメソッド呼び出しは、静的な型チェックを行わずに、動的呼び出しのためのバインディングコードを生成します
例えば、obj.SomeMethod()のような呼び出しは、objの型が不明なため、実行時に解決されるようにします

実行時

DLRが呼び出し先のオブジェクトの型を調べ、指定されたメソッドやプロパティが存在するかを確認します
存在すれば呼び出しを実行し、存在しなければ例外をスローします
呼び出し結果はキャッシュされ、同じ呼び出しが繰り返される場合は高速化されます

この仕組みにより、dynamic型は静的型付けの制約を超えた柔軟なコード記述を可能にしていますが、実行時エラーのリスクも伴います。

varとの違い

C#にはvarという型推論キーワードもありますが、dynamicとは性質が大きく異なります。

ここではvarとdynamicの違いを整理します。

特徴	var	dynamic
型決定のタイミング	コンパイル時に型が決まる	実行時に型が決まる
型チェック	コンパイル時に厳密に行われる	コンパイル時は行われず実行時に行われる
利用目的	型推論によるコードの簡潔化	動的なメンバーアクセスや遅延バインディング
例外発生	型不一致はコンパイルエラーになる	実行時にメンバーが存在しなければ例外が発生

varの特徴

varはコンパイラが右辺の式から型を推論し、その型で変数を宣言します。

例えば、

var number = 10; // numberはint型として扱われる

この場合、numberはint型としてコンパイル時に決定されるため、以降はint型として振る舞います。

varはあくまで静的型付けの範囲内で型推論を行うだけなので、型安全性は保たれます。

dynamicの特徴

一方、dynamicはコンパイル時に型を決定せず、実行時に型やメンバーの解決を行います。

例えば、

dynamic obj = GetSomeObject();
obj.SomeMethod(); // 実行時にSomeMethodが存在するかチェックされる

この場合、objの型は実行時まで不明であり、SomeMethodが存在しなければ実行時例外が発生します。

dynamicは動的な操作が必要な場面で使われ、柔軟性が高い反面、型安全性は低くなります。

このように、dynamicは動的バインディングを実現するための強力な機能であり、DLRの支援を受けて実行時に型やメンバーを解決します。

varとは異なり、実行時まで型が決まらないため、使い方には注意が必要ですが、柔軟なプログラミングを可能にします。

ExpandoObjectの基礎

何ができるか

ExpandoObjectは、System.Dynamic名前空間に含まれるクラスで、動的にプロパティやメソッドを追加・削除できるオブジェクトを提供します。

通常のクラスのように事前にプロパティを定義する必要がなく、実行時に自由にメンバーを操作できるのが特徴です。

具体的には、以下のような操作が可能です。

プロパティの追加・変更・削除
メソッドの追加(デリゲートをプロパティとして割り当てる形で)
foreachでの列挙(追加したプロパティを列挙可能)
IDictionary<string, object>としてのアクセス

例えば、以下のコードでは動的にNameとAgeというプロパティを追加しています。

using System;
using System.Dynamic;
class Program
{
    static void Main()
    {
        dynamic person = new ExpandoObject();
        person.Name = "Alice";  // プロパティの追加
        person.Age = 28;        // プロパティの追加
        Console.WriteLine($"Name: {person.Name}, Age: {person.Age}");
    }
}

Name: Alice, Age: 28

このように、ExpandoObjectは動的にプロパティを増やせるため、柔軟なデータ構造を簡単に作れます。

IDictionaryとしての振る舞い

ExpandoObjectは内部的にIDictionary<string, object>インターフェースを実装しています。

これにより、動的に追加したプロパティは辞書のキーと値のペアとして管理されます。

dynamicとして使うだけでなく、明示的に辞書として扱うことも可能です。

以下の例では、ExpandoObjectをIDictionary<string, object>としてキャストし、プロパティの追加や列挙を行っています。

using System;
using System.Dynamic;
using System.Collections.Generic;
class Program
{
    static void Main()
    {
        dynamic expando = new ExpandoObject();
        var dict = (IDictionary<string, object>)expando;
        dict["Country"] = "Japan";  // プロパティの追加
        dict["City"] = "Tokyo";
        foreach (var kvp in dict)
        {
            Console.WriteLine($"{kvp.Key}: {kvp.Value}");
        }
    }
}

Country: Japan
City: Tokyo

このように、ExpandoObjectは動的なプロパティを辞書のように操作できるため、キー・バリュー形式でのアクセスや操作がしやすくなっています。

TryGetMember／TrySetMember

ExpandoObjectはDynamicObjectクラスを継承していませんが、動的メンバーアクセスのために内部的にTryGetMemberやTrySetMemberのようなメソッドを実装しています。

これらは動的にプロパティの取得や設定を行う際に呼び出されるメソッドです。

TryGetMemberは、指定された名前のプロパティの値を取得しようとしたときに呼ばれます
TrySetMemberは、指定された名前のプロパティに値を設定しようとしたときに呼ばれます

これらのメソッドは、ExpandoObjectの内部辞書に対して操作を行い、動的なプロパティの追加や取得を実現しています。

例えば、ExpandoObjectにNameプロパティを設定すると、TrySetMemberが呼ばれて内部辞書に"Name"キーと値が登録されます。

Nameを参照するとTryGetMemberが呼ばれて値が返されます。

この仕組みは、ExpandoObjectが動的にプロパティを扱うためのコアな部分であり、ユーザーは意識せずに自然な形で動的メンバーを操作できます。

他のDynamicObjectとの比較

C#にはExpandoObject以外にも動的な振る舞いを実現するためのクラスがあり、代表的なものにDynamicObjectがあります。

両者の違いを理解すると、用途に応じて適切な選択ができます。

特徴	ExpandoObject	DynamicObject
継承関係	`object`から直接派生	`DynamicObject`を継承して作成
動的メンバーの管理	内部で`IDictionary<string, object>`を使い自動管理	メソッドをオーバーライドして自由に制御可能
プロパティの追加・削除	簡単に追加・削除可能	自分で実装が必要
柔軟性	シンプルで使いやすい	高度な動的振る舞いを実装可能
使用例	動的なデータ構造の簡単な作成	複雑な動的APIやプロキシの実装

ExpandoObjectは、動的にプロパティを追加・削除したい場合に最適で、特別な実装なしにすぐ使えます。

一方、DynamicObjectはメソッドをオーバーライドして動的な振る舞いを細かく制御できるため、より複雑な動的オブジェクトを作成したい場合に向いています。

例えば、DynamicObjectを継承してTryInvokeMemberやTryGetMemberをオーバーライドすれば、メソッド呼び出しの挙動を自由にカスタマイズできます。

ExpandoObjectはそうしたカスタマイズはできませんが、シンプルな動的オブジェクトとしては非常に便利です。

このように、ExpandoObjectは動的にプロパティを扱うためのシンプルかつ強力なクラスであり、内部的には辞書として管理され、動的メンバーアクセスはTryGetMemberやTrySetMemberの仕組みで実現されています。

用途に応じてDynamicObjectとの使い分けも検討すると良いでしょう。

基本的な使い方

プロパティの追加・変更

ExpandoObjectを使うと、動的にプロパティを追加したり変更したりできます。

dynamic型として扱うことで、まるで普通のオブジェクトのようにプロパティを自由に操作可能です。

以下の例では、NameとAgeというプロパティを追加し、その後Ageの値を変更しています。

using System;
using System.Dynamic;
class Program
{
    static void Main()
    {
        dynamic person = new ExpandoObject();
        // プロパティの追加
        person.Name = "Bob";
        person.Age = 25;
        Console.WriteLine($"Name: {person.Name}, Age: {person.Age}");
        // プロパティの変更
        person.Age = 26;
        Console.WriteLine($"Updated Age: {person.Age}");
    }
}

Name: Bob, Age: 25
Updated Age: 26

このように、ExpandoObjectはプロパティの追加も変更も簡単に行えます。

事前にクラス定義を用意しなくても、必要なプロパティを動的に増やせるため、柔軟なデータ構造を作成できます。

メソッドの定義

ExpandoObjectでは、メソッドを直接追加することはできませんが、デリゲートをプロパティとして割り当てることで、メソッドのように振る舞わせることが可能です。

以下の例では、Greetという名前のメソッドをデリゲートとして追加し、呼び出しています。

using System;
using System.Dynamic;
class Program
{
    static void Main()
    {
        dynamic person = new ExpandoObject();
        person.Name = "Carol";
        // メソッドの追加(Actionデリゲートを割り当て)
        person.Greet = new Action(() =>
        {
            Console.WriteLine($"Hello, my name is {person.Name}.");
        });
        // メソッドの呼び出し
        person.Greet();
    }
}

Hello, my name is Carol.

このように、ExpandoObjectのプロパティにActionやFuncなどのデリゲートを割り当てることで、動的にメソッドを定義できます。

引数付きのメソッドも同様に定義可能です。

person.SayAge = new Action<int>((age) =>
{
    Console.WriteLine($"I am {age} years old.");
});
person.SayAge(30);

I am 30 years old.

コレクションとの併用

ExpandoObjectはコレクションと組み合わせて使うことも多いです。

例えば、複数の動的オブジェクトをリストに格納したり、配列に変換したり、LINQで操作したりできます。

配列への変換

ExpandoObjectのリストを配列に変換するのは簡単です。

以下の例では、ExpandoObjectを複数作成し、List<dynamic>に格納してから配列に変換しています。

using System;
using System.Dynamic;
using System.Collections.Generic;
class Program
{
    static void Main()
    {
        var people = new List<dynamic>();
        dynamic person1 = new ExpandoObject();
        person1.Name = "Dave";
        person1.Age = 40;
        dynamic person2 = new ExpandoObject();
        person2.Name = "Eve";
        person2.Age = 35;
        people.Add(person1);
        people.Add(person2);
        // List<dynamic>を配列に変換
        dynamic[] peopleArray = people.ToArray();
        foreach (var p in peopleArray)
        {
            Console.WriteLine($"Name: {p.Name}, Age: {p.Age}");
        }
    }
}

Name: Dave, Age: 40
Name: Eve, Age: 35

このように、List<dynamic>をToArray()メソッドで配列に変換し、配列として扱うことができます。

LINQクエリへの適用

ExpandoObjectのリストはLINQクエリで操作可能です。

動的プロパティに基づいてフィルタリングや並べ替えを行えます。

以下の例では、年齢が30以上の人だけを抽出し、名前の昇順で並べ替えています。

using System;
using System.Dynamic;
using System.Collections.Generic;
using System.Linq;
class Program
{
    static void Main()
    {
        var people = new List<dynamic>();
        dynamic person1 = new ExpandoObject();
        person1.Name = "Frank";
        person1.Age = 28;
        dynamic person2 = new ExpandoObject();
        person2.Name = "Grace";
        person2.Age = 32;
        dynamic person3 = new ExpandoObject();
        person3.Name = "Hank";
        person3.Age = 45;
        people.Add(person1);
        people.Add(person2);
        people.Add(person3);
        var filtered = people
            .Where(p => p.Age >= 30)
            .OrderBy(p => p.Name);
        foreach (var p in filtered)
        {
            Console.WriteLine($"Name: {p.Name}, Age: {p.Age}");
        }
    }
}

Name: Grace, Age: 32
Name: Hank, Age: 45

このように、ExpandoObjectを使った動的オブジェクトのコレクションはLINQで柔軟に操作でき、静的型のコレクションとほぼ同様に扱えます。

ただし、動的型のため、プロパティ名のタイプミスなどには注意が必要です。

典型的なユースケース

JSONレスポンスのマッピング

Web APIなどから取得したJSONデータを扱う際、ExpandoObjectとdynamicを使うと柔軟にマッピングできます。

特に、JSONの構造が固定されていない場合や、部分的にしか使わない場合に便利です。

.NETのSystem.Text.JsonやNewtonsoft.Jsonでは、JSONをdynamic型やExpandoObjectにデシリアライズすることが可能です。

以下はNewtonsoft.Jsonを使った例です。

using System;
using System.Dynamic;
using Newtonsoft.Json;
class Program
{
    static void Main()
    {
        string json = @"{
            ""Name"": ""Ivy"",
            ""Age"": 29,
            ""Skills"": [""C#"", ""SQL"", ""Azure""]
        }";
        // JSONをExpandoObjectにデシリアライズ
        dynamic person = JsonConvert.DeserializeObject<ExpandoObject>(json);
        Console.WriteLine($"Name: {person.Name}");
        Console.WriteLine($"Age: {person.Age}");
        Console.WriteLine("Skills:");
        foreach (var skill in person.Skills)
        {
            Console.WriteLine($"- {skill}");
        }
    }
}

Name: Ivy
Age: 29
Skills:

- C#
- SQL
- Azure

このように、JSONのキーがそのまま動的プロパティとして扱えるため、クラスを定義せずにデータを操作できます。

APIのレスポンスが頻繁に変わる場合や、部分的にしか使わないデータを扱う際に特に有効です。

XMLとの相互運用

XMLデータを動的に扱いたい場合も、ExpandoObjectとdynamicが役立ちます。

System.Xml.LinqのXElementなどを使ってXMLを読み込み、必要な要素を動的にプロパティとしてマッピングすることが可能です。

以下は簡単なXMLを読み込み、動的オブジェクトに変換してアクセスする例です。

using System;
using System.Dynamic;
using System.Xml.Linq;
class Program
{
    static void Main()
    {
        string xml = @"
            <Person>
                <Name>Jack</Name>
                <Age>34</Age>
                <City>Osaka</City>
            </Person>";
        XElement element = XElement.Parse(xml);
        dynamic person = new ExpandoObject();
        var dict = (IDictionary<string, object>)person;
        foreach (var child in element.Elements())
        {
            dict[child.Name.LocalName] = child.Value;
        }
        Console.WriteLine($"Name: {person.Name}");
        Console.WriteLine($"Age: {person.Age}");
        Console.WriteLine($"City: {person.City}");
    }
}

Name: Jack
Age: 34
City: Osaka

この方法では、XMLの要素名を動的プロパティとして追加できるため、XMLの構造に応じて柔軟にデータを扱えます。

複雑なXMLの場合は再帰的に処理することも可能です。

テストダブルの作成

ユニットテストでモックやスタブなどのテストダブルを作成する際、ExpandoObjectは簡単に動的なオブジェクトを作れるため便利です。

特にインターフェースの実装が不要な軽量なテストダブルとして使えます。

例えば、以下のように動的にプロパティやメソッドを追加して、テスト対象に渡すことができます。

using System;
using System.Dynamic;
class Program
{
    static void Main()
    {
        dynamic mockService = new ExpandoObject();
        // プロパティの追加
        mockService.IsConnected = true;
        // メソッドの追加
        mockService.GetData = new Func<string>(() => "Mocked Data");
        Console.WriteLine($"IsConnected: {mockService.IsConnected}");
        Console.WriteLine($"GetData(): {mockService.GetData()}");
    }
}

IsConnected: True
GetData(): Mocked Data

このように、テスト用のオブジェクトを簡単に作成できるため、外部依存を切り離したテストがしやすくなります。

特に小規模なテストやプロトタイプ作成時に重宝します。

Office COMとの連携

Office製品のCOMオブジェクトと連携する際、dynamic型は非常に役立ちます。

COMオブジェクトは実行時にメンバーが決まるため、静的型付けでは扱いにくいですが、dynamicを使うと自然に操作できます。

以下はExcelのCOMオブジェクトをdynamicで操作する例です。

using System;
using Excel = Microsoft.Office.Interop.Excel;
class Program
{
    static void Main()
    {
        var excelApp = new Excel.Application();
        excelApp.Visible = false;
        dynamic workbook = excelApp.Workbooks.Add();
        dynamic sheet = workbook.Sheets[1];
        // セルに値を設定
        sheet.Cells[1, 1].Value = "Hello, Excel!";
        // セルの値を取得
        string cellValue = sheet.Cells[1, 1].Value;
        Console.WriteLine(cellValue);
        // 後片付け
        workbook.Close(false);
        excelApp.Quit();
    }
}

Hello, Excel!

COMオブジェクトのメソッドやプロパティは実行時に解決されるため、dynamicを使うことでコードがシンプルになり、COMの複雑な型定義を気にせずに操作できます。

ただし、COMの例外処理やリソース解放は慎重に行う必要があります。

これらのユースケースは、dynamicとExpandoObjectの柔軟性を活かした典型的な活用例です。

JSONやXMLのデータ操作、テストの簡素化、COM連携など、さまざまな場面で役立ちます。

パフォーマンスと最適化

キャッシュとCallSite

dynamic型の動的バインディングは、実行時にメンバーの解決を行うため、静的な型呼び出しに比べてパフォーマンスコストが発生します。

しかし、.NETのDynamic Language Runtime(DLR)はこのコストを軽減するために「CallSite」という仕組みを使い、呼び出し結果のキャッシュを行っています。

CallSiteは、動的呼び出しのバインディング情報を保持するキャッシュの役割を果たします。

初回の呼び出し時にメンバー解決を行い、その結果をCallSiteに保存します。

次回以降の同じ呼び出しではキャッシュされた情報を使うため、バインディングのオーバーヘッドが大幅に減少します。

この仕組みにより、同じ動的メンバーへのアクセスが繰り返される場合は、初回の遅延バインディングコストを除けば、ほぼ静的呼び出しに近い速度で処理されます。

ただし、異なるメンバーや異なる型のオブジェクトに対しては再度バインディングが必要になるため、動的呼び出しの多用はパフォーマンスに影響を与えます。

Reflectionとの差異

動的バインディングは一見するとリフレクション(Reflection)と似ていますが、内部的には異なる仕組みで動作しています。

Reflectionは、型情報を取得し、メソッドやプロパティを明示的に呼び出すAPIを使って操作します。呼び出しは常にリフレクションAPIを介して行われるため、オーバーヘッドが大きいです
dynamic(DLR)は、初回の呼び出し時にリフレクションを使ってメンバーを解決しますが、その後はCallSiteキャッシュを利用して高速化します。つまり、動的呼び出しはリフレクションよりも効率的に動作します

以下の表に主な違いをまとめます。

項目	Reflection	dynamic(DLR)
呼び出し方法	明示的にAPIを呼び出す	動的バインディングで自動的に解決
パフォーマンス	常にリフレクションAPIを使用	初回のみリフレクション、以降はキャッシュ利用
コードの可読性	冗長になりやすい	通常のメソッド呼び出しに近い記述が可能
型安全性	なし	なし

このため、動的な操作が必要な場合は、可能な限りdynamicを使い、リフレクションは特殊なケースに限定するのが一般的です。

IL生成の挙動

dynamic型の呼び出しは、コンパイル時にIL(中間言語)コードとして特別なバインディングコードが生成されます。

具体的には、CallSiteと呼ばれるランタイムバインディングのためのコードが埋め込まれます。

ILコードは以下のような特徴を持ちます。

CallSiteの生成

動的呼び出しごとにCallSiteが生成され、バインディングロジックが格納されます。

バインディングの遅延

実行時に対象オブジェクトの型を調べ、適切なメソッドやプロパティを解決します。

キャッシュの活用

一度解決したバインディングはCallSiteにキャッシュされ、次回以降の呼び出しは高速化されます。

ILコードを直接見ると、動的呼び出しは静的呼び出しよりも複雑な命令列となりますが、DLRの最適化により実行時のパフォーマンスは十分に実用的です。

ベンチマーク例

dynamic型のパフォーマンスを理解するために、静的型呼び出し、dynamic呼び出し、リフレクション呼び出しの速度を比較する簡単なベンチマークを示します。

using System;
using System.Diagnostics;
using System.Reflection;
class Sample
{
    public int Value { get; set; }
    public int GetValue() => Value;
}
class Program
{
    static void Main()
    {
        var sample = new Sample { Value = 42 };
        dynamic dynSample = sample;
        var sw = new Stopwatch();
        // 静的呼び出し
        sw.Start();
        for (int i = 0; i < 1_000_000; i++)
        {
            int v = sample.GetValue();
        }
        sw.Stop();
        Console.WriteLine($"Static call: {sw.ElapsedMilliseconds} ms");
        // dynamic呼び出し
        sw.Restart();
        for (int i = 0; i < 1_000_000; i++)
        {
            int v = dynSample.GetValue();
        }
        sw.Stop();
        Console.WriteLine($"Dynamic call: {sw.ElapsedMilliseconds} ms");
        // Reflection呼び出し
        var method = typeof(Sample).GetMethod("GetValue");
        sw.Restart();
        for (int i = 0; i < 1_000_000; i++)
        {
            int v = (int)method.Invoke(sample, null);
        }
        sw.Stop();
        Console.WriteLine($"Reflection call: {sw.ElapsedMilliseconds} ms");
    }
}

Static call: 2 ms
Dynamic call: 34 ms
Reflection call: 13 ms

(※実行環境により数値は変動します)

この結果からわかるように、

静的呼び出しが最も高速です
dynamic呼び出しは最も遅く、パフォーマンスに大きな影響を与えます
リフレクション呼び出しは静的呼び出しより遅いものの、dynamicよりはるかに高速です

したがって、パフォーマンスが重要な部分では静的型を使い、動的な柔軟性が必要な部分だけdynamicを使うのが望ましいです。

リフレクションは特殊なケースに限定しましょう。

型安全性とメンテナンス

静的解析ツールへの影響

dynamic型を使うと、コンパイル時に型チェックが行われないため、静的解析ツールの効果が制限されることがあります。

多くの静的解析ツールはソースコードの型情報をもとにコードの問題点や潜在的なバグを検出しますが、dynamicを使うと型が不明なため、以下のような影響が出ます。

メンバーの存在チェックができない

dynamicのメンバーアクセスは実行時に解決されるため、静的解析ツールは存在しないプロパティやメソッドの呼び出しを検出できません。

結果として、タイプミスや誤ったメンバー呼び出しが見逃される可能性があります。

リファクタリング支援の低下

IDEのリファクタリング機能は型情報を利用して安全に名前変更や移動を行いますが、dynamicでは正確な型情報がないため、リファクタリングの自動化が難しくなります。

コード補完の制限

Visual StudioなどのIDEは型情報をもとにコード補完を提供しますが、dynamic型の変数に対しては補完候補が表示されにくく、開発効率が下がることがあります。

これらの理由から、dynamicの使用は必要最小限にとどめ、可能な限り静的型付けを活用することが推奨されます。

静的解析ツールの恩恵を最大限に受けるためには、dynamicを使う箇所を限定し、明確にコメントやドキュメントで意図を示すことも重要です。

null安全パターン

dynamic型を使う場合、null参照例外NullReferenceExceptionが発生しやすくなるため、null安全に配慮したコードを書くことが大切です。

dynamicは実行時にメンバーアクセスを解決するため、対象がnullだと例外が発生します。

以下のようなnull安全パターンが有効です。

nullチェックを明示的に行う

dynamic obj = GetDynamicObject();
if (obj != null)
{
    // nullでなければメンバーにアクセス
    Console.WriteLine(obj.Name);
}
else
{
    Console.WriteLine("obj is null");
}

null条件演算子(?.)の活用

C# 6.0以降で使える?.演算子は、nullの場合にメンバーアクセスをスキップし、nullを返します。

dynamicでも利用可能です。

dynamic obj = GetDynamicObject();
Console.WriteLine(obj?.Name ?? "Name is null or obj is null");

try-catchで例外を捕捉する

動的メンバーアクセスで例外が発生する可能性がある場合は、RuntimeBinderExceptionを捕捉して安全に処理する方法もあります。

using Microsoft.CSharp.RuntimeBinder;
try
{
    dynamic obj = GetDynamicObject();
    Console.WriteLine(obj.Name);
}
catch (RuntimeBinderException)
{
    Console.WriteLine("メンバーが存在しません");
}

これらのパターンを組み合わせて使うことで、dynamicを使ったコードの安定性を高められます。

インターフェース実装による補完支援

dynamic型の弱点の一つはIDEのコード補完が効きにくいことですが、インターフェースを活用することで補完支援を改善できます。

具体的には、dynamicを使うオブジェクトに対して、共通のインターフェースを実装し、静的型として扱う部分を用意します。

こうすることで、IDEはインターフェースのメンバーを認識し、補完や型チェックが可能になります。

以下は例です。

using System;
using System.Dynamic;

interface IPerson
{
    string Name { get; set; }
    int Age { get; set; }
}

// ExpandoObjectをラップしてIPersonを実装
class PersonWrapper : IPerson
{
    private readonly dynamic _expando;

    public PersonWrapper(dynamic expando)
    {
        _expando = expando;
    }

    public string Name
    {
        get => _expando.Name;
        set => _expando.Name = value;
    }

    public int Age
    {
        get => _expando.Age;
        set => _expando.Age = value;
    }
}

class Program
{
    static void Main()
    {
        dynamic expando = new ExpandoObject();
        expando.Name = "Liam";
        expando.Age = 31;

        // ExpandoObjectをIPersonでラップする
        IPerson person = new PersonWrapper(expando);

        Console.WriteLine($"Name: {person.Name}, Age: {person.Age}");

        person.Age = 32;

        Console.WriteLine($"Updated Age: {person.Age}");
    }
}

Name: Liam, Age: 31
Updated Age: 32

この方法では、ExpandoObjectの動的な柔軟性を保ちつつ、インターフェースを通じて静的型の恩恵を受けられます。

IDEの補完や静的解析も有効になるため、メンテナンス性が向上します。

ただし、インターフェースに定義されていないメンバーにはアクセスできなくなるため、動的な拡張性は制限されます。

用途に応じて使い分けることが重要です。

エラーハンドリング

RuntimeBinderExceptionの対処

dynamic型を使う際に最もよく遭遇する例外の一つがRuntimeBinderExceptionです。

これは、実行時に呼び出そうとしたメンバー(プロパティやメソッド)が存在しない場合に発生します。

適切に対処しないと、プログラムが予期せずクラッシュする原因となるため、エラーハンドリングが重要です。

try-catchのパターン

RuntimeBinderExceptionを捕捉するためには、try-catchブロックを使います。

例外が発生しそうな動的メンバーアクセスを囲み、例外発生時に適切な処理を行うことで、プログラムの安定性を保てます。

using System;
using Microsoft.CSharp.RuntimeBinder;
class Program
{
    static void Main()
    {
        dynamic obj = new System.Dynamic.ExpandoObject();
        obj.ExistingProperty = "Hello";
        try
        {
            // 存在するプロパティへのアクセス(正常)
            Console.WriteLine(obj.ExistingProperty);
            // 存在しないプロパティへのアクセス(例外発生)
            Console.WriteLine(obj.NonExistentProperty);
        }
        catch (RuntimeBinderException ex)
        {
            Console.WriteLine($"RuntimeBinderException caught: {ex.Message}");
        }
    }
}

Hello
RuntimeBinderException caught: 'System.Dynamic.ExpandoObject' does not contain a definition for 'NonExistentProperty'

このように、try-catchで囲むことで、動的メンバーが存在しない場合でも例外をキャッチして処理を継続できます。

ログ出力や代替処理を行う際に有効です。

型チェックを組み込む方法

例外処理に頼らず、事前にメンバーの存在をチェックして安全にアクセスする方法もあります。

ExpandoObjectはIDictionary<string, object>として扱えるため、キーの存在を確認できます。

using System;
using System.Dynamic;
using System.Collections.Generic;
class Program
{
    static void Main()
    {
        dynamic obj = new ExpandoObject();
        var dict = (IDictionary<string, object>)obj;
        dict["Name"] = "Emma";
        if (dict.ContainsKey("Name"))
        {
            Console.WriteLine($"Name: {obj.Name}");
        }
        else
        {
            Console.WriteLine("Nameプロパティは存在しません");
        }
        if (dict.ContainsKey("Age"))
        {
            Console.WriteLine($"Age: {obj.Age}");
        }
        else
        {
            Console.WriteLine("Ageプロパティは存在しません");
        }
    }
}

Name: Emma
Ageプロパティは存在しません

また、dynamicオブジェクトがExpandoObject以外の場合は、GetType()やGetMemberを使ったリフレクションでメンバーの存在を調べることも可能です。

using System;
using System.Reflection;
class Program
{
    static void Main()
    {
        dynamic obj = new { Name = "Frank" };
        var type = obj.GetType();
        var prop = type.GetProperty("Name");
        if (prop != null)
        {
            Console.WriteLine($"Name: {prop.GetValue(obj)}");
        }
        else
        {
            Console.WriteLine("Nameプロパティは存在しません");
        }
    }
}

Name: Frank

このように、例外を未然に防ぐためにメンバーの存在チェックを組み込むことが推奨されます。

動的呼び出し失敗のデバッグ

動的呼び出しでエラーが発生すると、RuntimeBinderExceptionがスローされますが、デバッグ時に原因を特定するのはやや難しい場合があります。

ここでは、スタックトレースの読み方やデバッグのポイントを説明します。

スタックトレースの読み方

RuntimeBinderExceptionのスタックトレースは、通常の例外と同様に例外発生箇所を示しますが、動的バインディングの内部処理が含まれるため、やや複雑です。

System.Runtime.CompilerServices.RuntimeBinderException: 'System.Dynamic.ExpandoObject' does not contain a definition for 'Foo'
   at CallSite.Target(Closure , CallSite , Object )
   at Program.Main()

Program.Main()の行が、実際に動的メンバーアクセスを行った箇所です
CallSite.TargetはDLRの内部処理で、動的バインディングの呼び出し部分を示しています

デバッグ時は、スタックトレースの中で自分のコードが書かれている行を探し、どのメンバーアクセスが失敗したかを特定します。

デバッグのポイント

ブレークポイントを動的メンバーアクセス直前に置く

どのオブジェクトに対してどのメンバーを呼び出しているかを確認します。

オブジェクトの型を確認する

obj.GetType()で実際の型を調べ、期待通りの型かどうかをチェックします。

存在するメンバーを列挙する

ExpandoObjectの場合はIDictionary<string, object>としてキー一覧を取得し、どのメンバーが存在するかを確認します。

例外メッセージを活用する

例外メッセージには「存在しないメンバー名」が明示されているため、タイプミスや誤ったメンバー名を見つける手がかりになります。

これらの方法を組み合わせることで、動的呼び出し失敗の原因を効率的に特定し、修正できます。

非同期処理との組み合わせ

async/awaitでの注意点

dynamic型を使った非同期処理では、async/await構文と組み合わせる際にいくつか注意すべきポイントがあります。

dynamicは実行時に型が決まるため、非同期メソッドの戻り値や例外処理に影響を与えることがあります。

戻り値の型に注意する

非同期メソッドは通常、TaskやTask<T>を返しますが、dynamicを使うと戻り値の型が実行時まで不明になります。

例えば、dynamicなオブジェクトのメソッドをawaitするときは、戻り値がTaskかどうかを確実に把握しておく必要があります。

using System;
using System.Threading.Tasks;
class Program
{
    static async Task Main()
    {
        dynamic obj = new AsyncProvider();
        // 戻り値がTaskであることを期待してawait
        await obj.GetDataAsync();
        Console.WriteLine("処理完了");
    }
}
class AsyncProvider
{
    public async Task GetDataAsync()
    {
        await Task.Delay(500);
        Console.WriteLine("非同期処理中");
    }
}

非同期処理中
処理完了

この例では、obj.GetDataAsync()がTaskを返すことを前提にawaitしています。

もし戻り値がTaskでなければ、実行時に例外が発生します。

戻り値がTaskでない場合の対処

dynamicなメソッドの戻り値がTaskでない場合、awaitは使えません。

戻り値の型を事前にチェックするか、Taskにラップする必要があります。

dynamic obj = new SomeProvider();
var result = obj.SomeMethod();
if (result is Task task)
{
    await task;
}
else
{
    // Taskでなければ同期処理として扱う
    Console.WriteLine("同期処理の結果: " + result);
}

例外の伝播に注意

dynamicを使った非同期メソッドの例外は、通常のasync/awaitと同様にtry-catchで捕捉できますが、動的バインディングの失敗によるRuntimeBinderExceptionも発生する可能性があるため、例外処理は慎重に行う必要があります。

タスク戻り値のラッピング

dynamic型のメソッドが非同期処理を返さない場合でも、TaskやTask<T>にラップして非同期処理として扱うことができます。

これにより、dynamicオブジェクトのメソッドを非同期的に扱う柔軟性が向上します。

同期メソッドをTaskにラップする

同期的なメソッドの戻り値をTaskに包むには、Task.FromResultやTask.Runを使います。

using System;
using System.Threading.Tasks;
class Program
{
    static async Task Main()
    {
        dynamic obj = new SyncProvider();
        // 同期メソッドの戻り値をTaskにラップしてawait可能にする
        Task<string> taskResult = Task.FromResult(obj.GetData());
        string result = await taskResult;
        Console.WriteLine(result);
    }
}
class SyncProvider
{
    public string GetData()
    {
        return "同期データ";
    }
}

非同期処理をdynamicでラップする例

非同期メソッドを持つオブジェクトをdynamicで扱う場合、戻り値のTaskをそのまま返すことが多いですが、必要に応じてラップして返すことも可能です。

using System;
using System.Threading.Tasks;
class Program
{
    static async Task Main()
    {
        dynamic obj = new AsyncWrapper();
        string data = await obj.GetDataAsync();
        Console.WriteLine(data);
    }
}
class AsyncWrapper
{
    public Task<string> GetDataAsync()
    {
        return Task.Run(() =>
        {
            Task.Delay(300).Wait();
            return "非同期データ";
        });
    }
}

非同期データ

このように、dynamicと非同期処理を組み合わせる際は、戻り値の型を意識し、必要に応じてTaskでラップすることで安全かつ柔軟に非同期処理を扱えます。

高度なトピック

DynamicObjectを継承して拡張

DynamicObjectはC#のSystem.Dynamic名前空間にある抽象クラスで、動的なオブジェクトの振る舞いをカスタマイズするために使います。

ExpandoObjectとは異なり、DynamicObjectを継承してメソッドをオーバーライドすることで、動的メンバーの取得や設定、メソッド呼び出しなどの挙動を自由に制御できます。

Proxy的利用例

DynamicObjectを使う代表的な応用例の一つが「プロキシ(Proxy)」パターンの実装です。

プロキシは、実際のオブジェクトへのアクセスを仲介し、アクセス制御やロギング、遅延初期化などの機能を付加できます。

以下は、DynamicObjectを継承して、すべてのメンバーアクセスをログに記録しつつ、内部の実オブジェクトに処理を委譲する簡単なプロキシの例です。

using System;
using System.Dynamic;
using System.Reflection;
class LoggingProxy : DynamicObject
{
    private readonly object _target;
    public LoggingProxy(object target)
    {
        _target = target;
    }
    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
        Console.WriteLine($"GetMember: {binder.Name}");
        var prop = _target.GetType().GetProperty(binder.Name, BindingFlags.Public | BindingFlags.Instance);
        if (prop != null)
        {
            result = prop.GetValue(_target);
            return true;
        }
        result = null;
        return false;
    }
    public override bool TrySetMember(SetMemberBinder binder, object value)
    {
        Console.WriteLine($"SetMember: {binder.Name} = {value}");
        var prop = _target.GetType().GetProperty(binder.Name, BindingFlags.Public | BindingFlags.Instance);
        if (prop != null)
        {
            prop.SetValue(_target, value);
            return true;
        }
        return false;
    }
    public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
    {
        Console.WriteLine($"InvokeMember: {binder.Name}({string.Join(", ", args)})");
        var method = _target.GetType().GetMethod(binder.Name, BindingFlags.Public | BindingFlags.Instance);
        if (method != null)
        {
            result = method.Invoke(_target, args);
            return true;
        }
        result = null;
        return false;
    }
}
class Person
{
    public string Name { get; set; }
    public void SayHello() => Console.WriteLine($"Hello, my name is {Name}.");
}
class Program
{
    static void Main()
    {
        var person = new Person { Name = "Alice" };
        dynamic proxy = new LoggingProxy(person);
        Console.WriteLine(proxy.Name);  // プロパティ取得
        proxy.Name = "Bob";             // プロパティ設定
        proxy.SayHello();               // メソッド呼び出し
    }
}

GetMember: Name
Alice
SetMember: Name = Bob
InvokeMember: SayHello()
Hello, my name is Bob.

この例では、LoggingProxyがすべてのメンバーアクセスをキャッチし、ログを出力した上で実際のPersonオブジェクトに処理を委譲しています。

DynamicObjectのメソッドをオーバーライドすることで、柔軟に動的な振る舞いを実装できます。

Expression Treeとの統合

Expression Treeは、コードをデータ構造として表現し、動的にコードを生成・解析・実行できる仕組みです。

dynamicやExpandoObjectと組み合わせることで、より高度な動的プログラミングが可能になります。

例えば、Expression Treeを使って動的にプロパティアクセスやメソッド呼び出しの式を生成し、コンパイルして実行することができます。

これにより、動的オブジェクトの操作を高速化したり、複雑な動的クエリを構築したりできます。

以下は、Expression Treeで動的にプロパティアクセスを表現し、実行する簡単な例です。

using System;
using System.Linq.Expressions;
class Program
{
    static void Main()
    {
        var param = Expression.Parameter(typeof(Person), "p");
        var property = Expression.Property(param, "Name");
        var lambda = Expression.Lambda<Func<Person, string>>(property, param).Compile();
        var person = new Person { Name = "Charlie" };
        string name = lambda(person);
        Console.WriteLine(name);
    }
}
class Person
{
    public string Name { get; set; }
}

Charlie

この例では、PersonクラスのNameプロパティへのアクセスをExpression Treeで表現し、コンパイルして呼び出しています。

dynamicと組み合わせる場合は、Expression Treeで生成した式を動的オブジェクトの操作に応用することも可能です。

Roslynでのコード生成

RoslynはC#のコンパイラプラットフォームで、コードの解析や生成、コンパイルをプログラムから操作できます。

dynamicやExpandoObjectを使う場面で、Roslynを活用すると、動的コードの自動生成やカスタムコードの挿入が可能になります。

例えば、Roslynを使って動的にクラスやメソッドを生成し、実行時にコンパイルして利用することができます。

これにより、動的な型やメンバーを静的に生成し、パフォーマンスや型安全性を向上させることも可能です。

以下はRoslynで簡単なクラスを生成し、コンパイルしてインスタンス化する例の概要です。

// 1. C#コードの文字列を用意
string code = @"
public class DynamicClass
{
    public string SayHello() => ""Hello from generated code!"";
}";
// 2. RoslynのAPIでコンパイル
// 3. 生成したアセンブリから型を取得し、インスタンス化
// 4. メソッドを呼び出す
// 実際のコードはMicrosoft.CodeAnalysis.CSharpパッケージを利用して実装

Roslynを活用することで、dynamicの柔軟性と静的コードの安全性を組み合わせた高度な開発が可能になります。

特に大規模な動的コード生成やDSL(ドメイン固有言語)の実装に役立ちます。

代替アプローチ

Record型とパターンマッチング

C# 9.0以降で導入されたrecord型は、不変(イミュータブル)なデータ構造を簡潔に定義できる機能です。

dynamicのように動的にプロパティを追加することはできませんが、型安全かつ簡潔にデータを扱えるため、動的オブジェクトの代替として有効です。

using System;
record Person(string Name, int Age);
class Program
{
    static void Main()
    {
        var person = new Person("Alice", 30);
        Console.WriteLine($"Name: {person.Name}, Age: {person.Age}");
        // パターンマッチングで型チェックと分解
        if (person is Person { Age: > 20 } p)
        {
            Console.WriteLine($"{p.Name} is older than 20");
        }
    }
}

Name: Alice, Age: 30
Alice is older than 20

recordは値の比較やコピーが容易で、パターンマッチングと組み合わせることで条件分岐もシンプルに書けます。

動的型の柔軟性はありませんが、型安全性とメンテナンス性を重視する場合におすすめです。

Anonymous Typeの活用

匿名型(Anonymous Type)は、名前のない型を簡単に作成できる機能で、主に一時的なデータ構造の作成に使います。

dynamicのように実行時にプロパティを追加するわけではありませんが、簡潔に複数のプロパティをまとめられます。

using System;
class Program
{
    static void Main()
    {
        var anon = new { Name = "Bob", Age = 25 };
        Console.WriteLine($"Name: {anon.Name}, Age: {anon.Age}");
    }
}

Name: Bob, Age: 25

匿名型はコンパイル時に型が決まるため、IDEの補完や静的解析が効きます。

ただし、メソッドの定義やプロパティの追加はできず、スコープ内でのみ有効です。

動的な拡張性はありませんが、簡単なデータの受け渡しに便利です。

Source Generatorsで型安全を保つ

Source Generatorsは、コンパイル時にコードを自動生成するC#の機能で、動的なコード生成を静的に行うことで型安全性を保ちながら柔軟な設計が可能です。

dynamicのように実行時に型を決定するのではなく、コンパイル時に必要なコードを生成するため、パフォーマンスや保守性の向上に寄与します。

例えば、JSONのスキーマから対応するC#クラスを自動生成したり、複雑なボイラープレートコードを省略したりできます。

// Source Generatorの例(概要)
// 1. JSONスキーマを解析し、対応するrecordクラスを生成
// 2. 生成されたクラスは静的型として利用可能
// 3. IDEの補完や静的解析も有効
// 実際の実装はMicrosoft.CodeAnalysisパッケージを利用し、Generatorクラスを作成

Source Generatorsを活用すると、動的なデータ構造の柔軟性と静的型の安全性を両立でき、dynamicの使用を減らして堅牢なコードを書くことができます。

大規模プロジェクトや複雑なデータ連携がある場合に特に効果的です。

よくある落とし穴

名前衝突

ExpandoObjectやdynamicを使う際に注意したいのが、プロパティ名の名前衝突です。

動的にプロパティを追加するため、同じ名前のプロパティを誤って複数回追加したり、既存のメンバー名と重複したりすると、予期しない動作や上書きが発生します。

例えば、以下のように同じ名前のプロパティを複数回設定すると、最後に設定した値で上書きされます。

using System;
using System.Dynamic;
class Program
{
    static void Main()
    {
        dynamic obj = new ExpandoObject();
        obj.Name = "Alice";
        obj.Name = "Bob";  // 上書きされる
        Console.WriteLine(obj.Name);  // Bobと表示される
    }
}

Bob

また、ExpandoObjectは内部的にIDictionary<string, object>として管理されているため、キーの重複は許されません。

名前の衝突を防ぐためには、プロパティ名を一意に管理するか、命名規則を設けることが重要です。

さらに、動的オブジェクトに既存のメソッド名やプロパティ名と同じ名前を付けると、意図しない挙動を引き起こすことがあります。

例えば、ToStringやGetHashCodeなどのメソッド名は避けるべきです。

シリアライズ不可プロパティ

ExpandoObjectやdynamicを含むオブジェクトをJSONやXMLなどにシリアライズする際、シリアライズできないプロパティが存在することがあります。

特に、デリゲートや非公開のメンバー、循環参照を含む場合に問題が起こりやすいです。

例えば、ExpandoObjectにデリゲート(メソッドを表すオブジェクト)をプロパティとして追加すると、多くのシリアライザはこれを正しく処理できず、例外が発生したり、出力が不完全になったりします。

using System;
using System.Dynamic;
using Newtonsoft.Json;
class Program
{
    static void Main()
    {
        dynamic obj = new ExpandoObject();
        obj.Name = "Charlie";
        obj.Action = new Action(() => Console.WriteLine("Hello"));
        try
        {
            string json = JsonConvert.SerializeObject(obj);
            Console.WriteLine(json);
        }
        catch (Exception ex)
        {
            Console.WriteLine($"シリアライズエラー: {ex.Message}");
        }
    }
}

シリアライズエラー: Self referencing loop detected with type 'System.Action'.

このような問題を避けるには、シリアライズ対象のプロパティを限定したり、デリゲートなどシリアライズ不可能なメンバーを除外するカスタム設定を行う必要があります。

また、ExpandoObjectの動的プロパティはシリアライズ時にすべて含まれるため、不要なプロパティを削除しておくことも重要です。

IDEサポート不足

dynamic型を使うと、Visual StudioやJetBrains RiderなどのIDEでのコード補完や静的解析のサポートが制限されることがあります。

これは、dynamicの型情報がコンパイル時に不明なため、IDEがメンバーの存在や型を推測できないためです。

具体的な影響は以下の通りです。

コード補完が効かない

dynamic変数に対しては、利用可能なメンバーの候補が表示されず、手入力でのタイプミスが増えやすくなります。

リファクタリング支援の低下

メンバー名の変更や参照の追跡が難しくなり、リファクタリング時に見落としが発生しやすくなります。

静的解析ツールの警告が減る

型安全性のチェックができないため、潜在的なバグを検出しにくくなります。

これらの問題を軽減するためには、dynamicの使用を必要最小限に抑え、可能な限り静的型を使うことが推奨されます。

また、ExpandoObjectをIDictionary<string, object>として扱い、キーの存在チェックを行うなどの工夫も有効です。

これらの落とし穴は、dynamicやExpandoObjectの便利さの裏に潜むリスクです。

適切な命名規則やシリアライズ設定、IDEの制約を理解し、慎重に使うことでトラブルを防げます。

ベストプラクティス集

最小スコープでdynamicを使う

dynamic型は便利ですが、型安全性が失われるため、コードの保守性やバグの発見が難しくなるリスクがあります。

そのため、dynamicを使う際は最小限のスコープに限定することが重要です。

具体的には、以下のポイントを意識します。

必要な箇所だけで使う

例えば、外部APIのレスポンスを受け取る部分や、COMオブジェクトとの連携部分など、動的な操作がどうしても必要な箇所に限定します。

動的オブジェクトの受け渡しは避ける

dynamic型の変数をメソッドの引数や戻り値として広く使うと、呼び出し元での型不明によるトラブルが増えます。

できるだけ静的型に変換してから渡すようにします。

ローカル変数として使う

動的な操作はローカル変数の範囲内にとどめ、影響範囲を狭くします。

これにより、問題の切り分けやデバッグがしやすくなります。

dynamic GetDynamicData()
{
    dynamic data = new ExpandoObject();
    data.Name = "Alice";
    data.Age = 30;
    return data;
}
void ProcessData()
{
    dynamic data = GetDynamicData();
    // dynamicの使用はここだけに限定
    Console.WriteLine(data.Name);
}

このように、dynamicの使用範囲を限定することで、コードの安全性と可読性を保てます。

明示的な型変換

dynamic型の値を扱う際は、明示的に型変換(キャスト)を行うことが推奨されます。

これにより、実行時の型不一致による例外を早期に検出しやすくなり、コードの意図が明確になります。

dynamic obj = GetDynamicObject();
// 明示的にstring型にキャスト
string name = (string)obj.Name;
Console.WriteLine(name);

キャストを行うことで、もしobj.NameがstringでなければInvalidCastExceptionが発生し、問題の箇所を特定しやすくなります。

また、as演算子を使って安全にキャストし、nullチェックを組み合わせる方法もあります。

string name = obj.Name as string;
if (name != null)
{
    Console.WriteLine(name);
}
else
{
    Console.WriteLine("Nameはstring型ではありません");
}

このように、明示的な型変換を行うことで、動的型の曖昧さを減らし、堅牢なコードを書くことができます。

コメントとドキュメントの併用

dynamicを使うコードは、型情報がコンパイル時にわからないため、コメントやドキュメントを充実させることが特に重要です。

これにより、コードの意図や期待される型、利用方法を明確に伝えられ、メンテナンス性が向上します。

変数やメソッドの役割を説明するコメント

どのような動的オブジェクトが入るのか、どのプロパティが使われるのかを記述します。

期待される型や構造の説明

例えば、dynamicオブジェクトに含まれるべきプロパティ名や型をコメントで示すと、利用者が誤用を防げます。

例外が発生しやすい箇所の注意書き

動的メンバーアクセスで例外が起きやすい部分には、try-catchの必要性や事前チェックの推奨を明記します。

// dynamicオブジェクトはName(string)とAge(int)プロパティを持つことを期待
dynamic person = GetPersonData();
try
{
    string name = (string)person.Name;
    int age = (int)person.Age;
    Console.WriteLine($"Name: {name}, Age: {age}");
}
catch (RuntimeBinderException)
{
    Console.WriteLine("動的メンバーのアクセスに失敗しました");
}