: this() 作为构造函数
我试图更好地理解一般实践......特别是在构造函数中派生 this() 。我知道它的代码较少，但我认为它的可读性较差。这样做是常见/良好的做法吗？或者编写第二个专门处理它的构造函数更好？
public SomeOtherStuff(string rabble) : this(rabble, "bloop") { }
或
Public SomeOtherStuff(string rabble)
{
//set bloop
}
任何意见将不胜感激
I'm trying to get a better understanding of general practice... specifically deriving this() in a constructor. I understand that its less code, but I consider it less readable. Is it common/good practice to do it this way? Or is it better to write a second constructor that handles it specifically?
public SomeOtherStuff(string rabble) : this(rabble, "bloop") { }
or
Public SomeOtherStuff(string rabble)
{
//set bloop
}
Any input would be greatly appreciated
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
尽可能使用
this()是一种很好的做法。否则，您将重复一些代码，这违反了 DRY（不要重复自己）原则。重复自己的问题在于，每次您需要进行更改时（即使是对一行代码进行简单更改），您都必须记住做出相同 > 在多个地方进行更改，并保持多个副本同步。您应该仅在需要时“复制”代码，因为它需要不同，因此它不再是重复的。这样，有重复的代码就向读者传达了这样的信息：代码实际上是不同的，并且这是有原因的。
It is good practice to use
this()whenever possible. Otherwise you will be duplicating some code, which violates the DRY (Don’t Repeat Yourself) principle. The problem with repeating yourself is that every time you need to make a change — even if it’s a simple change to a single line of code — you have to remember to make the same change in multiple places, and keep the multiple copies synchronised.You should only “duplicate” the code when you need to because it needs to be different, so it’s no longer a duplicate. This way, having a duplicate is a message to the reader that the code is actually different, and is so for a reason.
两个单独的构造函数的问题在于，它们通常包含相同的代码，当一个构造函数发生更改而另一个构造函数没有更改时，这可能会导致以后的重构出现问题。因此，您可以将使用 this() 链接的构造函数视为DRY 原则的应用。
The problem with the two separate constructors is, that they often contain identical code, which may lead to problems with later refactorings, when one constructor is changed and the other not. So you could see constructor chaining with this() as an application of the DRY principle.
初始化列表是工业界非常常见的做法。
至于可读性……这是一个见仁见智的问题。但可维护性通常是一个更高的目标。
DRY 是一件好事:)
Initialization lists are very common practice in industry.
As for readability... that is a matter of opinion. But maintainability is usually a higher goal to strive for.
DRY is a good thing :)
这就是链接构造函数的方式，这是一件完全有效的事情。
That is how you chain constructors and it is a perfectly valid thing to do.
我真的很喜欢第一种方式（构造函数链接），但如果您觉得第二种方式更具可读性，那么就采用这种方式，您可以将构造函数中的任何重复代码放入私有方法中，以避免破坏人们提到的 DRY 原则。
另外，我也总是尝试以我正在处理的代码的风格进行编码 - 因此，如果主要风格是其中一种，我会采用该风格以保持一致性。
I really like the first way (constructor chaining) but if you feel the second way is more readable then go for that and you could put whatever duplicate code you have in the constructors into a private method to avoid breaking the DRY principle people have mentioned.
Also, I also always try to code in the style of the code I'm working on - so if the predominant style is one or the other, I'd go with that style for consistency.
我不太关心可读性，更关心可靠性。
链接构造函数比复制粘贴构造函数方法体要好得多。
I care less about readability and more for reliability.
Chaining constructors is much better than copypasting constructor method bodies.
另一种 DRY 方法是编写一个初始化方法，例如
Init(rabble, bloop)并且所有构造函数都调用此方法。这往往不会那么混乱并且更加灵活，尤其是在有很多构造函数的情况下。
another way to DRY is writing an initialization method, for example
Init(rabble, bloop)and all constructors calls this method.This tends to be less confusing and more flexible especially where there are many constructors.