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

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

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

или

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

Любой входной сигнал будет значительно оценен

источник

2010-08-19 Aardvark

'this()' это хороший способ иметь автоматические свойства для типа struct и по-прежнему разрешать их устанавливать в параметризованном конструкторе. Без 'this()', он требует использования явных полей поддержки. –

@ Dan: Это замечательно, я никогда об этом не думал!В будущем я буду использовать 'this()' в структурах, которые имеют авто-свойства! Благодаря! – Timwi

Рекомендуется по возможности использовать this(). В противном случае вы будете дублировать некоторый код, который нарушает принцип DRY (Do not Repeat Yourself). Проблема с повторением себя заключается в том, что каждый раз, когда вам нужно внести изменения - даже если это простое изменение в одной строке кода, вы должны до запомнить, чтобы сделать в нескольких местах и сохранить несколько копии синхронизированы.

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

источник

2010-08-19 17:40:38 Timwi

Отличный ответ, и это определенно разъясняет мой вопрос. Я не видел принцип DRY, и я считаю, что это улучшит мой код по всем направлениям. Благодаря! – Aardvark

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

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

источник

2010-08-19 17:39:08 Will

Я согласен, что конструкторы цепочки лучше, чем копирование кода. Однако читаемость очень важна. В этом случае я думаю, что конструкторы цепочки более читабельны и гораздо надежнее. Но как общее утверждение, «не заботясь» о удобочитаемости, это опасная практика ИМО. –

@foo Багги и читабельны или неясны, но надежны? Конечно, это не всегда одна или иная ситуация, но если у вас есть выбор, чтобы сделать то или другое, лучше другое. Кроме того, самый нечитаемый код становится более понятным с применением комментариев кода! – Will

Эх, почему вы связываете «багги» с «читаемым»? Как насчет «читаемости и надежности»? Они не являются взаимоисключающими. –

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

источник

2010-08-19 17:39:09

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

источник

2010-08-19 17:41:05 Landei

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

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

DRY хорошая вещь :)

источник

2010-08-19 17:41:27 Josh

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

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

источник

2010-08-19 18:38:31

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

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

источник

2010-08-20 02:08:19

ответ

Смежные вопросы