Мне понятно, что статический конструктор служит для присвоения значений статическим переменным, что он вызывается в первую очередь при создании объекта класса.
Но зачем он нужен, если я могу присвоить эти значения при объявлении переменных?
Ответ
В языке C# существует несколько способов инициализации полей:
В месте объявления
В конструкторе
Вот наивный пример:
class Foo
{
private string s1 = "s1";
private string s2;
private static string s3 = "s3";
private static string s4;
public Foo()
{
s2 = "s2";
}
static Foo()
{
s4 = "s4";
}
}
Если смотреть с высоты птичьего полета, то инициализация по месту реализуется довольно просто: выражение, использованое для инициализации поля переносится в соответствующий конструктор - в экземплярный конструктор для экземплярны полей и в статический конструктор для статических полей.
Тут нужно сказать, почему у нас два конструктора. Конструктор экземпляра - это некоторая вспомогательная функция, призванная инициализировать экземпляр создаваемого объекта. Например, мы можем сказать, что любой валидный объект должен обладать некоторым поведением (инвариантом) и конструктор - это специальная функция, обязанная его обеспечить. Инвариантом может быть что угодно: начиная от того, что некоторое поле не нулевое, заканчивая более сложными правилами, например, что сумма полей дебет и кредит равна 0.
Помимо инвариантов объектов существуют еще и инварианты типа: т.е. некоторые условия, которые должны быть верными не для конкретных объектов, но для типа целиком. Поведение типа выражается с помощью статических членов, а значит "инвариант" типа - это валидное состояние статичесих переменных, ответственность за валидность которых обеспечивает статический конструктор.
В отличие от конструктора объекта конструктор типа не вызывается пользователем. Вместо этого, он вызывается CLR в момент первого обращения к типу (опустим точные правила).
Существует тонкие различия в поведении во время исполнения, которое отличает использование инициализатора полей в месте объявления от инициализации этих же полей в конструкторе. Инициализаторы статических и экземплярных полей - это синтаксический сахар, но очень важно знать, какой именно!
Разница в случае экземплярных полей и конструкторов
Все инициализаторы экземплярных полей перемещаются компилятором C# в экземплярных конструктор. Но главный вопрос здесь: куда именно.
В общих чертах конструктор экземпляра выглядит следующим образом:
// ctor
// Код инициализаторов полей
// Вызов конструктора базового класса
// Код текущего конструктора
У данного алгоритма есть два важных следствия. Во-первых, код инициализаторов экземплярных полей не просто помещается в конструктор, он помещается в самое его начало, еще до вызова конструктора базового класса, и во-вторых, он будет скопирован во все экезмплярные конструкторы
Первое замечание очень важно (да, об этом могут спросить на собеседовании и это может пригодиться в реальных приложениях). Например, если кто-то вздумает вызвать виртуальный метод в конструкторе базового класса, то часть полей будет проинициализированы, а часть нет. Несложно догадаться, что поля, проинициализированные в месте объявления уже будут валидными, а другие поля будут содержать дефолтные значения.
Да, да, да, вызывать виртуальные методы в конструкторах базового класса - это плохо, но в реальность такое бывает и нужно понимать, что в этом случае будет в рантайме.
Разница в случае статических полей и конструкторов
Со статическими конструкторами дела обстоят несколько сложнее и проще одновременно. С точки зрения наследования, способ инициализации статических полей никак не пересекается с вызовом статического конструктора базового класса. Никак. Там вообще процесс вызова статических конструкторов отличается от экземплярных. Например, при создании экземпляра наследника вначале вызывается статический конструктор наследника, а потом статический конструктор базового класса. А если дергается статический метод наследника, то статический конструктор базового класса вообще не вызовется автоматом (вызовется только если статический метод наследника как-то дернет базовый тип).
Но сложность возникает с тем, когда именно будет вызван статический конструктор.
Как уже написал @Qwertiy наличие или отсутствие статического конструктора в классе влияет на то, когда будет вызван этот самый конструктор. Наличие статического конструктора приводит к генерации странного специального флага, который затем скажет CLR, что можно более вольно относиться к времени вызова статического конструктора, и сделать это теперь можно будет не прямо перед первым обращением, а, например, перед вызовом метода, в котором это обращение происходит.
Потенциально, это может повлиять на эффективность приложения, поскольку теперь проверка будет делаться один раз, а не тысячи раз, при условии, что первое обращение находится в цикле от 0 до 1000.
Заключение
Инциализатор полей (статических и нет) - это сахар, но он может быть с горчинкой, если не понимать, к чему приводит его чрезмерное использование.
Обычно я пользуюсь следующим эмпирическим правилом. Для экземплярных полей: нужно инициализировать поле аргументом конструктора - (без вариантов) использую конструктор; в противном случае - инициазатор полей. В случае статических полей: в подавляющем числе случаев использую инициализатор. Если кода много, то выделяю метод.
Если мне нужно использовать статический конструктор, чтобы задать порядок инициализации или изменить семантику инициализации типа, то я добавляю огромный комментарий, который говорит, почему к этому фрагменту кода нужно относитсья очень внимательно.
Если мне нужно использовать инициализатор для экземплярных полей, чтобы инициализация прошла до вызова конструктора базового класса, то я рефакторю код, чтобы этого было не нужно. Например, выделяю фабриный метод. Если же такоей поведение действительно нужно, то тут нужен двухстраничный комментарий, который объясняет почему это нужно и почему другие варианты не подходят.
Комментариев нет:
Отправить комментарий