: this() В качестве конструктора

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

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

или

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

Приветствуется любой ввод.

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

СУХОЙ это хорошо :)

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

Конструкторы цепочек намного лучше, чем тела метода конструктора copypasting.

Ответ 7

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

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