框架類型的擴展方法的用法

Question

在新工作中，我被告知要避免對您（或您的組織）無法控制的類型使用擴展方法，這意味着外部庫，框架類型（如字符串，列表等）。

我得到的論據是，如果框架開發人員現在決定實現與擴展方法具有相同名稱和/或參數的方法，那將是不好的。

盡管可能會出現此問題，但此參數有效地將擴展方法的可用性降低到幾乎為零。 這個論點會被認為是有效的嗎？ 我不建議在任何地方都使用擴展方法，但是我想知道支持和反對它的類似論點。

Answer 1

這是一個有一定優點的論點，但是在很多情況下，可以避免這些問題：

• 如果您控制代碼並可以根據需要輕松地對其進行更新，則可以輕松編寫單元測試以檢測問題並在出現問題時進行糾正。 （我認為您無論如何都要先對外部庫進行任何更新，然后再進行部署。）
• 如果您信任外部庫開發人員遵循向后兼容的常規良好做法，那么他們無論如何都不應在接口中添加成員，因為那樣會破壞現有的實現方式，因此您至少可以為接口編寫擴展方法。

• 如果您的擴展方法有這將是不太可能的名字被添加到外部庫，然后實際來看這不是一個問題。 例如，如果您的公司寫的是Frobulators，而這是您特有的術語，那么請寫

   public static Frobulator ToFrobulator(this string Frobulator) 

  實際上，這實際上不會成為問題。

Answer 2

當然，存在風險，但是在您無法控制的封閉或sealed類型上定義某些東西正是擴展方法的本質。 如果只對自己的類型創建擴展方法，則擴展方法的有效性（與常規方法相比）將降至最低。

在命名約定中有一個非常簡單的“解決方案”。 如果使用特定標識符在擴展名前添加前綴或后綴，則可以確保Microsoft不會創建類似的方法。