Здесь можно предположить, что класс Shape определяет некоторое количество членов, являющихся общими для всех наследников (скажем, значение для представления цвета фигуры, а также значения для высоты и ширины). Учитывая, что класс Hexagon расширяет Shape, он наследует основную функциональность, определяемую классами Shape и Object, и вдобавок сам определяет дополнительные детали, связанные с шестиугольником (какими бы они ни были).
На заметку! В рамках платформ .NET/.NET Core класс System.Object всегда находится на вершине любой иерархии классов, являясь первоначальным родительским классом, и определяет общую функциональность для всех типов (как подробно объясняется в главе 6).
В мире ООП существует еще одна форма повторного использования кода: модель включения/делегации, также известная как отношение "имеет" ("has-a") или агрегация. Такая форма повторного использования не применяется для установки отношений "родительский-дочерний". На самом деле отношение "имеет" позволяет одному классу определять переменную-член другого класса и опосредованно (когда требуется) открывать доступ к его функциональности пользователю объекта.
Например, предположим, что снова моделируется автомобиль. Может возникнуть необходимость выразить идею, что автомобиль "имеет" радиоприемник. Было бы нелогично пытаться наследовать класс Car (автомобиль) от класса Radio (радиоприемник) или наоборот (ведь Car не "является" Radio). Взамен есть два независимых класса, работающих совместно, где класс Car создает и открывает доступ к функциональности класса Radio:
class Radio
{
public void Power(bool turnOn)
{
Console.WriteLine("Radio on: {0}", turnOn);
}
}
class Car
{
<b> // Car 'имеет' Radio.</b>
private Radio myRadio = new Radio();
public void TurnOnRadio(bool onOff)
{
// Делегировать вызов внутреннему объекту.
myRadio.Power(onOff);
}
}
Обратите внимание, что пользователю объекта ничего не известно об использовании классом Car внутреннего объекта Radio:
// Call is forwarded to Radio internally.
Car viper = new Car();
viper.TurnOnRadio(false);
Роль полиморфизма
Последним основным принципом ООП является полиморфизм. Указанная характерная черта обозначает способность языка трактовать связанные объекты в сходной манере. В частности, данный принцип ООП позволяет базовому классу определять набор членов (формально называемый полиморфным интерфейсом), которые доступны всем наследникам. Полиморфный интерфейс класса конструируется с применением любого количества виртуальных или абстрактных членов (подробности ищите в главе 6).
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
Выражаясь кратко, виртуальный член — это член базового класса, определяющий стандартную реализацию, которую можно изменять (или более формально переопределять) в производном классе. В отличие от него абстрактный метод — это член базового класса, который не предоставляет стандартную реализацию, а предлагает только сигнатуру. Если класс унаследован от базового класса, в котором определен абстрактный метод, то такой метод должен быть переопределен в производном классе. В любом случае, когда производные классы переопределяют члены, определенные в базовом классе, по существу они переопределяют свою реакцию на тот же самый запрос.
Чтобы увидеть полиморфизм в действии, давайте предоставим некоторые детали иерархии фигур, показанной на рис. 5.3. Предположим, что в классе Shape определен виртуальный метод Draw(), не принимающий параметров. С учетом того, что каждой фигуре необходимо визуализировать себя уникальным образом, подклассы вроде Hexagon и Circle могут переопределять метод Draw() по своему усмотрению (см. рис. 5.3).
![]()
После того как полиморфный интерфейс спроектирован, можно начинать делать разнообразные предположения в коде. Например, так как классы Hexagon и Circle унаследованы от общего родителя (Shape), массив элементов типа Shape может содержать любые объекты классов, производных от этого базового класса. Более того, поскольку класс Shape определяет полиморфный интерфейс для всех производных типов (метод Draw() в данном примере), уместно предположить, что каждый член массива обладает такой функциональностью.
Рассмотрим следующий код, который заставляет массив элементов производных от Shape типов визуализировать себя с использованием метода Draw():
Shape[] myShapes = new Shape[3];
myShapes[0] = new Hexagon();
myShapes[1] = new Circle();
myShapes[2] = new Hexagon();
foreach (Shape s in myShapes)
{
// Использовать полиморфный интерфейс!
s.Draw();
}
Console.ReadLine();
На этом краткий обзор основных принципов ООП завершен. Оставшийся материал главы посвящен дальнейшим подробностям поддержки инкапсуляции в языке С#, начиная с модификаторов доступа. Детали наследования и полиморфизма обсуждаются в главе 6.
Модификаторы доступа C# (обновление в версии 7.2)
При работе с инкапсуляцией вы должны всегда принимать во внимание то, какие аспекты типа являются видимыми различным частям приложения. В частности, типы (классы, интерфейсы, структуры, перечисления и делегаты), а также их члены (свойства, методы, конструкторы и поля) определяются с использованием специального ключевого слова, управляющего "видимостью" элемента для других частей приложения. Хотя в C# для управления доступом предусмотрены многочисленные ключевые слова, они отличаются в том, к чему могут успешно применяться (к типу или члену). Модификаторы доступа и особенности их использования описаны в табл. 5.1.
