Методы класса Employee
В классе 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# требует, чтобы переопределяемые версии методов помечались явно, и будет инициировать ошибку компиляции, если этого не сделать. Это исключает риск любых потенциальных ошибок, когда, например, мы можем случайно переопределить метод без его реализации, возможно не зная, что метод с таким именем уже присутствует в базовом классе.
Мы завершили пример класса Employee как в VB, так и в C#, и до сих пор, хотя имеются некоторые неровности в создании и инициализации экземпляра Employee в версии VB, оба языка справились достаточно хорошо с требованиями. Однако одна из целей этого приложения состоит в том, чтобы показать, почему C# может быть в отдельных ситуациях значительно более мощным, чем VB6. Мы будем добавлять некоторые свойства в версию C# нашего примера, которые оставят VB далеко позади. Начнем со статических полей и свойств.
Статические члены
Мы упоминали несколько раз, что в C# классы имеют специальные методы, называемые статическими, которые можно вызвать, не создавая экземпляр объекта. Эти методы не имеют никакой аналогии в VB. Фактически, статическими могут быть не только методы, но и поля, свойства или любые другие члены класса.
Термин статический имеет совершенно другое значение в C#, чем в VB.
Чтобы проиллюстрировать, как работают статические члены и почему их необходимо использовать, давайте представим себе, что мы хотели бы, чтобы класс Employee поддерживал извлечение названия (имени) компании, в которой работает каждый сотрудник. Здесь имеется существенное различие между названием компании и именем сотрудника, так как каждый объект сотрудника представляет обособленную единицу, и поэтому необходимо хранить различные имена сотрудников. Это обычное поведение переменных модулей классов в VB и поведение по умолчанию полей в C#. Но если организация купила программное обеспечение, которое содержит класс Employee, то очевидно, что на всех сотрудников приходится одно и то же название компании. Это означает, что было бы избыточно хранить имя компании отдельно для каждого сотрудника. Будет просто ненужное дублирование строки. Вместо этого мы хотим сохранить имя компании только один раз и затем предоставить доступ к этим данным каждому объекту сотрудника. Именно так работает статическое поле. Объявим такое поле как companyName:
class Employee {
private string name;
private decimal salary;
private static readonly string companyName;
В этом коде объявлено еще одно поле, но, помечая его как static, мы инструктируем компилятор, что эту переменную нужно сохранить только один раз, независимо от того, сколько создано объектов Employee. В реальном смысле это статическое поле ассоциируется с классом как целым, а не с каким-то одним объектом.
Мы также объявили это поле используемым только для чтения. Такое указание имеет смысл, потому что название компании, так же как имя сотрудника, не должно меняться после запуска программы.
Конечно, одного объявления этого поля не достаточно. Необходимо также убедиться, что оно инициализируется правильными данными. Где это нужно сделать? Ясно, что не в конструкторе — конструктор вызывается всякий раз при создании объекта Employee, в то время как companyName нужно инициализировать только однажды. C# предоставляет для этой цели так называемый статический конструктор, который действует как любой другой конструктор, но работает для класса в целом, а не для определенного объекта. Если для класса определить статический конструктор, то он будет выполняться только один раз. Не гарантируется точно, когда он сработает, но это произойдет до того, как любой клиентский код попытается получить доступ к классу. Это обычно происходит при первом запуске программы. Добавим статический конструктор для класса Employee:
static Employee {
companyName = 'Wrox Press Pop Stars';
}
Как обычно, конструктор идентифицируется по имени, которое совпадает с именем класса. Этот конструктор обозначается также как static, следовательно, он является статическим конструктором. Он не помечен ни как public, ни как private, так как он не будет вызываться никаким кодом C#, а только средой выполнения .NET. Поэтому для статического конструктора не требуется модификатор доступа.
