Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
С# и объектно-ориентированное программирование.doc
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
1.3 Mб
Скачать
    1. Ключевое слово sealed

В С# поддерживается еще одно ключевое слово — sealed, которое предотвращает наследование. Если класс помечен как sealed (запечатанный), компилятор не позволяет наследовать от него.

Предположим, что в нашей иерархии классов появился класс – PTSalesPerson (от part-time продавцы на неполный рабочий день), который наследует существующему классу SalesPerson. Предположим, что мы хотим запретить производить какие либо классы от PTSalesPerson.

(этот код вставляем в проект EmployeeExample, пространство имен Employees)

Задание!!!: протестировать, исправить возможные ошибки

  1. Поддержка полиморфизма в с#

В базовом классе Employee был определен метод по имени GiveBonus() со следующей первоначальной реализацией:

public class Employee

{

……

public void GiveBonus(float amount)

{

currPay += amount;

}

…….

}

Поскольку этот метод был определен с ключевым словом public, теперь можно раздавать бонусы продавцам и менеджерам (а также продавцам с частичной занятостью):

static void Main(string[] args)

{

Console.WriteLine ("***** The Employee Class Hierarchy *****\n");

// Дать каждому сотруднику бонус

Manager списку = new Manager("Списку", 50, 92, 100000, “33-23-2322", 9000);

chucky.GiveBonus(100);

chucky.DisplayStats();

Console.WriteLine();

Salesperson fran = new Salesperson ("Fran", 43, 93, 3000, "932-32-3232", 31);

fran.GiveBonus(200);

fran.DisplayStats();

Console.ReadLine();

}

Проблема текущего кода состоит в том, что общедоступно унаследованный метод GiveBonus() работает идентично для всех подклассов. В идеале при подсчете бонуса для штатного продавца и частично занятого продавца должно приниматься во внимание количество продаж. Возможно, менеджеры должны получать дополнительные опционы на акции вместе с денежным вознаграждением. Учитывая это, попробуем ответить на вопрос: "Как сделать так, чтобы связанные типы по-разному реагировали на один и тот же запрос?" Для решения этой проблемы применяется полиморфизм.

    1. Ключевые слова virtual и override

Полиморфизм предоставляет подклассу способ определения собственной версии метода, определенного в его базовом классе, с использованием процесса, который называется переопределением метода (method overriding). Чтобы пересмотреть текущий дизайн, нужно понять значение ключевых слов virtual и override. Если базовый класс желает определить метод, который может быть (но не обязательно) переопределен в подклассе, он должен пометить его ключевым словом virtual. Методы, помеченные ключевым словом virtual, называются виртуальными методами.

(этот код вставляем в проект EmployeeExample, класс Employee, добавляем virtual в описании метода GiveBonus)

Задание!!!: протестировать, исправить возможные ошибки

Когда класс желает изменить реализацию деталей виртуального метода, он делает это с помощью ключевого слова override. Например, SalesPerson и Manager могли бы переопределить GiveBonus (), как показано ниже (предполагая, что PTSalesPerson не будет переопределять GiveBonus (), а потому просто наследует версию, определенную SalesPerson):

(этот код вставляем в проект EmployeeExample, класс SalesPerson)

(этот код вставляем в проект, класс Manager)

Задание!!!: протестировать, исправить возможные ошибки

Обратите внимание на использование каждым переопределенным методом поведения по умолчанию через ключевое слово base. Таким образом, полностью повторять реализацию логики GiveBonus () вовсе не обязательно, а вместо этого можно повторно использовать (и, возможно, расширять) поведение по умолчанию родительского класса. Также предположим, что текущий метод DisplayStatus () класса Employee объявлен виртуальным. При этом каждый подкласс может переопределять этот метод в расчете на отображение количества продаж (для продавцов) и текущих опционов на акции (для менеджеров). Например, рассмотрим версию метода DisplayStatus () в классе Manager

(этот код вставляем в проект EmployeeExample, класс Manager)

Задание!!! Реализовать аналогичным образом, вывод на консоль количества продаж (метод DisplayStatus () для класса SalesPerson). Протестировать, исправить возможные ошибки

Теперь, когда каждый подкласс может интерпретировать, что именно эти виртуальные методы означают для него, каждый экземпляр объекта ведет себя как более независимая сущность:

(этот код вставляем в проект EmployeeExample, метод Main)

Задание!!!: протестировать, исправить возможные ошибки