ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание - Эндрю Троелсен

Рис. 7.1. Иерархия форм (теперь с интерфейсами)

Интерфейсы в сравнении с абстрактными базовыми классами

С учетом знаний, полученных в главе 4, вы можете спросить, какова причина выдвижения типов интерфейса на первое место. Ведь в C# позволяется строить абстрактные типы класса, содержащие абстрактные методы. И, подобно интерфейсу, при получении класса из абстрактного базового класса, класс тоже обязан определить детали абстрактных методов (если, конечно, производный класс не объявляется абстрактным). Однако возможности абстрактных базовых классов выходят далеко за рамки простого определения группы абстрактных методов. Они могут определять открытые, приватные и защищенные данные состояния, а также любое число конкретных методов, которые оказываются доступными через подклассы.

Интерфейсы, с другой стороны, – это чистый протокол. Интерфейсы никогда не определяют данные состояния и никогда не обеспечивают реализацию методов (при попытке сделать это вы получите ошибку компиляции).

public interface IAmABadInterface {

 // Ошибка! Интерфейс не может определять данные!

 int myInt = 0;

 // Ошибка! Допускается только абстрактные члены!

 void MyMethod() {Console.WriteLine("Фи!");}

}

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

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

Вызов членов интерфейса на уровне объекта

Теперь, когда у вас есть набор типов, поддерживающих интерфейс Pointy, следующей задачей оказывается доступ я новым функциональным возможностям. Самым простым способом обеспечения доступа к функциональным возможностям данного интерфейса является непосредственный вызов методов на уровне объектов. Например:

static void Main(string[] args) {

 // вызов члена Points интерфейса IPointy.

 Hexagon hex = new Hexagon();

 Console.WriteLine("Вершин: {0}", hex.Points);

 Console.ReadLine();

}

Этот подход прекрасно работает в данном конкретном случае, поскольку вы знаете, что тип Hexagon реализует упомянутый интерфейс. Однако в других случаях во время компиляции вы не сможете определить, какие интерфейсы поддерживаются данным типом. Предположим, например, что у нас есть массив из 50 типов, соответствующих Shape, но только некоторые из них поддерживают IPointy. Очевидно, что если вы попытаетесь вызвать свойство Points для типа, в котором IPointy не реализован, вы получите ошибку компиляции. Возникает следующий вопрос: "Как динамически получить информацию о множестве интерфейсов, поддерживаемых данным типом?"

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

static void Main(string[] args) {

 …

 // Возможный захват исключения InvalidCastException.

 Circle с = new Circle ("Lisa");

 IPointу itfPt;

 try {

  itfPt = (IPointy)c;

  Console.WriteLine(itfPt.Points);

 } catch (InvalidCastException e) {

  Console.WriteLine(e.Message);

 }

 Console.ReadLine();

}

Итак, можно использовать логику try/catch и надеяться на удачу, но лучше еще до вызова членов интерфейса определить, какие интерфейсы поддерживаются. Мы рассмотрим два варианта такой тактики.

Получение интерфейсных ссылок: ключевое слово as

Второй способ проверить поддержку интерфейса для данного типа предполагает использование ключевого слова as, о котором уже шла речь в главе 4. Если объект можно интерпретировать, как указанный интерфейс, будет возвращена ссылка на интерфейс. Если нет – вы получите null.

static void Main(string[] args) {

 …

 // Можно ли интерпретировать hex2, как IPointy?

 Hexagon hex2 = new Hexagon("Peter");

 IPointy itfPt2 = hex2 as IPointy;

 if (itfPt2 != null) Console.WriteLine("Вершин: {0}", itfPt2.Points);

 else Console.WriteLine("ОЙ! Вершин не видно…");

}

Обратите внимание на то, что при использовании ключевого слова as не возникает необходимости использовать логику try/catch, поскольку в том случае, когда ссылка оказывается непустой, вы гарантированно будете иметь действительную ссылку на интерфейс.

Получение интерфейсных ссылок: ключевое слово is

Можно также проверить реализацию интерфейса с помощью ключевого слова is. Если соответствующий объект не совместим указанным интерфейсом, будет возвращено значение false. А если тип совместим с интерфейсом, вы можете смело вызвать его члены без использования логики try/catch.

Для примера предположим, что мы изменили массив типов Shape так, что теперь некоторые его члены реализуют IPointy. Вот как с помощью ключевого слова is можно выяснить, какие из элементов в массиве поддерживают этот интерфейс.

static void Main(string[] args) {

 …

 Shape[] s = {new Hexagon(), new Circle(), new Triangle("Joe"), new Circle("JoJo")};

 for (int i = 0; i ‹ s.Length; i++) {

  // Напомним, что базовый класс Shape определяет абстрактный

  // член Draw(), поэтому все формы могут отображать себя.

  s[i].Draw()

  // Кто с вершинами?

  if (s[i] is IPointy) Console.WriteLine("-› Вершин: {0} ", ((IPointy)s[i]).Points);

  else Console.WriteLine("-› {0} без вершин!", s[i].PetName);

 }

}

Соответствующий вывод показан на рис. 7.2.

Рис 7.2. Динамическое обнаружение реализованных интерфейсов

Интерфейсы в качестве параметров

Поскольку интерфейсы являются полноценными типами .NET, вы можете конструировать методы, которые будут использовать интерфейсы, как параметры. Для примера предположим, что мы определили другой интерфейс с именем IDraw3D.

// Моделируем возможность отображения типа в пространстве.

public interface IDraw3D {

 void Draw3D();

}

Предположим также, что две из наших трех форм (Circle и Hexagon) сконфигурированы для поддержки этого нового поведения.

// Circle поддерживает IDraw3D.

public class Circle: Shape, IDraw3D {

 …

 public void Draw3D() {

  Console.WriteLine("3D-отображение окружности!");

 }

}

// Hexagon поддерживает IPointy и IDraw3D.

public class Hexagon: Shape, IPointy, IDraw3D {

 …

 public void Draw3D() { Console.WriteLine ("3D-отображение шестиугольника!"); }

}

На рис. 7.3 показана соответствующая обновленная диаграмма классов, полученная в Visual Studio 2005.

Рис. 7.3. Обновленная иерархия форм

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

// Создание нескольких форм.

// Если это возможно, их отображение в трехмерном виде.

public class Program {

 // Отображение форм, поддерживающих IDraw3D.

 public static void DrawIn3D(IDraw3D itf3d) {

  Console.WriteLine("-› Отображение IDraw3D-совместимого типа");

  itf3d.Draw3D();

 }

 static void Main() {

  Shape [] s = {new Hexagon(), new Circle(), new Triangle("Joe"), new Circle("JoJo")};

  for (int i = 0; i ‹ s.Length; i++) {

   …

   // Можно ли отобразить в 3D-виде?

   if (s[i] is IDraw3D) DrawIn3D((IDraw3D)s[i]);

  }

 }

}

Обратите внимание на то, "что треугольник не отображается, поскольку он не является IDraw3D-совместимым (рис. 7.4).

Рис.7.4. Интерфейсы в качестве параметров