: this () как конструктор

Question

Я пытаюсь получить лучшее понимание общей практики ... особенно выводя this () в конструкторе. Я понимаю, что это меньше кода, но я считаю его менее читабельным. Это обычная / хорошая практика, чтобы делать это таким образом? Или лучше написать второй конструктор, который обрабатывает его специально?

public SomeOtherStuff(string rabble) : this(rabble, "bloop") { }

или

Public SomeOtherStuff(string rabble)
{
    //set bloop
}

Любой вклад будет принята с благодарностью

Answer 1

Хорошей практикой является использование this(), когда это возможно. В противном случае вы будете дублировать некоторый код, который нарушает принцип СУХОГО (не повторяйте себя). Проблема с повторением заключается в том, что каждый раз, когда вам нужно внести изменение - даже если это простое изменение в одной строке кода - вам нужно запомнить , чтобы сделать то же самое изменение в нескольких местах и ​​синхронизируйте несколько копий.

Вы должны «дублировать» код только тогда, когда вам нужно, потому что он должен быть другим, чтобы он больше не был дубликатом. Таким образом, наличие дубликата означает для читателя сообщение о том, что код на самом деле другой, и это не просто так.

Answer 2

Проблема с двумя отдельными конструкторами заключается в том, что они часто содержат идентичный код, что может привести к проблемам с последующими рефакторингами, когда один конструктор изменяется, а другой нет.Таким образом, вы можете увидеть конструктор с использованием this () как применение принципа DRY .

Answer 3

Списки инициализации являются очень распространенной практикой в ​​промышленности.

Что касается читабельности ... это вопрос мнения. Но ремонтопригодность обычно является более высокой целью, к которой нужно стремиться.

СУХОЙ это хорошая вещь:)

Answer 4

Мне действительно нравится первый способ (цепочка конструктора), но если вы чувствуете, что второй способ более читабелен, тогда сделайте это, и вы можете поместить любой дублирующий код в конструкторы в частный метод, чтобы избежать нарушения принципа DRY.упомянул.

Кроме того, я также всегда стараюсь кодировать в стиле кода, над которым я работаю - поэтому, если преобладающим стилем является тот или иной, я бы согласился с этим стилем для согласованности.

Answer 5

Именно так вы связываете конструкторы, и это совершенно правильно.

Answer 6

еще один способ DRY - это написание метода инициализации, например, Init(rabble, bloop), и все конструкторы вызывают этот метод.

Это имеет тенденцию быть менее запутанным и более гибким, особенно когда имеется много конструкторов.

Answer 7

Меня меньше заботит читабельность, а больше надежность.

Цепные конструкторы намного лучше, чем тела метода копирования-вставки.