>我有一个API，其中包括一些接受类型参数的方法。作为改进 API（更类型安全）的一部分，我现在将它们转换为泛型方法，同时保留非泛型版本以实现向后兼容性。
当前 - 待过时：
public object MyMethod(object value, Type expectedType)
新增功能：
public T MyMethod<T>(object value)
但是，Mymethod调用一个私有帮助程序方法，该方法也接受一个类型参数：
private object HelperMethod(object value, Type expectedType)
问：我是否也应该将此专用帮助程序方法设为通用方法？
我在下面有自己的答案，但我想知道我是否遗漏了什么。我非常感谢您的见解。
我的答案是否定的，我不应该使这个私有方法通用。
原因 1：此帮助程序方法是私有的，因此即使我将其设置为通用，它也不会改善 API。
原因 2：如果我将其设为泛型，则非泛型公共方法将不得不使用反射将类型参数传递给此泛型方法，这意味着更多的开销。
将私有帮助程序方法设为通用确实通过在整个实现过程中携带泛型类型特异性来改进 API。如果将类型限制到处理无类型System.Object的核心，则实现并未完全实现泛型的类型安全优势。
例如，为什么 MyMethod 的参数仍然是 System.Object？ 如果该参数源自源，则很有可能它也应该是一个类型参数。 如果参数源自数据，则最好使用 System.Object。 泛型在与源代码一起使用时最有用，因为源代码表达式在大多数上下文中隐式提供类型。
泛型的隐性成本取决于将与 API 一起使用的类型组合。 如果大多数类型都是值类型（内置和结构），则将 API 切换到泛型可能会增加内存消耗，因为对于每个值类型，泛型代码必须以不同的方式进行 jit。 如果与泛型 API 一起使用的大多数类型都是引用类型（类和接口），则代码/内存爆炸不是问题，因为所有引用类型共享相同的 JIT 代码。
让旧 API 调用新通用 API 的成本是否 a） 可度量和 b） 可接受完全取决于您在私有帮助程序方法中执行的操作 - 特别是专用帮助程序方法对 Type 参数执行的操作。
如果帮助程序方法实现相当轻量级，并且您确定（通过性能度量）调整旧 API 以调用新的通用帮助程序的成本是不可接受的，我会考虑并排复制帮助程序方法实现，一个采用旧样式，一个采用新泛型样式。这消除了 API 样式之间的交叉转换成本，并消除了在旧 API 中引入新错误的风险，代价是内部代码维护工作略有增加。
我认为这取决于您计划支持非通用方法的时间，调用频率，对反射的影响等。
我认为您会尽可能多地使用通用功能来利用所需的类型安全性。然后，如有必要，修改非泛型版本以使用泛型版本，并最终尽快弃用它。