public override sealed void GiveBonus(float amount)
{
...
}
}
Здесь класс SalesPerson на самом деле переопределяет виртуальный метод GiveBonus, определенный в Employee, но явно помечает его как sealed. Таким образом, попытка переопределения метода GiveBonus в классе PtSalesPerson приведет к ошибке на этапе компиляции:
sealed class PTSalesPerson : SalesPerson
{
...
// Ошибка на этапе компиляции! Переопределять этот метод
// в классе PtSalesPerson нельзя, т.к. он был запечатан.
{
}
}
В настоящий момент базовый класс Employee спроектирован так, что поставляет различные данные-члены своим наследникам, а также предлагает два виртуальных метода (GiveBonus и DisplayStats), которые могут быть переопределены в наследниках. Хотя все это замечательно, у такого проектного решения имеется один весьма странный побочный эффект: создавать экземпляры базового класса Employee можно напрямую:
// Что это будет означать?
Employee X = new Employee;
В нашем примере базовый класс Employee служит единственной цели — определять общие члены для всех подклассов. По всем признакам мы не намерены позволять кому-либо создавать непосредственные экземпляры типа Employee, т.к. он концептуально чересчур общий. Например, если кто-то заявит, что он сотрудник, то тут же возникнет вопрос: сотрудник какого
Учитывая, что многие базовые классы имеют тенденцию быть довольно расплывчатыми сущностями, намного более эффективным проектным решением для данного примера будет предотвращение возможности непосредственного создания в коде нового объекта Employee. В C# цели можно добиться за счет использования ключевого слова abstract в определении класса, создавая в итоге
// Превращение класса Employee в абстрактный для
// предотвращения прямого создания его экземпляров.
abstract partial class Employee
{
...
}
Теперь попытка создания экземпляра класса Employee приводит к ошибке на этапе компиляции:
// Ошибка! Нельзя создавать экземпляр абстрактного класса!
Employee X = new Employee;
Определение класса, экземпляры которого нельзя создавать напрямую, на первый взгляд может показаться странным. Однако вспомните, что базовые классы (абстрактные или нет) полезны тем, что содержат все общие данные и функциональность для производных типов. Такая форма абстракции дает возможность считать, что "идея" сотрудника является полностью допустимой, просто это не конкретная сущность. Кроме того, необходимо понимать, что хотя
На данной стадии у нас есть довольно интересная иерархия сотрудников. Мы добавим чуть больше функциональности к приложению позже, при рассмотрении правил приведения типов С#. А пока на рис. 6.4 представлено текущее проектное решение.
Когда класс определен как абстрактный базовый (посредством ключевого слова abstract), в нем может определяться любое число
Выражаясь упрощенно, полиморфный интерфейс абстрактного базового класса просто ссылается на его набор виртуальных и абстрактных методов. На самом деле это намного интереснее, чем может показаться на первый взгляд, поскольку данная характерная черта ООП позволяет строить легко расширяемые и гибкие приложения. В целях иллюстрации мы реализуем (и слегка модифицируем) иерархию фигур, кратко описанную в главе 5 во время обзора основных принципов ООП. Для начала создадим новый проект консольного приложения C# по имени Shapes.
