Интернет-журнал "Домашняя лаборатория", 2007 №9
Шрифт:
public void Work
{
VirtMethod;
NonVirtMethod;
Analysis ;
}
При компиляции метода work будет обнаружено, что вызываемый метод VirtMethod является виртуальным, поэтому для него будет применяться динамическое связывание. Это означает, что вопрос о вызове метода откладывается до момента, когда метод Work будет вызван объектом, связанным с х. Объект может принадлежать как классу Found, так и классам Derived и ChildDerived, в зависимости от класса объекта
Для не виртуальных методов NonvirtMethod и Analysis будет применено статическое связывание, так что work всегда будет вызывать методы, принадлежащие классу Found. Однако и здесь не все просто. Метод NonVirtMethod
public void NonVirtMethod
{
Console.WriteLine ("Мать: "+ this.ToString );
}
в процессе своей работы вызывает виртуальный метод ToString. Опять-таки, для метода ToString будет применяться динамическое связывание, и в момент выполнения будет вызываться метод класса объекта.
Что же касается метода Analysis, определенного в каждом классе, то всегда в процессе работы work будет вызываться только родительский метод анализа из-за стратегии статического связывания.
Хочу обратить внимание на важный принципиальный момент. Вполне понятно, когда потомки вызывают методы родительского класса. Потомкам все известно о своих предках. Но благодаря полиморфизму методы родительского класса, в свою очередь, могут вызывать методы своих потомков, которых они совсем не знают и которые обычно и не написаны в момент создания родительского класса. Достигается это за счет того, что между родителями и потомками заключается жесткий контракт. Потомок, переопределяющий виртуальный метод, сохраняет сигнатуру метода, сохраняет атрибуты доступа, изменяя реализацию метода, но не форму его вызова.
Класс Found, создающий метод Work, говорит примерно следующее: "Я предоставляю этот метод своим потомкам. Потомок, вызвавший этот метод, должен иметь VirtMethod, выполняющий специфическую для потомка часть работы; конечно, потомок может воспользоваться и моей реализацией, но допустима и его собственная реализация. Затем часть работы выполняю я сам, но выдача информации об объекте определяется самим объектом. Заключительную часть работы, связанную с анализом, я потомкам не доверяю и делаю ее сам".
Пример работы с полиморфным семейством классов
Классы семейства с полиморфными методами уже созданы. Давайте теперь в клиентском классе Testing напишем метод, создающий объекты наших классов и вызывающий методы классов для объектов семейства:
public void TestFoundDerivedReal
{
Found bs = new Found ("father", 777);
Console.WriteLine("Объект bs вызывает методы класса Found");
bs.VirtMethod;
bs.NonVirtMethod ;
bs.Analysis; bs.Work;
Derived der = new Derived("child", 888, 555);
Console.WriteLine("Объект der вызывает методы класса Derived");
der.DerivedMethod;
der.VirtMethod;
der.NonVirtMethod ;
der.Analysis;
der.Work;
ChildDerived chider = new ChildDerived("grandchild", 999, 444);
Console.WriteLine("Объект chider вызывает методы ChildDerived");
chider.VirtMethod;
chider.NonVirtMethod;
chider.Analysis(5);
chider.Work;
}
Результаты работы этого метода изображены на рис. 18.3.
Рис. 18.3. Полиморфизм семейства классов
В последующих лекциях нам неоднократно встретятся более содержательные семейства классов с полиморфизмом, так что мы сумеем еще оценить мощь этого механизма ООП.
Абстрактные классы
С наследованием тесно связан еще один важный механизм проектирования семейства классов — механизм абстрактных классов. Начну с определений.
Класс называется абстрактным, если он имеет хотя бы один абстрактный метод.
Метод называется абстрактным, если при определении метода задана его сигнатура, но не задана реализация метода.
Объявление абстрактных методов и абстрактных классов должно сопровождаться модификатором abstract. Поскольку абстрактные классы не являются полностью определенными классами, то нельзя создавать объекты абстрактных классов. Абстрактные классы могут иметь потомков, частично или полностью реализующих абстрактные методы родительского класса. Абстрактный метод чаще всего рассматривается как виртуальный метод, переопределяемый потомком, поэтому к ним применяется стратегия динамического связывания.
Абстрактные классы являются одним из важнейших инструментов объектно-ориентированного проектирования классов. К сожалению, я не могу входить в детали рассмотрения этой важной темы и ограничусь лишь рассмотрением самой идеи применения абстрактного класса. В основе любого класса лежит абстракция данных. Абстрактный класс описывает эту абстракцию, не входя в детали реализации, ограничиваясь описанием тех операций, которые можно выполнять над данными класса. Так, проектирование абстрактного класса Stack, описывающего стек, может состоять из рассмотрения основных операций над стеком и не определять, как будет реализован стек — списком или массивом. Два потомка абстрактного класса — ArrayStack и ListStack могут быть уже конкретными классами, основанными на различных представлениях стека.
Вот описание полностью абстрактного класса Stack;
public abstract class Stack
{
public Stack
{ }
/// <summary>
/// втолкнуть элемент item в стек
/// </summary>
/// <param name="item"></param>
public abstract void put(int item);
/// <summary>
/// удалить элемент в вершине стека
/// </summary>
public abstract void remove;
/// <summary>
/// прочитать элемент в вершине стека
/// </summary>
public abstract int item;
/// <summary>
/// определить, пуст ли стек
/// </summary>
/// <returns></returns>
public abstract bool IsEmpty;
}
Описание класса содержит только сигнатуры методов класса и их спецификацию, заданную тегами <summary>. Построим теперь одного из потомков этого класса, реализация которого основана на списковом представлении. Класс ListStack будет потомком абстрактного класса Stack и клиентом класса Linkable, задающего элементы списка. Класс Linkable выглядит совсем просто: