题

有人可以建议我在写作时采取什么方法吗 C# 构造函数？

在其他语言，如 C++, ，一切都很好-你通常不会让内部字段可见，并为它们提供getter/setter。

这意味着，您可以为您的类提供构造函数，这些构造函数初始化所有/部分本地成员并感到高兴。

C#, 但是，已经 properties, ，这使我们可以写类似的东西:

Class x = new Class { Field1 = new Field1 ...., Field2 = new Field2 }

这允许链接对象构造，并且，正如我假设的那样，可以删除很多构造函数，如果我们没有构造函数，这将是必需的 properties.

将此与属性的默认值相结合，正如我假设的那样，我们可以完全摆脱非专业构造函数，这些构造函数实际上做了一些工作。

现在-是否可以删除冗余构造函数并允许通过字段初始化进行对象构造？

这种方法有什么缺点？有人可以给 一般性建议 关于结合字段和构造函数的用法，一些 rules of thumb, ，大概吧？

谢谢！.

有帮助吗？

解决方案

我自己的经验法则很简单:如果需要一些东西来完全构造对象，它应该是一个ctor参数。

一个很好的例子是StreamReader或BinaryReader之类的Stream helper对象之一。它们不能在没有关联的流对象的情况下运行，因此必须在构造函数中指定。

其他提示

在我看来，拥有你所说的冗余构造函数并没有错。如果你想定义一个构造函数有足够的意义，那可能是因为真正需要这样做。

构造函数可用于强制使用者向类提供值。

我的经验法则是字段用于可选数据，而构造函数可用于强制所需数据。

不过，这个问题是一个错误的二分法。C++的行为方式与C＃相同-"字段"（实际上是属性-字段是类级变量）通常用作设置内部值的getter/setter，并且 new 允许您设置字段的语法只是

Class x = new Class();
x.Field1 = new Field1();
x.Field2 = new Field2();

最佳做法是创建一个处于可用状态的对象;尝试限制对属性设置器的依赖。

它减少了创建不完整的对象的机会，并导致代码不那么脆弱。

您发布的代码使用的是所谓的对象初始化器，它们实际上只是最近引入的语法糖。使用对象初始化器只是调用构造函数的一种简写方式 和 设置属性。您应该继续在C＃中使用构造函数，就像在其他语言中使用它们一样-一般规则是，如果一个类 需要 一个要正确初始化的对象或值，该参数应该通过构造函数传递。如果该值不是必需的，则将其设置为可设置属性是合理的。

一般来说，我避免使用setters 果不其然 可能的时候（有很多很多情况下是不可能的）。

公共无参数构造然后是属性初始化的方法很受欢迎（需要？）对于在XAML中使用，很多WPF玩具都这样做。

您面临的唯一问题是部分初始化的对象，但您可以在尝试使用字段之前简单地验证对象状态。

就个人而言，我在构造函数中创建了critical values参数，我从对象的副本和一系列可选参数中创建了复制构造函数，并且我还没有制作需要由XAML使用的东西。

对象初始值设定项语法只是语法糖。即使在C＃1中，你也可以写

Class c = new Class();
c.Property1 = value1;
c.Property2 = value2;
c.Property3 = value3;
....

C＃3基本上将语法缩短为: 

Class c = new Class 
{
   Property1 = value1, 
   Property2 = value2, 
   Property3 = value3
   ....
}

Countstructor的重点不是只设置字段，构造函数应该根据参数逻辑构造对象，这样当构造函数返回时，你得到的是一个准备使用的对象。

可以吗？那要看情况而定。..

为了使用对象初始化器，您需要向所有字段公开公共设置器，您可能不希望这样做。如果你很乐意公开它们，那么我会说继续删除构造函数。然而，仅仅因为你 可以 做一些事情并不意味着你 应该.我会说删除构造函数应该是你做的事情，如果你发现你的所有字段都是公开可设置的，不要让字段设置为可设置只是为了让你删除构造函数。

我怀疑你在这里指的是域对象，但是在服务的情况下，通过构造函数将服务的依赖关系注入进来会使服务更加自我记录，而不是"更新"你的依赖关系。此外，这使您可以更轻松地使用依赖注入容器。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top