Симон Робинсон - C# для профессионалов. Том II

После объявления полей в приведенном выше коде располагается "метод", имя которого — Employee, совпадает с именем класса, то есть перед нами находится конструктор. Однако этот конструктор получает параметры и делает то же самое, что и метод Createв версии VB — он использует параметры для инициализации полей-членов:

public Employee(string name, decimal salary) {

this.name = name;

this.salary = salary;

}

Существует потенциальная синтаксическая проблема, так как явные имена параметров совпадают с именами полей — nameи salary. Но она разрешается с помощью использования ссылки this, помечающей поля. Можно было бы вместо этого дать параметрам другие имена, но способ, которым это было сделано, является достаточно ясным и означает, что параметры сохраняют очевидные простые имена, которые соответствуют их значениям. Это обычный способ действий для C# в таких ситуациях.

Теперь можно объяснить точное значение квалификатора readonlyперед именем поля:

private readonly string name;

Если поле помечено как readonly, то единственным местом, где ему может быть присвоено значение, является конструктор класса. Компилятор будет инициировать ошибку, если встретит код, который попытается изменить значение переменной readonly, в любом месте, кроме конструктора. Это предоставляет надежную гарантию, что переменная не будет изменена, если она была задана. Невозможно сделать что-либо подобное в VB, так как VB не имеет конструкторов, которые получают параметры, поэтому переменные уровня класса в VB должны быть инициализированы с помощью методов или свойств, вызываемых после создания экземпляра объекта.

Между прочим этот конструктор не просто позволяет задать параметры для инициализации объекта Employee— он заставляет это сделать. Если написать код следующего вида:

Employee Britney = new Employee; // неправильно

то он на самом деле не откомпилируется. Компилятор будет инициировать ошибку, так как в C# должен всегда вызываться конструктор, когда создается новый объект. Но никаких параметров задано не было, а единственный доступный конструктор требует двух параметров. Поэтому просто невозможно создать объект Employeeбез каких-либо параметров. Это страхует от ошибок, вызываемых неинициализированными объектами Employee.

Можно задать в классе более одного конструктора, чтобы выбрать, какое множество желательно использовать при создании нового объекта этого класса. Мы увидим, как это делается позже в данном приложении. Однако для этого конкретного класса единственного конструктора вполне достаточно.

Теперь мы переходим к свойствам Nameи Salary. Синтаксис C# для объявления свойства существенно отличается от соответствующего синтаксиса VB, но базовые принципы одинаковы. Необходимо определить два метода доступа(accessors) соответственно для "получения" и "задания" значений свойства. В VB они синтаксически интерпретируются как методы, но в C# свойство объявляется в целом, а затем определяются методы доступа внутри определения свойства.

public decimal Salary {

get {

return salary;

}

set {

salary = value;

}

}

В VB компилятор знает, что определяется свойство, так как используется ключевое слово Property. В C# эта информация передается тем, что за именем свойства немедленно следует открывающая фигурная скобка. Если определяется метод, то это будет открывающая скобка, указывающая начало списка параметров, в то время как для поля это будет точка с запятой, отмечающая конец определения.

Еще один момент, на который необходимо обратить внимание, состоит в том, что определения методов доступа getи setне содержат никаких списков параметров, это не важно. Мы знаем, что Salaryявляется десятичным значением, и метод доступа getвернет десятичное значение, не используя параметры, в то время как метод доступа setбудет получать один десятичный параметр и возвращать void. Для процедуры доступа setэтот параметр не объявляется явно, но компилятор всегда интерпретирует слово value как ссылающееся на него.

Здесь снова синтаксис определения свойств показывает, что в случае C# он является более компактным и может облегчить ввод кода.

Так же как в VB, если необходимо сделать свойство предназначенным только для чтения, то просто опускается метод доступа set, как было сделано для свойства Name:

public string Name {

get {

return name;

}

}

В классе Employeeсуществуют два метода — GetMonthlySalary()и ToString().

GetMonthlySalary()не требует комментариев, так как большая часть соответствующего синтаксиса C# уже была рассмотрена. Берется зарплата, делится на 12 для преобразования из годовой в месячную зарплату, и возвращается результат:

public decimal GetMonthlyPayment() {

return salary/12;

}

Единственным новым элементом синтаксиса здесь является инструкция return. В VB возвращаемое из метода значение определяют, задавая требуемое значение фиктивной переменной, которая имеет такое же имя, как и функция

GetMonthlyPayment = mCurSalary/12

В C# тот же самый результат получают, добавляя параметр в инструкцию return(без скобок). Также returnв C# определяет, что происходит выход их функции, поэтому инструкция C#:

return salary/12;

эквивалентна в действительности следующему коду VB:

GetMonthlyPayment = mCurSalary/12

Exit Function

Метод ToString()более интересен. В большинстве случаев при написании класса C# будет полезным создание метода ToString(), который может использоваться для получения быстрого просмотра содержимого объекта. Как упоминалось ранее, метод ToString()уже доступен, так как все классы наследуют его от System.Object. Однако версия в System.Objectвыводит только имя класса и никаких данных из экземпляра класса. Компания Microsoft уже переопределила этот метод для всех числовых типов данных ( int, floatи т.д.), чтобы выводить реальные значения переменных, и нелишне будет сделать то же самое для собственных классов программиста. В любом случае это может быть полезно для просмотра содержимого объекта во время отладки:

publiс override string ToString() {

return Name: " + name + ", Salary: $" + salary.ToString();

}

Эта переопределенная версия выводит имя и зарплату сотрудника. Новым элементом синтаксиса является то, что метод специально объявлен как override. C# требует, чтобы переопределяемые версии методов помечались явно, и будет инициировать ошибку компиляции, если этого не сделать. Это исключает риск любых потенциальных ошибок, когда, например, мы можем случайно переопределить метод без его реализации, возможно не зная, что метод с таким именем уже присутствует в базовом классе.