Цель в том, чтобы создать семейство классов, моделирующих разнообразные типы сотрудников в компании. Предположим, что необходимо задействовать функциональность класса Employee при создании двух новых классов (SalesPerson и Manager). Новый класс SalesPerson "является" Employee (как и Manager). Вспомните, что в модели классического наследования базовые классы (вроде Employee) обычно применяются для определения характеристик, общих для всех наследников. Подклассы (такие как SalesPerson и Manager) расширяют общую функциональность, добавляя к ней специфическую функциональность.
В настоящем примере мы будем считать, что класс Manager расширяет Employee, сохраняя количество фондовых опционов, тогда как класс SalesPerson поддерживает хранение количества продаж. Добавьте новый файл класса (Manager.cs), в котором определен класс Manager со следующим автоматическим свойством:
// Менеджерам нужно знать количество их фондовых опционов.
class Manager : Employee
{
public int StockOptions { get; set; }
}
Затем добавьте еще один новый файл класса (SalesPerson.cs), в котором определен класс SalesPerson с подходящим автоматическим свойством:
// Продавцам нужно знать количество продаж.
class SalesPerson : Employee
{
public int SalesNumber { get; set; }
}
После того как отношение "является" установлено, классы SalesPerson и Manager автоматически наследуют все открытые члены базового класса Employee. В целях иллюстрации обновите операторы верхнего уровня, как показано ниже:
// Создание объекта подкласса и доступ к функциональности базового класса.
Console.WriteLine("***** The Employee Class Hierarchy *****\n");
SalesPerson fred = new SalesPerson
{
Age = 31, Name = "Fred", SalesNumber = 50
};
Вызов конструкторов базового класса с помощью ключевого слова base
В текущий момент объекты классов SalesPerson и Manager могут создаваться только с использованием "бесплатно полученного" стандартного конструктора (см. главу 5). Памятуя о данном факте, предположим, что в класс Manager добавлен новый конструктор с шестью аргументами, который вызывается следующим образом:
...
// Предположим, что у Manager есть конструктор с такой сигнатурой:
// (string fullName, int age, int empId,
// float currPay, string ssn, int numbOfOpts)
Manager chucky = new Manager("Chucky", 50, 92, 100000, "333-23-2322", 9000);
Взглянув на список параметров, легко заметить, что большинство аргументов должно быть сохранено в переменных-членах, определенных в базовом классе Employee. Чтобы сделать это, в классе Manager можно было бы реализовать показанный ниже специальный конструктор:
public Manager(string fullName, int age, int empId,
float currPay, string ssn, int numbOfOpts)
{
// Это свойство определено в классе Manager.
StockOptions = numbOfOpts;
// Присвоить входные параметры, используя
// унаследованные свойства родительского класса.
Id = empId;
Age = age;
Name = fullName;
Pay = currPay;
PayType = EmployeePayTypeEnum.Salaried;
// Если свойство SSN окажется доступным только для чтения,
// тогда здесь возникнет ошибка на этапе компиляции!
SocialSecurityNumber = ssn;
}
Первая проблема с таким подходом связана с тем, что если любое свойство определено как допускающее только чтение (например, свойство SocialSecurityNumber), то присвоить значение входного параметра string данному полю не удастся, как можно видеть в финальном операторе специального конструктора.