Effective C# 原則 43：勿濫用反射，優先採用介面與類別工廠

反射雖能實現動態配置、延遲綁定，但繞過編譯期型別檢查，參數/回傳值皆為 object，極易在執行期發生型別錯誤。大多數情況下，介面、委派、類別工廠等強型別方案更簡潔、可維護。

反射三大常見用途與替代方案

1. 動態建立實例 → 類別工廠

// 反射版：脆弱、依賴無參建構函式、編譯期不報錯
Type t = typeof(MyType);
MyType obj = (MyType)t.GetConstructor(Type.EmptyTypes).Invoke(null);

// 工廠版：強型別、編譯期檢查、可標記屬性供發現
public static MyType CreateInstance() => new MyType();

2. 動態呼叫方法 → 介面契約

// 反射版：參數檢查繁瑣、字串名稱易拼錯
object.InvokeMethod(obj, "MyHelperFunc");

// 介面版：編譯期綁定、智慧提示、重構安全
IMyInterface foo = obj as IMyInterface;
foo?.DoWork();

3. 動態存取欄位/屬性 → 介面屬性

// 反射版
object val = obj.GetType().GetField("MyField").GetValue(obj);

// 介面版
foo.Msg = "work is done.";

何時必須用反射？

• 資料繫結：需綁定任意公共屬性，介面會過度限制；
• 選單命令/外掛架構：任意方法（含靜態）可作為處理器，介面僅限實例方法；
• 工具類框架：NUnit（發現測試方法）、FxCop（掃描所有代碼）等，問題領域本質上需要反射。

結合屬性簡化反射

若必須用反射，請自訂屬性（Attribute）標記目標型別/成員，搭配 AttributeUsage 限制適用範圍，大幅降低誤用風險（詳見原則 42）。

總結

能用介面/工廠/委派解決的，堅決不用反射。反射保留給真正需要動態發現、跨組件擴展的框架級場景。