
- •С# и объектно-ориентированное программирование. Содержание
- •Разбор простой программы на с#.
- •Варианты метода Main ()
- •Формальное определение класса в с#
- •2.1Ссылки на самого себя
- •Построение цепочки вызовов конструкторов с использованием this.
- •Модификаторы доступа с#
- •Средства инкапсуляции с#
- •Инкапсуляция с использованием традиционных методов доступа и изменения
- •Инкапсуляция с использованием свойств .Net
- •Свойства, доступные только для чтения и только для записи
- •Статические свойства
- •Статические конструкторы
- •Наследование в с#
- •Работа с конструктором базового класса
- •Множественное наследование.
- •Ключевое слово sealed
- •Поддержка полиморфизма в с#
- •Ключевые слова virtual и override
- •Абстрактные классы
- •Полиморфный интерфейс
- •Сокрытие методов
- •Правила приведения к базовому и производному классу
- •Ключевое слово as
- •Ключевое слово is
- •Применение модели включения – делегирования.
- •Определение вложенных типов
- •Обработка исключений
- •Роль обработки исключений в .Net
- •Составляющие процесса обработки исключений в .Net
- •Генерация общего исключения
- •Перехват исключений
- •Создание специальных исключений, способ первый
- •Обработка нескольких исключений.
- •Блок finally
- •Замечания по работе с исключениями
- •Время жизни объектов
- •Базовые сведения о времени жизни объектов
- •Роль корневых элементов приложения
- •Поколения объектов
- •Параллельная сборка мусора в версиях .Net 1.0 - .Net 3.5
- •Фоновая сборка мусора в версии .Net 4.0
- •Создание финализируемых объектов
- •Описание процесса финализации
- •Создание высвобождаемых объектов
- •Повторное использование ключевого слова using в с#
- •Взаимодействие со сборщиком мусора
- •Принудительная активизация сборки мусора
- •Создание финализируемых и высвобождаемых типов
- •Формализованный шаблон очистки
Ключевое слово sealed
В С# поддерживается еще одно ключевое слово — sealed, которое предотвращает наследование. Если класс помечен как sealed (запечатанный), компилятор не позволяет наследовать от него.
Предположим, что в нашей иерархии классов появился класс – PTSalesPerson (от part-time продавцы на неполный рабочий день), который наследует существующему классу SalesPerson. Предположим, что мы хотим запретить производить какие либо классы от PTSalesPerson.
(этот код вставляем в проект EmployeeExample, пространство имен Employees)
Задание!!!: протестировать, исправить возможные ошибки
Поддержка полиморфизма в с#
В базовом классе 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() работает идентично для всех подклассов. В идеале при подсчете бонуса для штатного продавца и частично занятого продавца должно приниматься во внимание количество продаж. Возможно, менеджеры должны получать дополнительные опционы на акции вместе с денежным вознаграждением. Учитывая это, попробуем ответить на вопрос: "Как сделать так, чтобы связанные типы по-разному реагировали на один и тот же запрос?" Для решения этой проблемы применяется полиморфизм.
Ключевые слова 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)
Задание!!!: протестировать, исправить возможные ошибки