Според мен не е КПК да се инициализират променливи по този начин. 

Ако ти трябва default-на стойност за нещо - правиш го константа още когато го пишеш или го правиш readonly, подаваш стойност на конструктора, когато се мине през него му се присвоява стойността и повече не можеш да го пипаш, а само да го четеш. Пък ти си имай едно поле, което да е за текущата стойност и в началото да си взима default-ната такава, ако знаеш, че после ще го променяш.

А пък да зададеш стойности в началото на променлива, после да се подадат други и веднага да се заместят и оригиналните да не са били използвани, това пък тотално не му виждам логиката.

Тъй като говорим за полета в клас, знаем, че clr-a ги инициализира при инстанцииране то им с дефолтните стойности за дедените типове - т.е. Веднъж имаш задаване на стойности, ако не си го направил изрично. От друга страна е прието, че инициализацията на състоянието (state) на обекта се прави при инстанцииранено му или с други думи през конструктора на обекта и това ще ти е второто присвояване на стойност за твоите полета (ако не си им присвоил вече такава при декларирането им). Малко започна да става дълго, затова с две думи. Ако съответното поле няма да си променя стойността го инициализираш при декларацията му и направо го правиш константа или само за четене (както колегата по горе каза). Ако полето ще си сменя стойността през жизненият цикъл на класа, го инициализираш в конструктора с началната му такава ( било то чрез  параметър на конструктора или с фиксирана начална стойност) - това е добре да се прави дори за полета, които не са част от публичният интерфейс на класа (представени чрез пропъртита). 

Аз пък защо си мисля, че инициализацията на филдовете при създаване на обект взима default стойности само когато няма други зададени? Тоест според мен инициализация при декларацията си е ОК от тази гледна точка.

Даже що се отнася за статик класове бях чел, че по-добре така, отколкото през конструктор, тъй като е по-бързо. От друга страна обаче пък в MSDN-a прочетох, че е грешка при статични методи да се инициализират филдовете при декларация. Пък те се предполага да ги разбират тия неща :). Самият факт че го споменават обаче, означава, че при нормален клас не се счита за грешка. Но и аз не мога да се сетя за ситуация, при която това да е необходимо, освен може би за бързина?

private static int numberOfLegs = 4;

Спокойно може да стане константа. Освен ако нямаш някаква велика логика за рязане на крака или нещо друго садистко :) След като стане константа е оправдано да има стойност, най-малкото че това е идеята на константите :)

Инициализирането на статични стрингове в конструктор, също ми се струва безсмислено и овъркил и също така те кара да пишеш конструктор на събкласовете, за езиците където това не е нужно (в C# и Java е задължително на дериватите да пишеш конструктор, дори и той да не прави никаква логика, просто за да посочиш че изпълнява super/base конструктора, но в други езици като РНР например, има имплицит call на parent конструктора, ако не напишеш конструктор в дериватите) е излишен хем код, хем четене на логика.

Присвоването при инстанцирането в конструктор трябва да е обвързано с някаква логика - дали името идва отвън или например е конкатенирано с годините му. Ако годините идват отвън, например, "Sharo4" няма как да го напишеш директно в полето. Нито пък е редно да напишеш в полето "Sharo" а в конструктора да апенднеш "4".

В края на дена всъщност всичко зависи от логиката на апликейшъна ти.

Би било тъпо Шаро, който е на 5 години да можеш да му сетваш друго име, защото той вече отговаря на това и много трудно ще го научиш на друг бихейвиър.

И тогава ако искаш да експоузнеш "dogName" за пред публиката, най-лошото нещо което можеш да направиш е да направиш { get; set; }

Дефолтен гетър е ок, но директен сетър не. Всъщност, дори и логика в сетъра не е добра идея. Защото нека речем, че имаш система за продаване на кучета. 

Някой, когато иска да си купи кучето Шаро ще извади неговата инстанция от някъде (нека опростим до myDog = new Sharo()) и след това например, ще иска да му смени името.

За клиента не е важно дали ще пипа полето "dogName". За него е важно, кучето му да се казва, например, Боби.

Тогава най-логичното нещо е той да поиска да го преименува. И там се намесва метода Rename(), който прави това интърнали.

В такъв случай, код опростен до:

private string dogName = "Sharo";

public void Rename(String newName)

{

    if (this.age > 0.5) { // 6 months

        throw new Exception("....");

    }

    this.dogName = newName;

}

Инициализацията в декларацията в този случай ми се струва добра идея, тъй като когато кучето се е появило на бял свят, някой е решил, че това ще е шаро и го е присвоил към вече готовия клас за тип Шаро.

Ако обаче полето, по някаква причина, го направиш достъпно до останалия свят без каквито и да е обвързващи логики, то тогава би било редно да не го инициализираш в декларацията. Би било редно може би да бъде опшънъл параметър в конструктора. Ако никой не подаде име - ще се подаде Шаро. Пък в последствие ще си го смени през експоузнатия интерфейс.

В случай, че говорим за просто наследяване, където дериватите са просто ентитита и не изпълняват никаква допълнителна логика, смятам че минимализирането на веригата - в конкретния случай, писане на неща в конструктора - трябва да се следва.

Т.е.

abstract class Dog

{

    protected string name;

    public Dog(string param1, string param2) { ... }

    public void MyMethodOne() { ... }

    public void MyMethodTwo() { ... }

    // a lot of other methods

}

class Sharo : Dog

{

    protected string name = "Sharo";

    public Sharo(int param1, param2) : base(param1, param2);

}

class Bobi : Dog

{

    protected string name = "Bobi";

    public Bobi(int param1, param2) : base(param1, param2);

}

Тук ще се появи проблем обаче, ако param1 и param2 асайнват нещо към полета на Шаро и Боби. Не толкова, че може да се объркат стойности, въпреки че е възможно, а до това че ще имаш една част от полетата инициализирани по декларация, а друга - в конструктора. 

P.S.: Просто бъди констистентен - хванеш ли един начин за правене - ползвай него в целия апликейшън. В случая ако Шаро си го направил да е по декларация, Боби не го прави да е в конструктора.

Използвам темата, за да попитам и аз нещо по въпроса "какво е качествен клас". Кое е по-правилно: когато имам клас с няколко параметъра, да направя празен конструктор, конструктор с един параметър, с два и т.н., или да използвам колкото се може по-малко конструктора. Втори въпрос: ако трябва да имам повечко комбинации за конструкторите, кое е по-правилно - да ги изреждам един след друг, или да направя един конструктор с default-ни стойности. И трето - винаги ли е задължително да има празен конструктор? Ето пример, с който ще с е опитам да си изясня въпросите. Ако имам клас Person, включващ name, age, details, какви конструктори е по-правилно да има:

Person(){}

Person(string name){}

Person(string name, int age){}

Person(string name, int age, string details){}

или

Person(string name, int age, string details)

или

Person(string name, int age = default(int), string details = default(string)) (Това според мен е най-доброто, но виждам, че други хора ползват вариант 1.)

Ясно ми е, че въпросът до голяма степен зависи от самото приложение и какво се иска да прави то, но (предполагам) има и случаи, в които не е съвсем ясно кой параметър е важен и кой по-скоро опционален и трябва да се разчита на някакви базови правила.

Имам още едно въпрсоче, което смятам да го задам пак в тази тема. Кое е правилно - авоматичните property-та да са преди или след конструкторите?