Язык программирования C#9 и платформа .NET5

// Manager.cs
public override void DisplayStats()
{
  base.DisplayStats();
  // Вывод количества фондовых опционов
  Console.WriteLine("Number of Stock Options: {0}", StockOptions);
}
// SalesPerson.cs
public override void DisplayStats()
{
  base.DisplayStats();
  // Вывод количества продаж
  Console.WriteLine("Number of Sales: {0}", SalesNumber);
}
Теперь, когда каждый подкласс может истолковывать эти виртуальные методы значащим для него образом, их экземпляры ведут себя как более независимые сущности:
Console.WriteLine("***** The Employee Class Hierarchy *****\n");
// Лучшая система бонусов!
Manager chucky = new Manager("Chucky", 50, 92, 100000, "333-23-2322", 9000);
chucky.GiveBonus(300);
chucky.DisplayStats();
Console.WriteLine();
SalesPerson fran = new SalesPerson("Fran", 43, 93, 3000, "932-32-3232", 31);
fran.GiveBonus(200);
fran.DisplayStats();
Console.ReadLine();
Вот результат тестового запуска приложения в его текущем виде:
***** The Employee Class Hierarchy *****
Name: Chucky
ID: 92
Age: 50
Pay: 100300
SSN: 333-23-2322
Number of Stock Options: 9337
Name: Fran
ID: 93
Age: 43
Pay: 5000
SSN: 932-32-3232
Number of Sales: 31
  
Переопределение виртуальных членов с помощью Visual Studio/Visual Studio Code
 
Вы наверняка заметили, что при переопределении члена класса приходится вспоминать тип каждого параметра, не говоря уже об имени метода и соглашениях по передаче параметров (
ref
, 
out
 и 
params
). В Visual Studio и Visual Studio Code доступно полезное средство 
IntelliSense
, к которому можно обращаться при переопределении виртуального члена. Если вы наберете слово 
override
 внутри области действия типа класса (и затем нажмете клавишу пробела), то 
IntelliSense
 автоматически отобразит список всех допускающих переопределение членов родительского класса, исключая уже переопределенные методы.
 
Если вы выберете член и нажмете клавишу <Enter>, то IDE-среда отреагирует автоматическим заполнением заглушки метода. Обратите внимание, что вы также получаете оператор кода, который вызывает родительскую версию виртуального члена (можете удалить эту строку, если она не нужна). Например, при использовании описанного приема для переопределения метода 
DisplayStats()
 вы обнаружите следующий автоматически сгенерированный код:
public override void DisplayStats()
{
  base.DisplayStats();
}
  
Запечатывание виртуальных членов
 
Вспомните, что к типу класса можно применить ключевое слово 
sealed
, чтобы предотвратить расширение его поведения другими типами через наследование. Ранее класс 
PtSalesPerson
 был запечатан на основе предположения о том, что разработчикам не имеет смысла дальше расширять эту линию наследования.
Следует отметить, что временами желательно не запечатывать класс целиком, а просто предотвратить переопределение некоторых виртуальных методов в производных типах. В качестве примера предположим, что вы не хотите, чтобы продавцы с частичной занятостью получали специальные бонусы. Предотвратить переопределение виртуального метода 
GiveBonus()
 в классе 
PtSalesPerson
 можно, запечатав данный метод в классе 
SalesPerson
:
// Класс SalesPerson запечатал метод GiveBonus()!
class SalesPerson : Employee
{
  ...
public override sealed void GiveBonus(float amount)
  {
    ...
  }
}
Здесь класс 
SalesPerson
 на самом деле переопределяет виртуальный метод 
GiveBonus()
, определенный в 
Employee
, но явно помечает его как 
sealed
. Таким образом, попытка переопределения метода 
GiveBonus()
 в классе 
PtSalesPerson
 приведет к ошибке на этапе компиляции:
sealed class PTSalesPerson : SalesPerson
{
  ...
  // Ошибка на этапе компиляции! Переопределять этот метод
<div class="fb2-code"><code>  // в классе PtSalesPerson нельзя, т.к. он был запечатан.</code></div>
  {
  }
}
  
Абстрактные классы
 
 В настоящий момент базовый класс 
Employee
 спроектирован так, что поставляет различные данные-члены своим наследникам, а также предлагает два виртуальных метода (
GiveBonus()
 и 
DisplayStats()
), которые могут быть переопределены в наследниках. Хотя все это замечательно, у такого проектного решения имеется один весьма странный побочный эффект: создавать экземпляры базового класса 
Employee
 можно напрямую: