開發 AOP 織入器的首要決策:原始碼層級織入 vs 設計模式/委派插入。
理想方案:核心熱路徑靜態織入,管理型切面動態配置。但雙引擎維護成本極高,原型階段建議先單一路徑驗證可行性。
從 SharpDevelop 移植解析器核心(RC2 版本),發現兩處潛在 Bug:
// 原始碼(SharpDevelop 內部工具方法)
static public int Compare(IList a, IList b, IComparer comparer) {
if (a == null || b == null) return 1; // 問題:null 比較語意不明
if (a.Count != b.Count) return Math.Sign(a.Count - b.Count);
int limit = (a.Count < b.Count) ? a.Count : b.Count; // 冗餘:前已檢查 Count 相等
for (int i = 0; i < limit; i++) {
if (a[i] is IComparable && b[i] is IComparable) { // 問題:未使用傳入的 comparer!
int cmp = comparer.Compare(a[i], b[i]);
if (cmp != 0) return cmp;
}
}
return a.Count - b.Count; // 永遠為 0
}
Mono 已修正此邏輯。懷疑原作者可能在非清醒狀態撰寫。
特定巢狀泛型情境下型別參數解析失敗,導致織入器產生錯誤 IL。需加入防禦性檢查與單元測試覆蓋。
// 切面定義屬性
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class)]
public class AspectAttribute : Attribute {
public string Pointcut { get; set; } // 切入點運算式
public AdviceType Advice { get; set; } // Before/After/Around
public Type AdviceType { get; set; } // 實作切面的類別
}
// 織入器介面
public interface IWeaver {
void Weave(Assembly input, Assembly output, IEnumerable aspects);
WeavingResult Result { get; }
}
造輪子雖痛,但深入理解編譯器管線、IL 生成、型別系統極有價值。現階段優先驗證「靜態織入原型可行性」,而非追求功能完整。PostSharp 的商業成功證明此路可行,關鍵在工程品質與生態整合。