ооп теория

{

public Clain() {}

public void Prop1(string s)

{

Console.WriteLine(s);

}

public void Prop2(string name, int val)

{

Console.WriteLine("name = {0}, val ={1}", name, val);

}

}//Clain

Класс реализует методы интерфейса, делая их открытыми для клиентов класса и наследников. Другая стратегия реализации состоит в том, чтобы все или некоторые методы интерфейса сделать закрытыми. Для реализации этой стратегии класс, наследующий интерфейс, объявляет методы без модификатора доступа, что по умолчанию соответствует модификатору private, и уточняет имя метода именем интерфейса. Вот соответствующий пример:

public class ClainP:IProps

{

public ClainP(){ }

void IProps.Prop1(string s)

{

Console.WriteLine(s);

}

void IProps.Prop2(string name, int val)

{

Console.WriteLine("name = {0}, val ={1}", name, val);

}

}//class ClainP

Класс ClainP реализовал методы интерфейса IProps, но сделал их закрытыми и недоступными для вызова клиентов и наследников класса. Как же получить доступ к закрытым методам? Есть два способа решения этой проблемы:

Обертывание. Создается открытый метод, являющийся оберткой закрытого метода.

Кастинг. Создается объект интерфейсного класса IProps, полученный преобразованием (кастингом) объекта исходного класса ClainP. Этому объекту доступны закрытые методы интерфейса.

351

В чем главное достоинство обертывания? Оно позволяет переименовывать методы интерфейса. Метод интерфейса со своим именем закрывается, а

потом открывается под тем именем, которое класс выбрал для него. Вот пример обертывания закрытых методов в классе ClainP:

public void MyProp1(string s)

{

((IProps)this).Prop1(s);

}

public void MyProp2(string s, int x)

{

((IProps)this).Prop2(s, x);

}

Как видите, методы переименованы и получили другие имена, под которыми они и будут известны клиентам класса. В обертке для вызова закрытого метода пришлось использовать кастинг, приведя объект this к интерфейсному классу IProps.

ПРЕОБРАЗОВАНИЕ К КЛАССУ ИНТЕРФЕЙСА

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

(кастинга) объекта наследника к классу интерфейса. Это преобразование задается явно. Имея объект, можно вызывать методы интерфейса - даже если они закрыты в классе, для интерфейсных объектов они являются открытыми.

Приведу соответствующий пример, в котором идет работа как с объектами классов Clain, ClainP, так и с объектами интерфейсного класса IProps:

public void TestClainIProps()

