在构造函数中或类的顶部创建对象
哪个声明/实例化更好,为什么?
public class MainWindow
{
private Test _test;
public MainWindow()
{
_test = new Test();
}
}
或
public class MainWindow
{
private Test _test = new Test();
public MainWindow()
{
}
}
which declaration/instantiation is better and WHY ?
public class MainWindow
{
private Test _test;
public MainWindow()
{
_test = new Test();
}
}
OR
public class MainWindow
{
private Test _test = new Test();
public MainWindow()
{
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(9)
问自己这个问题:当您向
MainWindow
添加其他构造函数时会发生什么?您是否希望必须记住调用其他构造函数以确保_test
正确初始化?或者如果使用另一个构造函数,_test
可以不初始化吗?就我个人而言,在创建 UI 组件时,我会尽可能多地将故障点移出构造函数,并将类似的内容移至 Loaded 事件处理程序,或者像在选项中那样保留它2(这使得初始化在文件中很好地本地化)。
Ask yourself this question: what happens when you add other constructors to
MainWindow
? Do you want to then have to remember to invoke other constructors to ensure that_test
is correctly initialized? Or is it okay for_test
to not be initialized if another constructor is used?Personally when creating a UI component I would move as many points of failure out of the constructor as possible, and I would move something like that to either the
Loaded
event handler, or keep it as you did in option 2 (which keeps the initialization nicely localized in the file).我会选择第三种选择:
通过注入依赖项,您可以使代码更容易进行单元测试。
I'd go for a third option:
By injecting the dependency you make your code easier to unit test.
最好在构造函数中执行此操作,以便清楚地了解创建对象时发生的情况,尤其是当您编写子类时。
一般来说,这只是个人喜好的问题,最重要的是保持您的选择一致。
It's better to do it inside the constructor to make it plain what's happening when the object is created, especially when you go to write subclasses.
Generally though it's a matter of taste and the most important thing is to be consistent in your choice.
之间的区别相同。
这与和
我的观点是,如果可能的话,初始化应该接近声明,在理想情况下是声明的一部分。除了可读性方面的好处之外,您忘记初始化的机会也更小。所以第二个变体是更好的一个。
This is the same as the difference between
and
My opinion is that the initialization should be close to the declaration if possible, in ideal case a part of it. Beside the bonus in readability you get smaller chances to forget the initialization. So the 2nd variant is a better one.
我不认为你可以说一个声明比另一个更好,这完全取决于你的表单的逻辑,如果你不想在表单启动时启动测试,而是单击按钮,然后单击第一个声明比较好。
I don't think you can say that one declaration is better then the other, it's all about the logic of your form, if you don't want to initiate Test on the form start-up, but on a button click then the first declaration is better.
后者,因为声明和初始化发生在同一行......更容易阅读,更难犯错误。
The latter, because declaration and initialization occur on the same line... easier to read, harder to make a mistake.
第二个是最干净的恕我直言。我通常只在需要使用参数初始化对象时才在构造函数中创建对象。
无参数
带参数:
正如Jackson Pope所说,为对象添加一个构造函数可能是一个好主意,以便以后更容易开始使用 DI。您可以在此处阅读有关 DI/IoC 的信息: http://www.codeproject.com/KB/架构/DependencyInjection.aspx
The second is cleanest imho. I usually only create objects in the constructor when they need to be initialized with parameters.
No parameters
with parameters:
As Jackson Pope said, it can be a good idea to add a constructor for the object to make it easier to start using DI's later on. You can read about DI/IoC here: http://www.codeproject.com/KB/architecture/DependencyInjection.aspx
在您给出的示例中,这两种选择都不是更好。这两个片段都在类的构造期间实例化成员变量。唯一真正的区别是,在第二种情况下,成员在执行构造函数之前初始化。
它真正产生影响的唯一时间是当成员变量需要传递到其构造函数中的信息时,Main 类在它的构造函数中获取信息。那么你别无选择,只能使用第二个选项。
例如:
In the example that you gave, neither of the to choices is better. Both of these snippets instantiate a member variable during construction of the class. The only real difference is that, in the second case, the member is initialized before the constructor is executed.
The only time that it really makes a difference is when the member variable needs information passed into its constructor that the Main class gets in it's constructor. Then you have no choice but to use the second option.
For example:
它根本没有什么区别,因为编译器生成完全相同相同的IL。就可读性而言,这只是个人喜好的问题。我更喜欢后一个版本,但带有
readonly
修饰符:当类具有多个构造函数时,这尤其容易阅读和维护。
It doesn't make a difference at all, because the compiler generates exactly the same IL. In terms of readability it is just a matter of personal taste. I prefer the latter version but with the
readonly
modifier:This is especially easier to read and to maintain when the class has more than one constructor.