Язык программирования C#9 и платформа .NET5 - Троелсен Эндрю - Страница 141

В нашем примере базовый класс

служит единственной цели — определять общие члены для всех подклассов. По всем признакам мы не намерены позволять кому-либо создавать непосредственные экземпляры типа , т.к. он концептуально чересчур общий. Например, если кто-то заявит, что он сотрудник, то тут же возникнет вопрос: сотрудник какого рода (консультант, инструктор, административный работник, литературный редактор, советник в правительстве)?

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

. В C# цели можно добиться за счет использования ключевого слова в определении класса, создавая в итоге абстрактный базовый класс:

Теперь попытка создания экземпляра класса

приводит к ошибке на этапе компиляции:

Определение класса, экземпляры которого нельзя создавать напрямую, на первый взгляд может показаться странным. Однако вспомните, что базовые классы (абстрактные или нет) полезны тем, что содержат все общие данные и функциональность для производных типов. Такая форма абстракции дает возможность считать, что "идея" сотрудника является полностью допустимой, просто это не конкретная сущность. Кроме того, необходимо понимать, что хотя непосредственно создавать экземпляры абстрактного класса невозможно, они все равно появляются в памяти при создании экземпляров производных классов. Таким образом, для абстрактных классов вполне нормально (и общепринято) определять любое количество конструкторов, которые вызываются косвенно, когда выделяется память под экземпляры производных классов.

На данной стадии у нас есть довольно интересная иерархия сотрудников. Мы добавим чуть больше функциональности к приложению позже, при рассмотрении правил приведения типов С#. А пока на рис. 6.4 представлено текущее проектное решение.

Полиморфные интерфейсы

Когда класс определен как абстрактный базовый (посредством ключевого слова

), в нем может определяться любое число абстрактных членов. Абстрактные члены могут применяться везде, где требуется определить член, который не предоставляет стандартной реализации, но должен приниматься во внимание каждым производным классом. Тем самым вы навязываете полиморфный интерфейс каждому наследнику, оставляя им задачу реализации конкретных деталей абстрактных методов.

Выражаясь упрощенно, полиморфный интерфейс абстрактного базового класса просто ссылается на его набор виртуальных и абстрактных методов. На самом деле это намного интереснее, чем может показаться на первый взгляд, поскольку данная характерная черта ООП позволяет строить легко расширяемые и гибкие приложения. В целях иллюстрации мы реализуем (и слегка модифицируем) иерархию фигур, кратко описанную в главе 5 во время обзора основных принципов ООП. Для начала создадим новый проект консольного приложения C# по имени

.

На рис. 6.5 обратите внимание на то, что типы

и расширяют базовый класс . Как и любой базовый класс. определяет набор членов (в данном случае свойство и метод ), общих для всех наследников.

Во многом подобно иерархии классов для сотрудников вы должны иметь возможность запретить создание экземпляров класса

напрямую, потому что он представляет слишком абстрактную концепцию. Чтобы предотвратить непосредственное создание экземпляров класса , его можно определить как абстрактный класс. К тому же с учетом того, что производные типы должны уникальным образом реагировать на вызов метода , пометьте его как и определите стандартную реализацию. Важно отметить, что конструктор помечен как , поэтому его можно вызывать только в производных классах.

Обратите внимание, что виртуальный метод

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