{

Console.WriteLine("Объект класса Clain вызывает открытые методы!");

Clain clain = new Clain(); clain.Prop1(" свойство 1 объекта"); clain.Prop2("Владимир", 44);

Console.WriteLine("Объект класса IProps вызывает открытые методы!");

IProps ip = (IProps)clain; ip.Prop1("интерфейс: свойство");

352

ip.Prop2 ("интерфейс: свойство",77); Console.WriteLine("Объект класса ClainP вызывает

открытые методы!"); ClainP clainp = new ClainP();

clainp.MyProp1(" свойство 1 объекта"); clainp.MyProp2("Владимир", 44); Console.WriteLine("Объект класса IProps вызывает

закрытые методы!");

IProps ipp = (IProps)clainp; ipp.Prop1("интерфейс: свойство"); ipp.Prop2 ("интерфейс: свойство",77);

}

Этот пример демонстрирует работу с классом, где все наследуемые методы интерфейса открыты, и с классом, закрывающим наследуемые методы интерфейса. Показано, как обертывание и кастинг позволяют добраться до закрытых методов класса. Результаты выполнения этой тестирующей процедуры приведены на рис. 19.1.

Рис. 19.1. Наследование интерфейса. Две стратегии

ПРОБЛЕМЫ МНОЖЕСТВЕННОГО НАСЛЕДОВАНИЯ

При множественном наследовании классов возникает ряд проблем. Они остаются и при множественном наследовании интерфейсов, хотя становятся проще. Рассмотрим две основные проблемы - коллизию имен и наследование от общего предка.

КОЛЛИЗИЯ ИМЕН

Проблема коллизии имен возникает, когда два или более интерфейса имеют методы с одинаковыми именами и сигнатурой. Сразу же заметим, что если

353

имена методов совпадают, но сигнатуры разные, то это не приводит к конфликтам - при реализации у класса наследника просто появляются перегруженные методы. Но что следует делать классу-наследнику в тех случаях, когда сигнатуры методов совпадают? И здесь возможны две стратегии - склеивание методов и переименование.

Стратегия склеивания применяется тогда, когда класс - наследник интерфейсов - полагает, что разные интерфейсы задают один и тот же метод,

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

соответствующую методам всех интерфейсов, которые имеют единую сигнатуру.

Другая стратегия исходит из того, что, несмотря на единую сигнатуру,

методы разных интерфейсов должны быть реализованы по-разному. В этом случае необходимо переименовать конфликтующие методы. Конечно,

переименование можно сделать в самих интерфейсах, но это неправильный путь: наследники не должны требовать изменений своих родителей - они сами должны меняться. Переименование методов интерфейсов иногда невозможно чисто технически, если интерфейсы являются встроенными или поставляются сторонними фирмами. К счастью, мы знаем, как производить переименование метода интерфейса в самом классе наследника. Напомню,

для этого достаточно реализовать методы разных интерфейсов как закрытые,

а затем открыть их с переименованием.

Итак, коллизия имен при множественном наследовании интерфейсов хотя и возможна, но легко разрешается. Разработчик класса может выбрать любую из двух возможных стратегий, наиболее подходящую для данного конкретного случая. Приведу пример двух интерфейсов, имеющих методы с

354

одинаковой сигнатурой, и класса - наследника этих интерфейсов,

применяющего разные стратегии реализации для конфликтующих методов.

public interface IProps

{

void Prop1(string s);

void Prop2 (string name, int val); void Prop3();

}

public interface IPropsOne

{

void Prop1(string s); void Prop2 (int val); void Prop3();

}

У двух интерфейсов - по три метода с совпадающими именами, сигнатуры двух методов совпадают, а в одном случае различаются. Вот класс,

наследующий оба интерфейса:

public class ClainTwo:IProps,IPropsOne

{

///<summary>

///склеивание методов двух интерфейсов

///</summary>

///<param name="s"></param>

public void Prop1 (string s)

{

Console.WriteLine(s);

}

///<summary>

///перегрузка методов двух интерфейсов

///</summary>

///<param name="s"></param>

///<param name="x"></param>

public void Prop2(string s, int x)

{

Console.WriteLine(s + "; " + x);

}

public void Prop2 (int x)

{

Console.WriteLine(x);

}

///<summary>

///переименование методов двух интерфейсов

///</summary>

void IProps.Prop3()

{

Console.WriteLine("Свойство 3 интерфейса 1");

}

void IPropsOne.Prop3()

{

Console.WriteLine("Свойство 3 интерфейса 2");

}

public void Prop3FromInterface1()

355

{

((IProps)this).Prop3();

}

public void Prop3FromInterface2()

{

((IPropsOne)this).Prop3();

}

}

Для первого из методов с совпадающей сигнатурой выбрана стратегия склеивания, так что в классе есть только один метод, реализующий методы двух интерфейсов. Методы с разной сигнатурой реализованы двумя перегруженными методами класса. Для следующей пары методов с совпадающей сигнатурой выбрана стратегия переименования. Методы интерфейсов реализованы как закрытые методы, а затем в классе объявлены два новых метода с разными именами, являющиеся обертками закрытых методов класса.

Приведу пример работы с объектами класса и интерфейсными объектами:

public void TestCliTwoInterfaces()

{

Console.WriteLine("Объект ClainTwo вызывает методы двух интерфейсов!");

Cli.ClainTwo claintwo = new Cli.ClainTwo(); claintwo.Prop1("Склейка свойства двух интерфейсов"); claintwo.Prop2("перегрузка ::: ",99); claintwo.Prop2(9999); claintwo.Prop3FromInterface1(); claintwo.Prop3FromInterface2();

Console.WriteLine("Интерфейсный объект вызывает методы 1-го интерфейса!");

Cli.IProps ip1 = (Cli.IProps)claintwo; ip1.Prop1("интерфейс IProps: свойство 1"); ip1.Prop2("интерфейс 1 ", 88); ip1.Prop3();

Console.WriteLine("Интерфейсный объект вызывает методы 2-го интерфейса!");

Cli.IPropsOne ip2 = (Cli.IPropsOne)claintwo; ip2.Prop1("интерфейс IPropsOne: свойство1"); ip2.Prop2(7777);

ip2.Prop3();

}

Результаты работы тестирующей процедуры показаны на рис. 19.2.

356

Рис. 19.2. Решение проблемы коллизии имен

НАСЛЕДОВАНИЕ ОТ ОБЩЕГО ПРЕДКА

Проблема наследования от общего предка характерна, в первую очередь, для множественного наследования классов. Если класс C является наследником классов A и B, а те, в свой черед, являются наследниками класса Parent, то класс наследует свойства и методы своего предка Parent дважды, один раз получая их от класса A, другой от - B. Это явление называется еще дублирующим наследованием. Для классов ситуация осложняется тем, что классы A и B могли по-разному переопределить методы родителя и для потомков предстоит сложный выбор реализации.

Для интерфейсов сама ситуация дублирующего наследования маловероятна,

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

видимому, естественным решением этой проблемы в данной ситуации является склеивание, когда методам, пришедшим разными путями от одного родителя, будет соответствовать единая реализация.

Начнем наш пример с наследования интерфейсов:

public interface IParent

357

{

void ParentMethod();

}

public interface ISon1:IParent

{

void Son1Method();

}

public interface ISon2:IParent

{

void Son2Method();

}

Два сыновних интерфейса наследуют метод своего родителя. А теперь рассмотрим класс, наследующий оба интерфейса:

public class Pars:ISon1, ISon2

{

public void ParentMethod()

{

Console.WriteLine("Это метод родителя!");

}

public void Son1Method()

{

Console.WriteLine("Это метод старшего сына!");

}

public void Son2Method()

{

Console.WriteLine("Это метод младшего сына!");

}

}//class Pars

Класс обязан реализовать метод ParentMethod, приходящий от обоих интерфейсов.

Понимая, что речь идет о дублировании метода общего родителя - интерфейса IParent,

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

public void TestIParsons()

{

Console.WriteLine("Объект класса вызывает методы трех интерфейсов!");

Cli.Pars ct = new Cli.Pars(); ct.ParentMethod(); ct.Son1Method(); ct.Son2Method();

Console.WriteLine("Интерфейсный объект 1 вызывает свои методы!");

Cli.IParent ip = (IParent)ct; ip.ParentMethod();

Console.WriteLine("Интерфейсный объект 2 вызывает свои методы!");

Cli.ISon1 ip1 = (ISon1)ct; ip1.ParentMethod(); ip1.Son1Method();

358

Console.WriteLine("Интерфейсный объект 3 вызывает свои методы!");

Cli.ISon2 ip2 = (ISon2)ct; ip2.ParentMethod(); ip2.Son2Method();

}

Результаты работы тестирующей процедуры показаны на рис. 19.3.

Рис. 19.3. Дублирующее наследование интерфейсов

Встроенные интерфейсы

Рассмотрим несколько встроенных интерфейсов, являющихся частью библиотеки FCL. Они используются многими классами-библиотеками так же, как и классами, создаваемыми пользователем.

Упорядоченность объектов и интерфейс IComparable

Часто, когда создается класс, желательно задать отношение порядка на его объектах. Такой класс следует объявить наследником интерфейса

IComparable. Этот интерфейс имеет всего один метод CompareTo (object obj),

возвращающий целочисленное значение, положительное, отрицательное или равное нулю, в зависимости от выполнения отношения "больше", "меньше"

или "равно".

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

359

Давайте введем отношение порядка на классе Person, рассмотренном в лекции 16, сделав этот класс наследником интерфейса IComparable.

Реализуем в этом классе метод интерфейса CompareTo:

public class Person:IComparable

{

public int CompareTo( object pers)

{

const string s = "Сравниваемый объект не принадлежит классу Person";

Person p = pers as Person; if (!p.Equals(null))

return (fam.CompareTo(p.fam)); throw new ArgumentException (s);

}

// другие компоненты класса

}

Поскольку аргумент метода должен иметь универсальный тип object, то перед выполнением сравнения его нужно привести к типу Person. Это приведение использует операцию as, позволяющую проверить корректность выполнения приведения.

При приведении типов часто используются операции is и as. Логическое выражение (obj is T) истинно, если объект obj имеет тип T. Оператор присваивания (obj = P as T;) присваивает объекту obj объект P, приведенный к типу T, если такое приведение возможно, иначе объекту присваивается значение null. Семантику as можно выразить следующим условным выражением: (P is T) ? (T)P : (T)null.

Заметьте также, что при проверке на значение null используется отношение

Equals, а не обычное равенство, которое будет переопределено.

Отношение порядка на объектах класса Person задается как отношение порядка на фамилиях персон. Так как строки наследуют интерфейс

IComparable, то для фамилий персон вызывается метод CompareTo, его результат и возвращается в качестве результата метода CompareTo для

360