Переопределение метода
Переопределенная версия метода GetMonthlyPayment() является достаточно простой. Отметим, что она помечена ключевым словом override для сообщения компилятору, что мы переопределяем метод базового класса, как это делалось с методом Employee.ToString():
public override decimal GetMonthlyPayment() {
return base.GetMonthlyPayment() + bonus/12;
}
Переопределенная версия содержит также вызов версии этого метода из базового класса. При этом используется новое ключевое слово base, base действует таким же образом, как и this, за исключением того, что оно специально указывает, что надо использовать метод или свойство и т.д. из определения базового класса. При желании можно альтернативно реализовать переопределенную версию метода GetMonthlyPayment() следующим образом:
public override decimal GetMonthlyPayment() {
return (Salary + bonus)/12;
}
но, чтобы показать использование ключевого слова base, был выбран другой вариант. В связи с этим есть одно действие, которое мы не смогли бы сделать:
public override decimal GetMonthlyPayment() {
return (salary + bonus)/12; // неправильно
}
Код выглядит почти так же, как предыдущая версия, кроме того, что поле salary используется непосредственно, а не через свойство Salary. Можно предположить, что это более эффективное решение, поскольку фактически убирается вызов метода. Но компилятор будет инициировать ошибку, так как поле salary объявлялось как private (закрытое). Этот означает, что ничему вне класса Employee не разрешается видеть это поле. Даже производные классы не знают о закрытых полях базового класса.
Если необходимо, чтобы производные, но не связанные классы могли видеть поле, C# предоставит альтернативный уровень защиты protected (защищенный):
protected decimal salary; // можно сделать так
Если член класса объявлен как защищенный, то он виден только в этом классе и в производных классах. Однако обычно строго рекомендуется сохранять все поля закрытыми (private) по той же причине, по которой требуется сохранять переменные закрытыми в модулях классов VB. Дело в том, что при сокрытии реализации класса (или модуля класса) облегчается выполнение будущего обслуживания этого класса. Обычно модификатор protected используется для свойств и методов, которые предназначены только для того, чтобы разрешать производным классам получать доступ к свойствам определения базового класса.
Конструкторы класса Manager
Давайте добавим по крайней мере один конструктор для класса Manager в связи с тем, что:
□ Существует дополнительный элемент информации — бонус менеджера, который необходимо определить, когда создается экземпляр объекта Manager.
□ В отличие от методов, свойств и полей, конструкторы не наследуются производными классами.
Фактически было добавлено два конструктора. Это связано с решением, что бонус менеджера обычно по умолчанию равен $100000, если он не определен явно. В VB можно определить в методах параметры по умолчанию, но C# не разрешает делать это напрямую. Вместо этого C# предлагает более мощную технику — перезагрузку методов, которая дает тот же результат. Определение в данном случае двух конструкторов позволяет проиллюстрировать эту технику.
Первый конструктор Manager имеет три параметра:
public Manager(string name, decimal salary, decimal bonus) : base(name, salary) {
this.bonus = bonus;
}
Прежде всего отметим вызов конструктора базового класса с помощью немного странного синтаксиса. Этот синтаксис называют инициализатором конструктора (constructor initializer.) При этом любому конструктору разрешается вызвать один другой конструктор перед своим выполнением. Этот вызов делается в инициализаторе конструктора с помощью показанного выше синтаксиса. Конструктор может вызвать либо другой конструктор того же класса, либо конструктор базового класса, что сделано с целью обеспечения хорошо спроектированной архитектуры конструкторов. Связанные с этим вопросы обсуждаются в главе 5. Синтаксис инициализатора конструктора требует двоеточия, за которым следует одно из ключевых слов base или this для определения, из какого класса вызывается второй конструктор, за которым следуют параметры, передаваемые этому второму конструктору.
Показанный выше конструктор получает три параметра. Однако два из них — name и salary, присутствуют там только для того, чтобы инициализировать поля базового класса в Employee. Эти параметры относятся на самом деле к классу Employee, а не Manager, поэтому они просто передаются конструктору Employee, с помощью чего делается вызов base(name, salary). Как мы видели раньше, конструктор Employee будет просто использовать эти параметры для инициализации полей name и salary. Наконец, мы передаем параметр bonus, имеющий отношение к классу Manager, и используем для инициализации поля bonus. Второй предоставленный конструктор Manager также применяет список инициализации конструктора:
public Manager(string name, decimal salary) : this(name salary, 100000M) {
}
В данном случае задается значение для параметра по умолчанию и затем все передается в конструктор с тремя параметрами. Конечно, в свою очередь, конструктор с тремя параметрами будет вызывать конструктор базового класса для работы с параметрами name и salary. Можно захотеть узнать, почему не использовался следующий альтернативный способ реализации конструктора с двумя параметрами:
public Manager(string name, decimal salary) : base(name, salary) // не очень хорошо
{
this.bonus = 100000M;
}
Причина в том, что это приводит к некоторому потенциальному дублированию кода: два конструктора каждый по отдельности инициализируют поле bonus, что может вызывать проблемы в будущем, если понадобится изменить оба конструктора, если в будущей версии Manager изменится способ хранения bonus. Обычно в C#, так же как и VB, стараются по возможности избегать дублирования кода. Таким образом, предыдущая реализация двухпараметрического конструктора считается более предпочтительной.
Тот факт, что для класса Manager было предоставлено два конструктора, иллюстрирует принцип перезагрузки методов в C#, в соответствии с которым предполагается, что класс имеет более одного метода с одним именем, но эти методы имеют различное число параметров. Мы продемонстрировали перезагрузку конструкторов, но точно такие же принципы применимы ко всем методам.
Не путайте термины перезагрузка и переопределение методов. Это различные и никак не связанные концепции.
Когда компилятор встречает вызов перезагруженного метода, он проверяет передаваемые параметры, чтобы определить, какой метод необходимо вызвать. В случае создания объекта менеджера, так как один конструктор получает три параметра, а другой только два, то компилятор прежде всего проверит число параметров. Следовательно, если написать:
Manager SomeManager = new Manager("Name", 300000.00M);
компилятор будет использовать для создания экземпляра объекта Manager конструктор с двумя параметрами, то есть bonus будет присвоено значение по умолчанию, равное 100000M. Если, с другой стороны, написать:
Manager SomeManager = new Manager("Name", 300000.00М, 50000.00М);
компилятор использует конструктор с тремя параметрами, поэтому bonus получит указанное значение 50000.00М. При наличии нескольких доступных перезагружаемых версий компилятор не сможет найти подходящую и проинициирует ошибку компиляции. Например, если написать.
Manager SomeManager = new Manager(100, 300000.00М, 50000.00М); // неправильно
то будет получена ошибка компиляции, так как оба доступных конструктора Manager требуют строку, а не числовой тип в качестве первого параметра. Компилятор C# может организовать некоторый тип преобразований между различными числовыми типами, которые будут выполняться автоматически, но он не будет автоматически преобразовывать из числового значения в строку.
Наконец, отметим, что C# не разрешает методам использовать параметры по умолчанию, как это делает VB. Однако легко получить тот же самый эффект с помощью перезагрузки методов, как это сделано в нашем примере. Обычный способ состоит просто в использовании перезагруженных версий, которые имеют меньше параметров, чтобы подставить значения по умолчанию для оставшихся параметров и затем вызывать другие перезагружаемые версии.
Использование классов Employee и Manager
Теперь, когда завершено определение классов Employee и Manager, напишем код, который их использует. Фактически, если загрузить исходный код этого проекта с web-сайта издательства Wrox press, то можно выяснить, что два эти класса определены как часть стандартного проекта форм Windows, достаточно похожего на пример SampleRoot. В данном случае, однако, основная форма имеет только один элемент управления — поле списка. Мы используем конструктор класса основной формы (класса с именем MainForm) для создания экземпляров объектов Employee и Manager, а затем выводим данные этих объектов в поле списка. Результат представлен ниже:
