使用动态 vs 接口作为参数的 C# 构造函数
由于在 C# 中创建干净的解耦代码的好处，我希望获得一些有关使用动态参数构造对象的反馈。通常，我相信您会创建一个接口并使用该接口作为契约，但是您必须为所有类创建接口，我认为这有点令人讨厌......
所以，我的问题是什么是优点和缺点做这样的事情：
class Class1
{
public string Description { get; set; }
public string Name { get; set; }
public Class1(dynamic obj)
{
Name = obj.Name;
Description = obj.Description;
}
}
vs
class Class1
{
public string Description { get; set; }
public string Name { get; set; }
public Class1(IClass1 obj)
{
Name = obj.Name;
Description = obj.Description;
}
}
In the benefit of creating clean decoupled code in c# I was hoping to get some feedback on using a dynamic parameter to construct objects. Typically I believe you'd create an interface and use the interface as the contract, but then you have to create interfaces for all your classes which I think is kind of icky...
So, my question is what are the pros and cons of doing something like this:
class Class1
{
public string Description { get; set; }
public string Name { get; set; }
public Class1(dynamic obj)
{
Name = obj.Name;
Description = obj.Description;
}
}
vs
class Class1
{
public string Description { get; set; }
public string Name { get; set; }
public Class1(IClass1 obj)
{
Name = obj.Name;
Description = obj.Description;
}
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
该接口的优点：
动态的优点：我个人通常使用 C# 作为静态类型语言，除非我正在与自然动态的东西交互（例如，我否则会使用反射，或者调用 COM 或 DLR）...但我可以看到，在某些情况下这可能很有用。只是不要做得太过分:)
Pros of the interface:
Pros of
dynamic:Personally I typically use C# as a statically typed language unless I'm interacting with something naturally dynamic (e.g. where I'd otherwise use reflection, or calling into COM or the DLR)... but I can see that in some cases this could be useful. Just don't over-do it :)
在这两种情况下，为了使方法按预期正常运行，传递到方法中的对象必须具有您的 Name 和 Description 属性。
我担心的是，使用动态的最佳实践是，您需要提供额外的方法文档，以确保其他程序员甚至您自己六个月后知道所传递的对象上必须存在的预期数据契约，甚至那么你真的应该将错误处理写入你的方法中，以确保它在合同被破坏时按预期运行。
所有这些潜在的陷阱是否超过了不编写接口的假设收益，在给出的示例中，接口实际上只有 5 行基本代码，然后它将完成您强迫自己手动执行的所有操作。
假设您希望遵循最佳实践，从而生成记录良好且易于阅读的代码。我倾向于使用界面来实现此目的。
In both scenarios for the method to function properly as expected the objects being passed into the method must have your Name and Description properties.
My concern is that the best practice for using a dynamic as you have, you would need to provide additional method documentation to ensure other programmers or even yourself six months from now know the expected data contracts that must be present on the object being passed and even then you really should write error handling into your method to ensure it functions as expected when that contract is broken.
Does all these potential gotchas out weight the hypothetical gain of not writing an interface which in the example given would be literally only a 5 basic lines of code, which would then do everything your forcing yourself to do manually.
Assuming you want to follow best practices which lead to well documented and easy to read code. I would lean towards using an interface for this purpose.