使用 dynamic 被认为是一种不好的做法吗？
Is the use of dynamic considered a bad practice?
在 C# 中，有人可以做到：
MyClass myInstance = new MyClass();
dynamic mydynamicInstance = myInstance;
然后，调用一个方法，例如：
//This method takes a MyClass argument and does something.
Caller.InvokeMethod(myDynamicInstance);
现在，这将导致在运行时确定 myInstance 类型，
并且，如果有效，Caller.InvokeMethod 将被正常调用。
现在，我的问题是这是否被认为是使用 dynamic 的不良做法，尤其是在以下情况下：
1) InvokeMethod实例化另一个myDynamicInstance类型的实例，
在内部使用反射。
2) 有一个抽象基class MyBaseClass 和它的一些子class，包括MyBaseClass。如果我们有许多 InvokeMethod 的重载方法用于所有那些派生的 classes，我们是否可以使用它来允许在运行时确定类型，然后通过方法重载（或延迟绑定到 class)?:
方法的调用
public abstract class MyBaseClass {/*...*/}
public class MyClass : MyBaseClass {/*...*/}
public class MyAnotherClass : MyBaseClass {/*...*/}
MyBaseClass myBaseClassRef = new MyClass();
dynamic myDynamicInstance = myBaseClassRef;
Caller.InvokeMethod(myDynamicInstance);
简短的回答是肯定的，使用动态是一种不好的做法。
为什么？
dynamic关键字指的是type late binding，意思是系统只会在执行时检查type，而不是
在编译期间。这将意味着用户，而不是程序员，被留下来发现潜在的错误。错误可能是
MissingMethodException，但它也可能是对具有不良行为的现有方法的无意调用。
想象一下调用以计算错误的价格或计算错误的氧气水平结束的方法。
一般来说，类型检查有助于获得确定性计算，因此，如果可以，您应该使用它。这是关于 shortcomings of dynamic.
的问题
但是，动态可能会有用...
- Interop with COM like with Office
- 与动态类型是语言一部分的语言互操作（IronPython、IronRuby），因为动态被引入以帮助将它们移植到 .Net。
- 可以用低俗、优雅的代码代替复杂的反射代码（但是根据情况，您仍然应该分析这两种方法以检查哪种方法最合适性能和编译时检查）。
代码库在整个应用程序生命周期中不断发展，即使动态现在看起来不错，
它开创了一个先例，这可能意味着您的团队会增加动态关键字的使用。它可以导致增加
维护成本（如果上述签名发生变化，您可能会注意到它为时已晚）。当然，你可以
依赖单元测试、非回归人工测试等。但是当你必须在与人类纪律相关的事物之间做出选择时
质量由电脑自动检测相关质量，选择后者。它不太容易出错。
你的情况...
在你的情况下，你似乎可以使用通用继承方案（下面的第一个和你在问题中提到的那个），
因为 dynamic 不会给你任何额外的好处（它只会花费你更多的处理能力并让你招致
未来潜在错误的风险）。
这取决于您是否可以更改 MyClass 层次结构的代码 and/or Caller.InvokeMethod.
让我们列举一下
动态的不同可能替代方案...
- 动态关键字方法调用的已编译类型检查替代方法：
最常见的是使用 接口虚拟调用 像这样 instance.InvokeMethod() 继承调用正确的实现。
public interface IInvoker : { void InvokeMethod(); }
public abstract class MyBaseClass : IInvoker { public abstract void InvokeMethod(); }
public class MyAnotherClass : MyBaseClass { public override void InvokeMethod() { /* Do something */ } }
public class MyClass : MyBaseClass { public override void InvokeMethod() { /* Do something */ } }
另一个性能稍差的方法是使用扩展方法
public static class InvokerEx:
{
public static void Invoke(this MyAnotherClass c) { /* Do something */ } }
public static void Invoke(this MyClass c) { /* Do something */ } }
}
如果有多个"visitors"的MyBaseClass层级，可以使用访问者模式:
public interface IVisitor
{
void Visit(this MyAnotherClass c);
void Visit(this MyClass c);
}
public abstract class MyBaseClass : IInvoker { public abstract void Accept(IVisitor visitor); }
public class MyAnotherClass : MyBaseClass { public override void Accept(IVisitor visitor) { visitor.Visit(this); } }
public class MyClass : MyBaseClass { public override void Accept(IVisitor visitor) { visitor.Visit(this); } }
其他变体虽然在这里不是很有用（通用方法）但对性能比较很有趣：
public void InvokeMethod<T>(T instance) where T : IInvoker { return instance.InvokeMethod(); }
- 动态关键字方法调用的动态替代：
如果您需要调用编译时未知的方法，我在下面添加了您可以使用的不同技术并更新了性能结果：
MethodInfo.CreateDelegate
_method = typeof (T).GetMethod("InvokeMethod");
_func = (Func<T, int>)_method.CreateDelegate(typeof(Func<T, int>));
注意：需要转换为 Func 以避免调用 DynamicInvoke（因为它通常较慢）。
DynamicMethod 和 ILGenerator.Emit
它实际上是从头开始构建完整的调用，它是最灵活的，但您必须具有一定的汇编程序背景才能完全理解它。
_dynamicMethod = new DynamicMethod("InvokeMethod", typeof (int), new []{typeof(T)}, GetType().Module);
ILGenerator il = _dynamicMethod.GetILGenerator();
il.Emit(OpCodes.Ldarg_0);
il.Emit(OpCodes.Call, _method);
il.Emit(OpCodes.Ret);
_func = (Func<T, int>) _dynamicMethod.CreateDelegate(typeof (Func<T, int>));
Linq 表达式
它类似于 DynamicMethod，但是您无法控制生成的 IL。不过，它确实更具可读性。
_method = typeof (T).GetMethod("InvokeMethod");
var instanceParameter = Expression.Parameter(typeof (T), "instance");
var call = Expression.Call(instanceParameter, _method);
_delegate = Expression.Lambda<Func<T, int>>(call, instanceParameter).Compile();
_func = (Func<T, int>) _delegate;
MethodInfo.Invoke
最后但并非最不重要的，标准的已知反射调用。
然而，即使它很容易搞砸，也不要使用它，因为它的性能确实很差（查看基准测试结果）。更喜欢 CreateDelegate，它确实更快。
_method = typeof (T).GetMethod("InvokeMethod");
return (int)_method.Invoke(instance, _emptyParameters);
基准测试的代码可以在GitHub上找到。
不同方法的基准测试 得到一个数量级（针对 1000 万次调用）(.NET Framework 4.5)：
For Class standard call:
Elapsed: 00:00:00.0532945
Call/ms: 188679
For MethodInfo.CreateDelegate call:
Elapsed: 00:00:00.1131495
Call/ms: 88495
For Keyword dynamic call:
Elapsed: 00:00:00.3805229
Call/ms: 26315
For DynamicMethod.Emit call:
Elapsed: 00:00:00.1152792
Call/ms: 86956
For Linq Expression call:
Elapsed: 00:00:00.3158967
Call/ms: 31746
For Extension Method call:
Elapsed: 00:00:00.0637817
Call/ms: 158730
For Generic Method call:
Elapsed: 00:00:00.0772658
Call/ms: 129870
For Interface virtual call:
Elapsed: 00:00:00.0778103
Call/ms: 129870
For MethodInfo Invoke call:
Elapsed: 00:00:05.3104416
Call/ms: 1883
For Visitor Accept/Visit call:
Elapsed: 00:00:00.1384779
Call/ms: 72463
== SUMMARY ==
Class standard call: 1
Extension Method call : 1,19
Generic Method call : 1,45
Interface virtual call : 1,45
MethodInfo.CreateDelegate call : 2,13
DynamicMethod.Emit call : 2,17
Visitor Accept/Visit call : 2,60
Linq Expression call : 5,94
Keyword dynamic call : 7,17
MethodInfo Invoke call : 100,19
编辑：
因此与访问者模式相比，动态调度只慢 3 倍。对于某些应用程序来说，它是可以接受的，因为它可以删除繁琐的代码。始终由您选择。
请记住所有缺点。
编辑：（作为对多重分派好处的回答）
使用像“multiple dispatch”这样的流行模式名称，并只是声明它更干净，因为它使用的代码更少，恕我直言，这并不能使它成为一个额外的好处。
如果你想写时髦的代码或者不关心类型安全和生产稳定性，已经有很多语言提供了全功能的动态类型。我将 C# 中的 dynamic 关键字引入视为缩小强类型语言家族与非强类型语言之间差距的一种方式。这并不意味着您应该改变开发方式并将类型检查扔到垃圾桶。
更新：2016/11/08 (.NET Framework 4.6.1)
数量级保持不变（即使其中一些有所改进）：
Class standard call: 1
Extension Method call : 1,19
Interface virtual call : 1,46
Generic Method call : 1,54
DynamicMethod.Emit call : 2,07
MethodInfo.CreateDelegate call : 2,13
Visitor Accept/Visit call : 2,64
Linq Expression call : 5,55
Keyword dynamic call : 6,70
MethodInfo Invoke call : 102,96
我不完全同意 Fabien 的观点，即它不会给您带来额外的好处。
他用访问者模式解决的问题称为 Multiple dispatch 动态也可以为此提供一个干净的解决方案。当然，您必须知道 Fabien 提到的含义，例如性能、静态类型检查...
public abstract class MyBaseClass
{
}
public class MyClass : MyBaseClass
{
}
public class MyAnotherClass : MyBaseClass
{
}
public class ClassThatIsUsingBaseClass
{
public static void PrintName(MyBaseClass baseClass)
{
Console.WriteLine("MyBaseClass");
}
public static void PrintName(MyClass baseClass)
{
Console.WriteLine("MyClass");
}
public static void PrintName(MyAnotherClass baseClass)
{
Console.WriteLine("MyAnotherClass");
}
public static void PrintNameMultiDispatch(MyBaseClass baseClass)
{
ClassThatIsUsingBaseClass.PrintName((dynamic)baseClass);
}
}
用法是
static void Main(string[] args)
{
MyBaseClass myClass = new MyClass();
MyBaseClass myAnotherClass = new MyAnotherClass();
ClassThatIsUsingBaseClass.PrintName(myClass);
ClassThatIsUsingBaseClass.PrintName(myAnotherClass);
ClassThatIsUsingBaseClass.PrintNameMultiDispatch(myClass);
ClassThatIsUsingBaseClass.PrintNameMultiDispatch(myAnotherClass);
Console.ReadLine();
}
输出为
MyBaseClass
MyBaseClass
MyClass
MyAnotherClass
搜索 "Multiple dispatch" 和 "C# multiple dispatch" 了解更多信息。
这个问题在 2015 年得到了回答，2019 年的今天，我们在 JavaScript 和 Typescript 中看到的模式确实有充分的理由使用动态；但是，这需要开发者谨慎。
private (Boolean Valid, dynamic Result) ValidatePersonID(int ID)
{
var person = _store.Persons.FirstOrDefault(person => person.ID == ID);
if (person == null)
{
string message = $"The person id {ID} does not exist, please try again.";
return (false, message);
}
return (true, person);
}
要使用上面的代码：
var operation = ValidatePersonID(personID);
if (operation.Valid == false)
{
//BadRequest takes a string and C# uses co-variance to make it work.
return BadRequest(operation.Result);
}
//otherwise just cast the type, but requires the cast to always work.
var pe = (Person)operation.Result;
...
有效性的 return 是 True 还是 False 决定了returned 的类型。我们仍然使用 BadRequest 上的强制转换和/或所需的输入类型来选择强类型。我们还选择了编译时类型检查，因为如果两个 returned 类型中的一个更改为字符串和/或人以外的其他内容，它将无法编译。
我认为这是一种依赖注入的形式，我们可以根据注入的内容实现不同的行为。 C# 纯粹主义者不喜欢这个想法，但 Typescript 的人一直在这样做。
在 C# 中，有人可以做到：
MyClass myInstance = new MyClass();
dynamic mydynamicInstance = myInstance;
然后，调用一个方法，例如：
//This method takes a MyClass argument and does something.
Caller.InvokeMethod(myDynamicInstance);
现在，这将导致在运行时确定 myInstance 类型，
并且，如果有效，Caller.InvokeMethod 将被正常调用。
现在，我的问题是这是否被认为是使用 dynamic 的不良做法，尤其是在以下情况下：
1) InvokeMethod实例化另一个myDynamicInstance类型的实例，
在内部使用反射。
2) 有一个抽象基class MyBaseClass 和它的一些子class，包括MyBaseClass。如果我们有许多 InvokeMethod 的重载方法用于所有那些派生的 classes，我们是否可以使用它来允许在运行时确定类型，然后通过方法重载（或延迟绑定到 class)?:
public abstract class MyBaseClass {/*...*/}
public class MyClass : MyBaseClass {/*...*/}
public class MyAnotherClass : MyBaseClass {/*...*/}
MyBaseClass myBaseClassRef = new MyClass();
dynamic myDynamicInstance = myBaseClassRef;
Caller.InvokeMethod(myDynamicInstance);
简短的回答是肯定的，使用动态是一种不好的做法。
为什么？
dynamic关键字指的是type late binding，意思是系统只会在执行时检查type，而不是 在编译期间。这将意味着用户，而不是程序员，被留下来发现潜在的错误。错误可能是 MissingMethodException，但它也可能是对具有不良行为的现有方法的无意调用。 想象一下调用以计算错误的价格或计算错误的氧气水平结束的方法。
一般来说，类型检查有助于获得确定性计算，因此，如果可以，您应该使用它。这是关于 shortcomings of dynamic.
的问题但是，动态可能会有用...
- Interop with COM like with Office
- 与动态类型是语言一部分的语言互操作（IronPython、IronRuby），因为动态被引入以帮助将它们移植到 .Net。
- 可以用低俗、优雅的代码代替复杂的反射代码（但是根据情况，您仍然应该分析这两种方法以检查哪种方法最合适性能和编译时检查）。
代码库在整个应用程序生命周期中不断发展，即使动态现在看起来不错， 它开创了一个先例，这可能意味着您的团队会增加动态关键字的使用。它可以导致增加 维护成本（如果上述签名发生变化，您可能会注意到它为时已晚）。当然，你可以 依赖单元测试、非回归人工测试等。但是当你必须在与人类纪律相关的事物之间做出选择时 质量由电脑自动检测相关质量，选择后者。它不太容易出错。
你的情况...
在你的情况下，你似乎可以使用通用继承方案（下面的第一个和你在问题中提到的那个），
因为 dynamic 不会给你任何额外的好处（它只会花费你更多的处理能力并让你招致
未来潜在错误的风险）。
这取决于您是否可以更改 MyClass 层次结构的代码 and/or Caller.InvokeMethod.
让我们列举一下 动态的不同可能替代方案...
- 动态关键字方法调用的已编译类型检查替代方法：
最常见的是使用 接口虚拟调用 像这样 instance.InvokeMethod() 继承调用正确的实现。
public interface IInvoker : { void InvokeMethod(); }
public abstract class MyBaseClass : IInvoker { public abstract void InvokeMethod(); }
public class MyAnotherClass : MyBaseClass { public override void InvokeMethod() { /* Do something */ } }
public class MyClass : MyBaseClass { public override void InvokeMethod() { /* Do something */ } }
另一个性能稍差的方法是使用扩展方法
public static class InvokerEx:
{
public static void Invoke(this MyAnotherClass c) { /* Do something */ } }
public static void Invoke(this MyClass c) { /* Do something */ } }
}
如果有多个"visitors"的MyBaseClass层级，可以使用访问者模式:
public interface IVisitor
{
void Visit(this MyAnotherClass c);
void Visit(this MyClass c);
}
public abstract class MyBaseClass : IInvoker { public abstract void Accept(IVisitor visitor); }
public class MyAnotherClass : MyBaseClass { public override void Accept(IVisitor visitor) { visitor.Visit(this); } }
public class MyClass : MyBaseClass { public override void Accept(IVisitor visitor) { visitor.Visit(this); } }
其他变体虽然在这里不是很有用（通用方法）但对性能比较很有趣：
public void InvokeMethod<T>(T instance) where T : IInvoker { return instance.InvokeMethod(); }
- 动态关键字方法调用的动态替代：
如果您需要调用编译时未知的方法，我在下面添加了您可以使用的不同技术并更新了性能结果：
MethodInfo.CreateDelegate
_method = typeof (T).GetMethod("InvokeMethod");
_func = (Func<T, int>)_method.CreateDelegate(typeof(Func<T, int>));
注意：需要转换为 Func 以避免调用 DynamicInvoke（因为它通常较慢）。
DynamicMethod 和 ILGenerator.Emit
它实际上是从头开始构建完整的调用，它是最灵活的，但您必须具有一定的汇编程序背景才能完全理解它。
_dynamicMethod = new DynamicMethod("InvokeMethod", typeof (int), new []{typeof(T)}, GetType().Module);
ILGenerator il = _dynamicMethod.GetILGenerator();
il.Emit(OpCodes.Ldarg_0);
il.Emit(OpCodes.Call, _method);
il.Emit(OpCodes.Ret);
_func = (Func<T, int>) _dynamicMethod.CreateDelegate(typeof (Func<T, int>));
Linq 表达式
它类似于 DynamicMethod，但是您无法控制生成的 IL。不过，它确实更具可读性。
_method = typeof (T).GetMethod("InvokeMethod");
var instanceParameter = Expression.Parameter(typeof (T), "instance");
var call = Expression.Call(instanceParameter, _method);
_delegate = Expression.Lambda<Func<T, int>>(call, instanceParameter).Compile();
_func = (Func<T, int>) _delegate;
MethodInfo.Invoke
最后但并非最不重要的，标准的已知反射调用。 然而，即使它很容易搞砸，也不要使用它，因为它的性能确实很差（查看基准测试结果）。更喜欢 CreateDelegate，它确实更快。
_method = typeof (T).GetMethod("InvokeMethod");
return (int)_method.Invoke(instance, _emptyParameters);
基准测试的代码可以在GitHub上找到。
不同方法的基准测试 得到一个数量级（针对 1000 万次调用）(.NET Framework 4.5)：
For Class standard call:
Elapsed: 00:00:00.0532945
Call/ms: 188679
For MethodInfo.CreateDelegate call:
Elapsed: 00:00:00.1131495
Call/ms: 88495
For Keyword dynamic call:
Elapsed: 00:00:00.3805229
Call/ms: 26315
For DynamicMethod.Emit call:
Elapsed: 00:00:00.1152792
Call/ms: 86956
For Linq Expression call:
Elapsed: 00:00:00.3158967
Call/ms: 31746
For Extension Method call:
Elapsed: 00:00:00.0637817
Call/ms: 158730
For Generic Method call:
Elapsed: 00:00:00.0772658
Call/ms: 129870
For Interface virtual call:
Elapsed: 00:00:00.0778103
Call/ms: 129870
For MethodInfo Invoke call:
Elapsed: 00:00:05.3104416
Call/ms: 1883
For Visitor Accept/Visit call:
Elapsed: 00:00:00.1384779
Call/ms: 72463
== SUMMARY ==
Class standard call: 1
Extension Method call : 1,19
Generic Method call : 1,45
Interface virtual call : 1,45
MethodInfo.CreateDelegate call : 2,13
DynamicMethod.Emit call : 2,17
Visitor Accept/Visit call : 2,60
Linq Expression call : 5,94
Keyword dynamic call : 7,17
MethodInfo Invoke call : 100,19
编辑：
因此与访问者模式相比，动态调度只慢 3 倍。对于某些应用程序来说，它是可以接受的，因为它可以删除繁琐的代码。始终由您选择。
请记住所有缺点。
编辑：（作为对多重分派好处的回答）
使用像“multiple dispatch”这样的流行模式名称，并只是声明它更干净，因为它使用的代码更少，恕我直言，这并不能使它成为一个额外的好处。
如果你想写时髦的代码或者不关心类型安全和生产稳定性，已经有很多语言提供了全功能的动态类型。我将 C# 中的 dynamic 关键字引入视为缩小强类型语言家族与非强类型语言之间差距的一种方式。这并不意味着您应该改变开发方式并将类型检查扔到垃圾桶。
更新：2016/11/08 (.NET Framework 4.6.1)
数量级保持不变（即使其中一些有所改进）：
Class standard call: 1
Extension Method call : 1,19
Interface virtual call : 1,46
Generic Method call : 1,54
DynamicMethod.Emit call : 2,07
MethodInfo.CreateDelegate call : 2,13
Visitor Accept/Visit call : 2,64
Linq Expression call : 5,55
Keyword dynamic call : 6,70
MethodInfo Invoke call : 102,96
我不完全同意 Fabien 的观点，即它不会给您带来额外的好处。 他用访问者模式解决的问题称为 Multiple dispatch 动态也可以为此提供一个干净的解决方案。当然，您必须知道 Fabien 提到的含义，例如性能、静态类型检查...
public abstract class MyBaseClass
{
}
public class MyClass : MyBaseClass
{
}
public class MyAnotherClass : MyBaseClass
{
}
public class ClassThatIsUsingBaseClass
{
public static void PrintName(MyBaseClass baseClass)
{
Console.WriteLine("MyBaseClass");
}
public static void PrintName(MyClass baseClass)
{
Console.WriteLine("MyClass");
}
public static void PrintName(MyAnotherClass baseClass)
{
Console.WriteLine("MyAnotherClass");
}
public static void PrintNameMultiDispatch(MyBaseClass baseClass)
{
ClassThatIsUsingBaseClass.PrintName((dynamic)baseClass);
}
}
用法是
static void Main(string[] args)
{
MyBaseClass myClass = new MyClass();
MyBaseClass myAnotherClass = new MyAnotherClass();
ClassThatIsUsingBaseClass.PrintName(myClass);
ClassThatIsUsingBaseClass.PrintName(myAnotherClass);
ClassThatIsUsingBaseClass.PrintNameMultiDispatch(myClass);
ClassThatIsUsingBaseClass.PrintNameMultiDispatch(myAnotherClass);
Console.ReadLine();
}
输出为
MyBaseClass
MyBaseClass
MyClass
MyAnotherClass
搜索 "Multiple dispatch" 和 "C# multiple dispatch" 了解更多信息。
这个问题在 2015 年得到了回答，2019 年的今天，我们在 JavaScript 和 Typescript 中看到的模式确实有充分的理由使用动态；但是，这需要开发者谨慎。
private (Boolean Valid, dynamic Result) ValidatePersonID(int ID)
{
var person = _store.Persons.FirstOrDefault(person => person.ID == ID);
if (person == null)
{
string message = $"The person id {ID} does not exist, please try again.";
return (false, message);
}
return (true, person);
}
要使用上面的代码：
var operation = ValidatePersonID(personID);
if (operation.Valid == false)
{
//BadRequest takes a string and C# uses co-variance to make it work.
return BadRequest(operation.Result);
}
//otherwise just cast the type, but requires the cast to always work.
var pe = (Person)operation.Result;
...
有效性的 return 是 True 还是 False 决定了returned 的类型。我们仍然使用 BadRequest 上的强制转换和/或所需的输入类型来选择强类型。我们还选择了编译时类型检查，因为如果两个 returned 类型中的一个更改为字符串和/或人以外的其他内容，它将无法编译。
我认为这是一种依赖注入的形式，我们可以根据注入的内容实现不同的行为。 C# 纯粹主义者不喜欢这个想法，但 Typescript 的人一直在这样做。