Оператор goto

Оператор if

Оператор присваивания

Оператор return

Оператор switch

Операторы break и continue

Операторы языка C#

Операторы перехода

Операторы выбора

Описание методов (процедур и функций). Синтаксис

Определенное присваивание

Организация интерфейса

• команды пункта главного меню Create позволяют создавать геометрические фигуры разных классов;
• команды пункта главного меню Show позволяют показать или стереть текущую фигуру или все фигуры, сохраняемые в списке;
• две команды пункта Scale позволяют изменить масштаб фигуры (увеличить ее или уменьшить);
• команды пункта Move позволяют перемещать текущую фигуру в четырех направлениях;
• команды пункта Color позволяют либо задать цвет фигур в диалоговом окне, либо выбрать один из предопределенных цветов;
• группа команд пункта List позволяет помещать текущую фигуру в список, перемещаться по списку и удалять из списка ту или иную фигуру;
• командные кнопки инструментальной панели соответствуют наиболее важным командам меню;
• реализована возможность перетаскивания фигур по экрану мышью.

Организация интерфейса

Организация меню в формах

Основные методы

• public StringBuilder Append (<объект>). К строке, вызвавшей метод, присоединяется строка, полученная из объекта, который передан методу в качестве параметра. Метод перегружен и может принимать на входе объекты всех простых типов, начиная от char и bool до string и long. Поскольку объекты всех этих типов имеют метод ToString, всегда есть возможность преобразовать объект в строку, которая и присоединяется к исходной строке. В качестве результата возвращается ссылка на объект, вызвавший метод. Поскольку возвращаемую ссылку ничему присваивать не нужно, то правильнее считать, что метод изменяет значение строки;
• public StringBuilder Insert (int location,<объект>). Метод вставляет строку, полученную из объекта, в позицию, указанную параметром location. Метод Append является частным случаем метода Insert;
• public StringBuilder Remove (int start, int len). Метод удаляет подстроку длины len, начинающуюся с позиции start;
• public StringBuilder Replace (string str1,string str2). Все вхождения подстроки str1 заменяются на строку str2;
• public StringBuilder AppendFormat (<строка форматов>, <объекты>). Метод является комбинацией метода Format класса String и метода Append. Строка форматов, переданная методу, содержит только спецификации форматов. В соответствии с этими спецификациями находятся и форматируются объекты. Полученные в результате форматирования строки присоединяются в конец исходной строки.

Открытость

Отладка и инструментальная среда Visual Studio .Net

Отладка

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

Отладочная печать и условная компиляция

• функцией, возвращающей значение;
• методом интерфейса;
• методом с модификатором override. Возможно его задание для virtual-метода. В этом случае атрибут наследуется методами потомков.

Отношение вложенности

Отношения "является" и "имеет"

Отношения между классами

Отношения между клиентами и поставщиками

Параллельная работа обработчиков исключений

Паутина Безье

Печать рациональных чисел

Перечисление RegexOptions

Перечисления

• как и другие классы, перечисления могут быть объявлены непосредственно в пространстве имен проекта или могут быть вложены в описание класса. Последний вариант часто применяется, когда перечисление используется в одном классе и имеет атрибут доступа private;
• константы разных перечислений могут совпадать, как в перечислениях MyColors и TwoColors. Имя константы всегда уточняется именем перечисления;
• константы могут задаваться словами русского языка, как в перечислении Rainbow;
• разрешается задавать базовый класс перечисления. Для перечисления Days базовым классом задан класс long;
• разрешается задавать не только базовый класс, но и указывать начальный элемент подмножества, на которое проецируется множество значений перечисления. Для перечисления Sex в качестве базового класса выбран класс byte, а подмножество значений начинается с 1, так что хранимым значением константы man является 1, а woman - 2.

• объекты перечислений нельзя создавать в объектном стиле с использованием операции new, поскольку перечисления не имеют конструкторов;
• объекты можно объявлять с явной инициализацией, как color1, или с отложенной инициализацией, как color2. При объявлении без явной инициализации объект получает значение первой константы перечисления, так что color2 в момент объявления получает значение black;
• объекту можно присвоить значение, которое задается константой перечисления, уточненной именем перечисления, как для color1 и color2. Можно также задать значение базового типа, приведенное к типу перечисления, как для color3;
• нельзя сравнивать объекты разных перечислений, например color1 и color2, но можно сравнивать строки, возвращаемые методом ToString, например color1.ToSting() и color2.ToString();
• существуют явные взаимно обратные преобразования констант базового типа и констант перечисления;
• Метод ToString, наследованный от класса Object, возвращает строку, задающую константу перечисления.

Передача информации между формами

Перегрузка операций

Переопределение значений аргументов события

• В классе ChangedEventArgs следует изменить процедуру-свойство Item, удалив процедуру Set, разрешающую изменение свойства. В качестве компенсации в класс следует добавить конструктор с аргументом, что позволит в классе, создающем событие, создавать объект класса ChangedEventArgs с нужным значением свойства item. Приведу соответствующий код: public object Item { get {return(item);} //set { item = value;} } public ChangedEventArgs(object item) { this.item = item; }
• В методы класса ListWithChangedEvent, зажигающие события, нужно ввести изменения. Теперь перед каждым вызовом нужно создавать новый объект, задающий аргументы. Вот измененный код: public override int Add(object value) { int i=0; ChangedEventArgs evargs = new ChangedEventArgs(value); //evargs.Item = value; OnChanged(evargs); if (evargs.Permit) i = base.Add(value); else Console.WriteLine("Добавление элемента запрещено." + "Значение = {0}", value); return i; } public override void Clear() { ChangedEventArgs evargs = new ChangedEventArgs(0); //evargs.Item=0; OnChanged(evargs); base.Clear(); } public override object this[int index] { set { ChangedEventArgs evargs = new ChangedEventArgs(value); //evargs.Item = value; OnChanged(evargs); if (evargs.Permit) base[index] = value; else Console.WriteLine("Замена элемента запрещена." + " Значение = {0}", value); } get {return(base[index]);} }

Персоны и профессии

Первый закон (закон для разработчика)

Почему у методов мало аргументов?

Поля класса или функции без аргументов?

Поля класса

Поля

Построение программных систем методом "раскрутки". Функции обратного вызова

Преобразование к классу интерфейса

Преобразование к типу object

Преобразования и класс Convert

(ToBoolean(),...ToUInt64()), где Type может принимать значения от Boolean до UInt64 для всех встроенных типов, перечисленных в таблице 3.1. Единственным исключением является тип object, - метода ToObject нет по понятным причинам, поскольку для всех типов существует неявное преобразование к типу object. Среди других методов отмечу общий статический метод ChangeType, позволяющий преобразование объекта к некоторому заданному типу.
Существует возможность преобразования к системному типу DateTime, который хотя и не является встроенным типом языка C#, но допустим в программах, как и любой другой системный тип. Приведу простейший пример работы с этим типом:
// System type: DateTime System.DateTime dat = Convert.ToDateTime("15.03.2003"); Console.WriteLine("Date = {0}", dat);
Результатом вывода будет строка:
Date = 15.03.2003 0:00:00
Все методы To класса Convert перегружены и каждый из них имеет, как правило, более десятка реализаций с аргументами разного типа. Так что фактически эти методы задают все возможные преобразования между всеми встроенными типами языка C#.
Кроме методов, задающих преобразования типов, в классе Convert имеются и другие методы, например, задающие преобразования символов Unicode в однобайтную кодировку ASCII, преобразования значений объектов и другие методы. Подробности можно посмотреть в справочной системе.

Преобразования ссылочных типов

Поскольку операции над ссылочными типами не определены (исключением являются строки, но операции над ними, в том числе и присваивание, выполняются как над значимыми типами), то необходимость в них возникает только при присваиваниях и вызовах методов. Семантика таких преобразований рассмотрена в предыдущей лекции 3, где подробно обсуждалась семантика присваивания и совпадающая с ней семантика замены формальных аргументов фактическими. Там же много говорилось о преобразованиях между ссылочными и значимыми типами, выполняемых при этом операциях упаковки значений в объекты и обратной их распаковки.
Коротко повторю основные положения, связанные с преобразованиями ссылочных типов. При присваиваниях (замене аргументов) тип источника должен быть согласован с типом цели, то есть объект, связанный с источником, должен принадлежать классу, являющемуся потомком класса цели. В случае согласования типов, ссылочная переменная цели связывается с объектом источника и ее тип динамически изменяется, становясь типом источника. Это преобразование выполняется автоматически и неявно, не требуя от программиста никаких дополнительных указаний. Если же тип цели является потомком типа источника, то неявное преобразование отсутствует, даже если объект, связанный с источником, принадлежит типу цели. Явное преобразование, заданное программистом, позволяет справиться с этим случаем. Ответственность за корректность явных преобразований лежит на программисте, так что может возникнуть ошибка на этапе выполнения, если связываемый объект реально не является объектом класса цели. За примерами следует обратиться к лекции 3, еще раз обратив внимание на присваивания объектов классов Parent и Child.

Преобразования строкового типа

Важным классом преобразований являются преобразования в строковый тип и наоборот. Преобразования в строковый тип всегда определены, поскольку, напомню, все типы являются потомками базового класса Object, а, следовательно, обладают методом ToString(). Для встроенных типов определена подходящая реализация этого метода. В частности, для всех подтипов арифметического типа метод ToString() возвращает в подходящей форме строку, задающую соответствующее значение арифметического типа. Заметьте, метод ToString можно вызывать явно, но, если явный вызов не указан, то он будет вызываться неявно, всякий раз, когда по контексту требуется преобразование к строковому типу. Вот соответствующий пример:
///

/// Демонстрация преобразования в строку данных различного типа. ///

public void ToStringTest() { s ="Владимир Петров "; s1 =" Возраст: "; ux = 27; s = s + s1 + ux.ToString(); s1 =" Зарплата: "; dy = 2700.50; s = s + s1 + dy; WhoIsWho("s",s); }

Рис. 4.3.  Вывод на печать результатов теста ToStringTest
Здесь для переменной ux метод был вызван явно, а для переменной dy он вызывается автоматически. Результат работы этой процедуры показан на рис. 4.3.
Преобразования из строкового типа в другие типы, например, в арифметический, должны выполняться явно. Но явных преобразований между арифметикой и строками не существуют. Необходимы другие механизмы, и они в C# имеются. Для этой цели можно использовать соответствующие методы класса Convert библиотеки FCL, встроенного в пространство имен System. Приведу соответствующий пример:
///

/// Демонстрация преобразования строки в данные различного типа. ///

public void FromStringTest() { s ="Введите возраст "; Console.WriteLine(s); s1 = Console.ReadLine(); ux = Convert.ToUInt32(s1); WhoIsWho("Возраст: ",ux); s ="Введите зарплату "; Console.WriteLine(s); s1 = Console.ReadLine(); dy = Convert.ToDouble(s1); WhoIsWho("Зарплата: ",dy); }
Этот пример демонстрирует ввод с консоли данных разных типов. Данные, читаемые с консоли методом ReadLine или Read, всегда представляют собой строку, которую затем необходимо преобразовать в нужный тип. Тут-то и вызываются соответствующие методы класса Convert. Естественно, для успеха преобразования строка должна содержать значение в формате, допускающем подобное преобразование. Заметьте, например, что при записи значения числа для выделения дробной части должна использоваться запятая, а не точка; в противном случае возникнет ошибка периода выполнения.
На рис. 4.4 показаны результаты вывода и ввода данных с консоли при работе этой процедуры.

Рис. 4.4.  Вывод на печать результатов теста FromStringTest

Преобразования типов в выражениях

Продолжая тему преобразований типов, рассмотрим привычные для программистов преобразования между значимыми типами и, прежде всего, преобразования внутри арифметического типа.
В C# такие преобразования делятся на неявные и явные. К неявным относятся те преобразования, результат выполнения которых всегда успешен и не приводит к потере точности данных. Неявные преобразования выполняются автоматически. Для арифметических данных это означает, что в неявных преобразованиях диапазон типа назначения содержит в себе диапазон исходного типа. Например, преобразование из типа byte в тип int относится к неявным, поскольку диапазон типа byte является подмножеством диапазона int. Это преобразование всегда успешно и не может приводить к потере точности. Заметьте, преобразования из целочисленных типов к типам с плавающей точкой относятся к неявным. Хотя здесь и может происходить некоторое искажение значения, но точность представления значения сохраняется, например, при преобразовании из long в double порядок значения остается неизменным.
К явным относятся разрешенные преобразования, успех выполнения которых не гарантируется или может приводить к потере точности. Такие потенциально опасные преобразования должны быть явно заданы программистом. Преобразование из типа int в тип byte относится к явным, поскольку оно небезопасно и может приводить к потере значащих цифр. Заметьте, не для всех типов существуют явные преобразования. В этом случае требуются другие механизмы преобразования типов, которые будут рассмотрены позже.

Все эти методы устроены достаточно

Все эти методы устроены достаточно просто. Они сообщают информацию о типе и значении переданных аргументов. Вот тестирующая процедура, вызывающая метод OLoad с разным числом и типами аргументов:

///

/// Вызов перегруженного метода OLoad. В зависимости от /// типа и числа аргументов вызывается один из методов группы. ///

public void OLoadTest() { OLoad(x); OLoad(ux); OLoad(y); OLoad(dy); // OLoad(x,ux); // conflict: (int, float) и (long,long) OLoad(x,(float)ux); OLoad(y,dy); OLoad(x,dy); }

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

Рис. 4.2.  Вывод на печать результатов теста OLoadTest

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

Приведу все-таки некоторые комментарии. При первом вызове метода тип источника - int, а тип аргумента у четырех возможных реализаций соответственно float, long, ulong, double. Явного соответствия нет, поэтому нужно искать самый короткий путь на схеме. Так как не существует неявного преобразования из типа int в тип ulong (на диаграмме нет пути), то остаются возможными три реализации. Но путь из int в long короче, чем остальные пути, поэтому будет выбрана long-реализация метода.

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

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

Преобразования внутри арифметического типа

Арифметический тип, как показано в таблице 3.1, распадается на 11 подтипов. На рис. 4.1 показана схема преобразований внутри арифметического типа.

Рис. 4.1.  Иерархия преобразований внутри арифметического типа
Диаграмма, приведенная на рисунке, позволяет ответить на ряд важных вопросов, связанных с существованием преобразований между типами. Если на диаграмме задан путь (стрелками) от типа А к типу В, то это означает существование неявного преобразования из типа А в тип В. Все остальные преобразования между подтипами арифметического типа существуют, но являются явными. Заметьте, что циклов на диаграмме нет, все стрелки односторонние, так что преобразование, обратное к неявному, всегда должно быть задано явным образом.
Путь, указанный на диаграмме, может быть достаточно длинным, но это вовсе не означает, что выполняется вся последовательность преобразований на данном пути. Наличие пути говорит лишь о существовании неявного преобразования, а само преобразование выполняется только один раз, - из типа источника А в тип назначения В.
Иногда возникает ситуация, при которой для одного типа источника может одновременно существовать несколько типов назначений и необходимо осуществить выбор цели - типа назначения. Такие проблемы выбора возникают, например, при работе с перегруженными методами в классах.

Понятие перегрузки методов и операций подробно будет рассмотрено в последующих лекциях (см. лекцию 8).

Диаграмма, приведенная на рис. 4.1, и в этом случае помогает понять, как делается выбор. Пусть существует две или более реализации перегруженного метода, отличающиеся типом формального аргумента. Тогда при вызове этого метода с аргументом типа T может возникнуть проблема, какую реализацию выбрать, поскольку для нескольких реализаций может быть допустимым преобразование аргумента типа T в тип, заданный формальным аргументом данной реализации метода. Правило выбора реализации при вызове метода таково: выбирается та реализация, для которой путь преобразований, заданный на диаграмме, короче. Если есть точное соответствие параметров по типу (путь длины 0), то, естественно, именно эта реализация и будет выбрана.
Давайте рассмотрим еще один тестовый пример. В класс Testing включена группа перегруженных методов OLoad с одним и двумя аргументами. Вот эти методы:
///

/// Группа перегруженных методов OLoad /// с одним или двумя аргументами арифметического типа. /// Если фактический аргумент один, то будет вызван один из /// методов, наиболее близко подходящий по типу аргумента. /// При вызове метода с двумя аргументами возможен /// конфликт выбора подходящего метода, приводящий /// к ошибке периода компиляции. ///

void OLoad(float par) { Console.WriteLine("float value {0}", par); } ///

/// Перегруженный метод OLoad с одним параметром типа long ///

/// void OLoad(long par) { Console.WriteLine("long value {0}", par); } ///

/// Перегруженный метод OLoad с одним параметром типа ulong ///

/// void OLoad(ulong par) { Console.WriteLine("ulong value {0}", par); } ///

/// Перегруженный метод OLoad с одним параметром типа double ///

/// void OLoad(double par) { Console.WriteLine("double value {0}", par); } ///

/// Перегруженный метод OLoad с двумя параметрами типа long и long ///

/// /// void OLoad(long par1, long par2) { Console.WriteLine("long par1 {0}, long par2 {1}", par1, par2); } ///

/// Перегруженный метод OLoad с двумя параметрами типа /// double и double ///

/// /// void OLoad(double par1, double par2) { Console.WriteLine("double par1 {0}, double par2 {1}",par1, par2); } ///

/// Перегруженный метод OLoad с двумя параметрами типа /// int и float ///

/// /// void OLoad(int par1, float par2) { Console.WriteLine("int par1 {0}, float par2 {1}",par1, par2); }

Атрибуты"

Как уже говорилось, регулярные выражения особенно хороши при разборе сложных текстов. Примерами таковых могут быть различные справочники, различные текстовые базы данных, весьма популярные теперь XML-документы, разбором которых приходится заниматься. В качестве заключительного примера рассмотрим структурированный документ, строки которого содержат некоторые атрибуты, например, телефон, адрес и e-mail. Структуру документа можно задавать по-разному; будем предполагать, что каждый атрибут задается парой "имя: Значение" Наша задача состоит в том, чтобы выделить из строки соответствующие атрибуты. В таких ситуациях регулярное выражение удобно задавать в виде групп, где каждая группа соответствует одному атрибуту. Приведу начальный фрагмент кода очередной тестирующей процедуры, в котором описываются строки текста и образцы поиска:
public void TestAttributes() { string s1 = "tel: (831-2) 94-20-55 "; string s2 = "Адрес: 117926, Москва, 5-й Донской проезд, стр.10,кв.7"; string s3 = "e-mail: Valentin.Berestov@tverorg.ru "; string s4 = s1+ s2 + s3; string s5 = s2 + s1 + s3; string pat1 = @"tel:\s(?\((\d|-)*\)\s(\d|-)+)\s"; string pat2= @"Адрес:\s(?[0-9А-Яа-я \-\,\.]+)\s"; string pat3 =@"e-mail:\s(?[a-zA-Z.@]+)\s"; string compat = pat1+pat2+pat3; string tel="", addr = "", em = "";
Строки s4 и s5 представляют строку разбираемого документа. Их две, для того чтобы можно было проводить эксперименты, когда атрибуты в документе представлены в произвольном порядке. Каждая из строк pat1, pat2, pat3 задает одну именованную группу в регулярном выражении, имена групп - tel, Адрес, e-mail - даются в соответствии со смыслом атрибутов. Сами шаблоны подробно описывать не буду - сделаю лишь одно замечание. Например, шаблон телефона исходит из того, что номеру предшествует код, заключенный в круглые скобки. Поскольку сами скобки играют особую роль, то для задания скобки как символа используется пара - "\(". Это же касается и многих других символов, используемых в шаблонах, - точки, дефиса и т.п. Строка compat представляет составное регулярное выражение, содержащее все три группы. Строки tel, addr и em нам понадобятся для размещения в них результатов разбора. Применим вначале к строкам s4 и s5 каждый из шаблонов pat1, pat2, pat3 в отдельности и выделим соответствующий атрибут из строки. Вот код, выполняющий эти операции:
Regex reg1 = new Regex(pat1); Match match1= reg1.Match(s4); Console.WriteLine("Value =" + match1.Value); tel= match1.Groups["tel"].Value; Console.WriteLine(tel); Regex reg2 = new Regex(pat2); Match match2= reg2.Match(s5); Console.WriteLine("Value =" + match2.Value); addr= match2.Groups["addr"].Value; Console.WriteLine(addr); Regex reg3 = new Regex(pat3); Match match3= reg3.Match(s5); Console.WriteLine("Value =" + match3.Value); em= match3.Groups["em"].Value; Console.WriteLine(em);



Все выполняется нужным образом - создаются именованные группы, к ним можно получить доступ и извлечь найденный значения атрибутов. А теперь попробуем решить ту же задачу одним махом, используя составной шаблон compat:
Regex comreg = new Regex(compat); Match commatch= comreg.Match(s4); tel= commatch.Groups["tel"].Value; Console.WriteLine(tel); addr= commatch.Groups["addr"].Value; Console.WriteLine(addr); em= commatch.Groups["em"].Value; Console.WriteLine(em); }// TestAttributes
И эта задача успешно решается. Взгляните на результаты разбора текста.

Рис. 15.7.  Регулярные выражения. Пример "Атрибуты"
На этом и завершим рассмотрение регулярных выражений а также лекции, посвященные работе с текстами в C#.

чет и нечет"

Не всякий класс языков можно описать с помощью регулярных выражений. И даже тогда, когда такая возможность есть, могут потребоваться определенные усилия для корректной записи соответствующего регулярного выражения. Рассмотрим, например, язык L1 в алфавите T={0,1}, которому принадлежат пустое слово и слова, содержащие четное число нулей и четное число единиц. В качестве другого примера рассмотрим язык L2, отличающийся от первого тем, что в нем число единиц нечетно. Оба языка можно задать регулярными выражениями, но корректная запись непроста и требует определенного навыка. Давайте запишем регулярные выражения, определяющие эти языки, и покажем, что C# справляется с проблемой их распознавания. Вот регулярное выражение, описывающее первый язык:
(00|11)*((01|10)(00|11)*(01|10)(00|11)*)*
Дадим содержательное описание этого языка. Слова языка представляют возможно пустую последовательность из пар одинаковых символов. Далее может идти последовательность, начинающаяся и заканчивающаяся парами различающихся символов, между которыми может стоять произвольное число пар одинаковых символов. Такая группа может повторяться многократно. Регулярное выражение короче и точнее передает описываемую структуру слов языка L1.
Язык L2 описать теперь совсем просто. Его слова представляют собой единицу, окаймленную словами языка L1.
Прежде чем перейти к примеру распознавания слов языков L1 и L2, приведу процедуру FindMatches, позволяющую найти все вхождения образца в заданный текст:
void FindMatches(string str, string strpat) { Regex pat = new Regex(strpat); MatchCollection matchcol =pat.Matches(str); Console.WriteLine("Строка ={0}\tОбразец={1}",str,strpat); Console.WriteLine("Число совпадений ={0}",matchcol.Count); foreach(Match match in matchcol) Console.WriteLine("Index = {0} Value = {1}, Length ={2}", match.Index,match.Value, match.Length); }//FindMatches
Входные аргументы у процедуры те же, что и у функции FindMatch, ищущей первое вхождение. Я не стал задавать выходных аргументов процедуры, ограничившись тем, что все результаты непосредственно выводятся на печать в самой процедуре. Выполнение процедуры, так же, как и в FindMatch, начинается с создания объекта pat класса Regex, конструктору которого передается регулярное выражение. Замечу, что класс Regex, так же, как и класс String, относится к неизменяемым (immutable) классам, поэтому для каждого нового образца нужно создавать новый объект pat.
В отличие от FindMatch, объект pat вызывает метод Matches, который определяет все вхождения подстрок, удовлетворяющих образцу, в заданный текст. Результатом выполнения метода Matches является автоматически создаваемый объект класса MatchCollection, хранящий коллекцию объектов уже известного нам класса Match, каждый из которых задает очередное вхождение. В процедуре используются свойства коллекции и ее элементов для получения в цикле по элементам коллекции нужных свойств - индекса очередного вхождения подстроки в строку, ее длины и значения.
Вот процедура, в которой многократно вызывается FindMatches для различных строк и образцов поиска:
public void TestMultiPat() { //поиск по образцу всех вхождений string str,strpat,found; Console.WriteLine("Распознавание языков: чет и нечет"); //четное число нулей и единиц strpat ="((00|11)*((01|10)(00|11)*(01|10)(00|11)*)*)"; str = "0110111101101"; FindMatches(str, strpat); //четное число нулей и нечетное единиц string strodd = strpat + "1" + strpat; FindMatches(str, strodd); }//TestMultiPat



Коротко прокомментирую работу этой процедуры. Первые два примера связаны с распознаванием языков L1 и L2 (чет и нечет) - языков с четным числом единиц и нулей в первом случае и нечетным числом единиц во втором. Регулярные выражения, описывающие эти языки, подробно рассматривались. В полном соответствии с теорией, константы задают эти выражения. На вход для распознавания подается строка из нулей и единиц. Для языка L1 метод находит три соответствия. Первое из них задает максимально длинную подстроку, содержащую четное число нулей и единиц, и две пустые подстроки, по определению принадлежащие языку L1. Для языка L2 находится одно соответствие - это сама входная строка. Взгляните на результаты распознавания.

Рис. 15.2.  Регулярные выражения. Пример "чет и нечет"

Дом Джека"

Давайте вернемся к задаче разбора предложения на элементы. В классе string для этого имеется метод Split, который и решает поставленную задачу. Однако у этого метода есть существенный недостаток, - он не справляется с идущими подряд разделителями и создает для таких пар пустые слова. Метод Split класса Regex лишен этих недостатков, в качестве разделителей можно задавать любую пару символов, произвольное число пробелов и другие комбинации символов. Повторим наш прежний пример:
public void TestParsing() { string str,strpat; //разбор предложения - создание массива слов str = "А это пшеница, которая в темном чулане хранится," +" в доме, который построил Джек!"; strpat =" +|, "; Regex pat = new Regex(strpat); string[] words; words = pat.Split(str); int i=1; foreach(string word in words) Console.WriteLine("{0}: {1}",i++,word); }//TestParsing
Регулярное выражение, заданное строкой strpat, определяет множество разделителей. Заметьте, в качестве разделителя задан пробел, повторенный сколь угодно много раз, либо пара символов - запятая и пробел. Разделители задаются регулярными выражениями. Метод Split применяется к объекту pat класса Regex. В качестве аргумента методу передается текст, подлежащий расщеплению. Вот как выглядит массив слов после применения метода Split.

Рис. 15.6.  Регулярные выражения. Пример "Дом Джека"

две версии класса Account

Проиллюстрируем рассмотренные выше вопросы на примере проектирования классов Account и Account1, описывающих такую абстракцию данных, как банковский счет. Определим на этих данных две основные операции - занесение денег на счет и снятие денег. В первом варианте - классе Account - будем активно использовать поля класса. Помимо двух основных полей credit и debit, хранящих приход и расход счета, введем поле balance, которое задает текущее состояние счета, и два поля, связанных с последней выполняемой операцией. Поле sum будет хранить сумму денег текущей операции, а поле result - результат выполнения операции. Полей у класса много, и как следствие, у методов класса аргументов будет немного. Вот описание нашего класса:
///

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

public class Account { //закрытые поля класса int debit=0, credit=0, balance =0; int sum =0, result=0; ///

/// Зачисление на счет с проверкой ///

/// зачисляемая сумма public void putMoney(int sum) { this.sum = sum; if (sum >0) { credit += sum; balance = credit - debit; result =1; } else result = -1; Mes(); }//putMoney ///

/// Снятие со счета с проверкой ///

/// снимаемая сумма public void getMoney(int sum) { this.sum = sum; if(sum <= balance) { debit += sum; balance = credit - debit; result =2; } else result = -2; Mes(); }//getMoney ///

/// Уведомление о выполнении операции ///

void Mes() { switch (result) { case 1: Console.WriteLine("Операция зачисления денег прошла успешно!"); Console.WriteLine("Cумма={0}, Ваш текущий баланс={1}",sum, balance); break; case 2: Console.WriteLine("Операция снятия денег прошла успешно!"); Console.WriteLine("Cумма={0}, Ваш текущий баланс={1}", sum,balance); break; case -1: Console.WriteLine("Операция зачисления денег не выполнена!"); Console.WriteLine("Сумма должна быть больше нуля!"); Console.WriteLine("Cумма={0}, Ваш текущий баланс={1}", sum,balance); break; case -2: Console.WriteLine("Операция снятия денег не выполнена!"); Console.WriteLine("Сумма должна быть не больше баланса!"); Console.WriteLine("Cумма={0}, Ваш текущий баланс={1}", sum,balance); break; default: Console.WriteLine("Неизвестная операция!"); break; } } }//Account



Как можно видеть, только у методов getMoney и putMoney имеется один входной аргумент. Это тот аргумент, который нужен по сути дела, поскольку только клиент может решить, какую сумму он хочет снять или положить на счет. Других аргументов у методов класса нет - вся информация передается через поля класса. Уменьшение числа аргументов приводит к повышению эффективности работы с методами, так как исчезают затраты на передачу фактических аргументов. Но за все надо платить. В данном случае, усложняются сами операции работы со вкладом, поскольку нужно в момент выполнения операции обновлять значения многих полей класса. Закрытый метод Mes вызывается после выполнения каждой операции, сообщая о том, как прошла операция, и информируя клиента о текущем состоянии его баланса.
А теперь спроектируем аналогичный класс Account1, отличающийся только тем, что у него будет меньше полей. Вместо поля balance в классе появится соответствующая функция с этим же именем, вместо полей sum и result появятся аргументы у методов, обеспечивающие необходимую передачу информации. Вот как выглядит этот класс:
///

/// Класс Account1 определяет банковский счет. /// Вариант с аргументами и функциями ///

public class Account1 { //закрытые поля класса int debit=0, credit=0; ///

/// Зачисление на счет с проверкой ///

/// зачисляемая сумма public void putMoney(int sum) { int res =1; if (sum >0)credit += sum; else res = -1; Mes(res,sum); }//putMoney ///

/// Снятие со счета с проверкой ///

/// снимаемая сумма public void getMoney(int sum) { int res=2; if(sum <= balance())debit += sum; else res = -2; balance(); Mes(res, sum); }//getMoney ///

/// вычисление баланса ///

/// текущий баланс int balance() { return(credit - debit); } ///

/// Уведомление о выполнении операции ///

void Mes(int result, int sum) { switch (result) { case 1: Console.WriteLine("Операция зачисления денег прошла успешно!"); Console.WriteLine("Cумма={0}, Ваш текущий баланс={1}", sum,balance()); break; case 2: Console.WriteLine("Операция снятия денег прошла успешно!"); Console.WriteLine("Cумма={0}, Ваш текущий баланс={1}", sum,balance()); break; case -1: Console.WriteLine("Операция зачисления денег не выполнена!"); Console.WriteLine("Сумма должна быть больше нуля!"); Console.WriteLine("Cумма={0}, Ваш текущий баланс={1}", sum,balance()); break; case -2: Console.WriteLine("Операция снятия денег не выполнена!"); Console.WriteLine("Сумма должна быть не больше баланса!"); Console.WriteLine("Cумма={0}, Ваш текущий баланс={1}", sum,balance()); break; default: Console.WriteLine("Неизвестная операция!"); break; } } }//Account1


Сравнивая этот класс с классом Account, можно видеть, что число полей сократилось с пяти до двух, упростились основные методы getMoney и putMoney. Но, в качестве платы, у класса появился дополнительный метод balance(), многократно вызываемый, и у метода Mes теперь появились два аргумента. Какой класс лучше? Однозначно сказать нельзя, все зависит от контекста, от приоритетов, заданных при создании конкретной системы.
Приведу процедуру класса Testing, тестирующую работу с классами Account и Account1:
public void TestAccounts() { Account myAccount = new Account(); myAccount.putMoney(6000); myAccount.getMoney(2500); myAccount.putMoney(1000); myAccount.getMoney(4000); myAccount.getMoney(1000); //Аналогичная работа с классом Account1 Console.WriteLine("Новый класс и новый счет!"); Account1 myAccount1 = new Account1(); myAccount1.putMoney(6000); myAccount1.getMoney(2500); myAccount1.putMoney(1000); myAccount1.getMoney(4000); myAccount1.getMoney(1000); }
На рис. 9.1 показаны результаты работы этой процедуры.

Рис. 9.1.  Тестирование классов Account и Account1

кок и кук"

Этот пример на поиск множественных соответствий навеян словами песни Высоцкого, где говорится, что дикари не смогли распознать, где кок, а где Кук. Наше регулярное выражение также не распознает эти слова. Обратите внимание на точку в регулярном выражении, которая соответствует любому символу, за исключением символа конца строки. Все слова в строке поиска - кок, кук, кот и другие - будут удовлетворять шаблону, так что в результате поиска найдется множество соответствий.
Console.WriteLine("кок и кук"); strpat="(т|к).(т|к)"; str="кок тот кук тут как кот"; FindMatches(str, strpat);
Вот результаты работы этого фрагмента кода.

Рис. 15.4.  Регулярные выражения. Пример "кок и кук"

Комбинирование делегатов"

Рассмотрим следующую ситуацию. Пусть есть городские службы: милиция, скорая помощь, пожарные. Каждая из служб по-своему реагируют на события, происходящие в городе. Построим примитивную модель жизни города, в которой случаются события и сообщения о них посылаются службам. В последующей лекции эта модель будет развита. Сейчас она носит формальный характер, демонстрируя, главным образом, работу с делегатами, заодно поясняя ситуации, в которых разумно комбинирование делегатов.
Начнем с построения класса с именем Combination, где, следуя уже описанной технологии, введем делегатов как закрытые свойства, доступ к которым идет через процедуру-свойство get. Три делегата одного класса будут описывать действия трех городских служб. Класс будет описываться ранее введенным делегатом MesToPers, размещенным в пространстве имен проекта. Вот программный код, в котором описаны функции, задающие действия служб:
class Combination { private static void policeman(string mes) { //анализ сообщения if(mes =="Пожар!") Console.WriteLine(mes + " Милиция ищет виновных!"); else Console.WriteLine(mes +" Милиция здесь!"); } private static void ambulanceman(string mes) { if(mes =="Пожар!") Console.WriteLine(mes + " Скорая спасает пострадавших!"); else Console.WriteLine(mes + " Скорая помощь здесь!"); } private static void fireman(string mes) { if(mes =="Пожар!") Console.WriteLine(mes + " Пожарные тушат пожар!"); else Console.WriteLine( mes + " Пожарные здесь!"); } }
Как видите, все три функции имеют не только одинаковую сигнатуру, но и устроены одинаково. Они анализируют приходящее к ним сообщение, переданное через параметр mes, а затем, в зависимости от результата, выполняют ту или иную работу, которая в данном случае сводится к выдаче соответствующего сообщения. Сами функции закрыты, и мы сейчас организуем к ним доступ:
public static MesToPers Policeman { get {return (new MesToPers(policeman));} } public static MesToPers Fireman { get {return (new MesToPers(fireman));} } public static MesToPers Ambulanceman { get {return (new MesToPers(ambulanceman));} }



Три статических открытых свойства - Policeman, Fireman, Ambulanceman - динамически создают экземпляры класса MesToPers, связанные с соответствующими закрытыми функциями класса.
Службы у нас есть, покажем, как с ними можно работать. С этой целью добавим в класс Testing, где проводятся различные эксперименты, следующую процедуру:
public void TestSomeServices() { MesToPers Comb; Comb = (MesToPers)Delegate.Combine(Combination.Ambulanceman, Combination.Policeman); Comb = (MesToPers)Delegate.Combine(Comb,Combination.Fireman); Comb("Пожар!");
Вначале объявляется без инициализации функциональная переменная Comb, которой в следующем операторе присваивается ссылка на экземпляр делегата, созданного методом Combine, чей список вызова содержит ссылки на экземпляры делегатов Ambulanceman и Policeman. Затем к списку вызовов экземпляра Comb присоединяется новый кандидат Fireman. При вызове делегата Comb ему передается сообщение "Пожар!". В результате вызова Comb поочередно запускаются все три экземпляра входящие в список, каждому из которых передается сообщение.
Давайте теперь начнем поочередно отключать делегатов, вызывая затем Comb с новыми сообщениями:
Comb = (MesToPers)Delegate.Remove(Comb,Combination.Policeman); //Такое возможно: попытка отключить не существующий элемент Comb = (MesToPers)Delegate.Remove(Comb,Combination.Policeman); Comb("Через 30 минут!"); Comb = (MesToPers)Delegate.Remove(Comb,Combination.Ambulanceman); Comb("Через час!"); Comb = (MesToPers)Delegate.Remove(Comb,Combination.Fireman); //Comb("Через два часа!"); // Comb не определен
В этом фрагменте поочередно отключаются разные службы - милиция, скорая помощь, пожарные, и каждый раз вызывается Comb. После последнего отключения, когда список вызовов становится пустым, вызов Comb приводит к ошибке, потому оператор вызова закомментирован.
Покажем теперь, что ту же работу можно выполнить, используя не методы, а операции:
//операции + и - Comb = Combination.Ambulanceman; Console.WriteLine( Comb.Method.Name); Comb+= Combination.Fireman; Comb+= Combination.Policeman; Comb("День города!"); Comb -= Combination.Ambulanceman; Comb -= Combination.Fireman; Comb("На следующий день!"); }//TestSomeServices
Обратите внимание, здесь демонстрируется вызов свойства Method, возвращающее объект, свойство Name которого выводится на печать. Результаты, порожденные работой этой процедуры, изображены на рис. 20.6.

Рис. 20.6.  Службы города

обратные ссылки"

В этом примере рассматривается ранее упоминавшаяся, но не описанная возможность задания в регулярном выражении обратных ссылок. Можно ли описать с помощью регулярных выражений язык, в котором встречаются две подряд идущие одинаковые подстроки? Ответ на это вопрос отрицательный, поскольку грамматика такого языка должна быть контекстно-зависимой, и нужна память, чтобы хранить уже распознанные части строки. Аппарат регулярных выражений, предоставляемый классами пространства RegularExpression, тем не менее, позволяет решить эту задачу. Причина в том, что расширение стандартных регулярных выражений в Net Framework является не только синтаксическим. Содержательные расширения связаны с введением понятия группы, которой отводится память и дается имя. Это и дает возможность ссылаться на уже созданные группы, что и делает грамматику языка контекстно-зависимой. Ссылка на ранее полученную группу называется обратной ссылкой. Признаком обратной ссылки является пара символов "\k", после которой идет имя группы. Приведу пример:
Console.WriteLine("Ссылка назад - второе вхождение слова"); strpat = @"\s(?\w+)\s\k'word'"; str = "I know know that, You know that!"; FindMatches(str, strpat);
Рассмотрим более подробно регулярное выражение, заданное строкой strpat. В группе, заданной скобочным выражением, после знака вопроса идет имя группы "word", взятое в угловые скобки. После имени группы идет шаблон, описывающий данную группу, в нашем примере шаблон задается произвольным идентификатором "\w+". В дальнейшем описании шаблона задается ссылка на группу с именем "word". Здесь имя группы заключено в одинарные кавычки. Поиск успешно справился с поставленной задачей, подтверждением чему являются результаты работы этого фрагмента кода.

Рис. 15.5.  Регулярные выражения. Пример "обратные ссылки"

око и рококо"

Следующий образец в нашем примере позволяет прояснить некоторые особенности работы метода Matches. Сколько раз строка "око" входит в строку "рококо" - один или два? Все зависит от того, как считать. С точки зрения метода Matches, - один раз, поскольку он разыскивает непересекающиеся вхождения, начиная очередной поиск вхождения подстроки с того места, где закончилось предыдущее вхождение. Еще один пример на эту же тему работает с числовыми строками.
Console.WriteLine("око и рококо"); strpat="око"; str = "рококо"; FindMatches(str, strpat); strpat="123"; str= "0123451236123781239"; FindMatches(str, strpat);
На рис. 15.3 показаны результаты поисков.

Рис. 15.3.  Регулярные выражения. Пример "око и рококо"

Плохая служба"

Как быть, если в списке вызовов есть "плохой" экземпляр, при вызове которого возникает ошибка, приводящая к выбрасыванию исключительной ситуации? Тогда стоящие за ним в очереди экземпляры не будут вызваны, хотя они вполне могли бы выполнить свою часть работы. В этом случае полезно использовать метод GetInvocationList и в цикле поочередно вызывать делегатов. Вызов делегата следует поместить в охраняемый блок, тогда при возникновении исключительной ситуации в обработчике ситуации можно получить и выдать пользователю всю информацию о нарушителе, а цикл продолжит выполнение очередных делегатов из списка вызова.
Добавим в класс Combination "плохого" кандидата, который пытается делить на ноль:
//метод, вызывающий исключительную ситуацию public static void BadService(string mes) { int i =7, j=5, k=0; Console.WriteLine("Bad Service: Zero Divide"); j=i/k; }
Создадим процедуру, в которой в списке вызовов есть хорошие и плохие кандидаты. Эта процедура использует управление исключительными ситуациями, о которых подробнее будет рассказано в последующих лекциях.
public void TestBadJob() { MesToPers Comb; Comb = (MesToPers)Delegate.Combine(Combination.Ambulanceman, Combination.Policeman); Comb = (MesToPers)Delegate.Combine(Comb, new MesToPers(Combination.BadService)); Comb = (MesToPers)Delegate.Combine(Comb,Combination.Fireman); foreach(MesToPers currentJob in Comb.GetInvocationList()) { try { currentJob("Пожар!"); } catch(Exception e) { Console.WriteLine(e.Message); Console.WriteLine(currentJob.Method.Name); } } }//BadJob
Поясню, как будет работать эта процедура при ее вызове. Вначале две службы нормально отработают, но при вызове третьей службы возникнет исключительная ситуация "деление на ноль". Универсальный обработчик Exception перехватит эту ситуацию и напечатает как свойство Message объекта e, так и имя метода, вызвавшего исключительную ситуацию, используя свойство Method объекта, вызвавшего ситуацию. После завершения работы блока обработчика ситуации выполнение программы продолжится, выполнится следующий шаг цикла, и служба пожарных благополучно выполнит свою работу. Вот результаты вывода:

Рис. 20.7.  "Плохая служба"
Разговор о делегатах еще не закончен. Он будет продолжен в следующей лекции, в которой рассмотрим классы с событиями. События основываются на делегатах.

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

Классы семейства с полиморфными методами уже созданы. Давайте теперь в клиентском классе 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.  Полиморфизм семейства классов
В последующих лекциях нам неоднократно встретятся более содержательные семейства классов с полиморфизмом, так что мы сумеем еще оценить мощь этого механизма ООП.

Списки с событиями"

В этом примере строится класс ListWithChangedEvent, являющийся потомком встроенного класса ArrayList, который позволяет работать со списками. В класс добавляется событие Changed, сигнализирующее обо всех изменениях элементов списка. Строятся два класса - Receiver1 и Receiver2, получающие сообщения. В примере рассматривается взаимодействие нескольких объектов: два объекта посылают сообщения, три - принимают.
Начнем с объявления делегата:
// Объявление делегата public delegate void ChangedEventHandler(object sender, ChangedEventArgs args);
Здесь объявлен делегат ChangedEventHandler, по всем правилам хорошего стиля - его имя и его форма соответствует всем требованиям. Второй аргумент, задающий аргументы события, принадлежит классу ChangedEventArgs, производному от встроенного класса EventArgs. Рассмотрим, как устроен этот производный класс:
public class ChangedEventArgs:EventArgs { private object item; private bool permit; public object Item { get {return(item);} set { item = value;} } public bool Permit { get {return(permit);} set { permit = value;} } }//class ChangedEventArgs
У класса два закрытых свойства, доступ к которым осуществляется через процедуры-свойства get и set. Конечно, можно было бы в данной ситуации сделать их просто public - общедоступными. Свойство Item задает входной аргумент события, передаваемый обработчику события. Булево свойство Permit задает выходной аргумент события, получающий в обработчике значение True, если обработчик события дает добро на изменение элемента.
В модели, которую мы рассматриваем, предполагается, что обработчик события, получив уведомление об изменении элемента, анализирует ситуацию и может разрешить или не разрешить изменение, например, если значение элемента больше некоторого предельного значения.

Правильно ли, что обработчик события, а не сам класс, создающий событие, принимает решение о допуске изменения элемента списка? Все зависит от контекста. В прошлые времена молодые могли объявить о своей помолвке, но требовалось разрешение родителей на брак. Времена изменились - теперь на брак родительского благословения не требуется. Но в программистском мире ситуации, требующие внешнего разрешения, встречаются довольно часто.

Примеры преобразований

Перейдем к примерам. Класс Testing, содержащий примеры, представляет собой набор данных разного типа, над которыми выполняются операции, иллюстрирующие преобразования типов. Вот описание класса Testing:
using System; namespace Types { ///

/// Класс Testing включает данные разных типов. Каждый его /// открытый метод описывает некоторый пример, /// демонстрирующий работу с типами. /// Открытые методы могут вызывать закрытые методы класса. ///

public class Testing { ///

/// набор скалярных данных разного типа. ///

byte b = 255; int x = 11; uint ux = 1111; float y = 5.5f; double dy = 5.55; string s = "Hello!"; string s1 = "25"; object obj = new Object(); // Далее идут методы класса, приводимые по ходу // описания примеров }
В набор данных класса входят скалярные данные арифметического типа, относящиеся к значимым типам, переменные строкового типа и типа object, принадлежащие ссылочным типам. Рассмотрим закрытый (private) метод этого класса - процедуру WhoIsWho с формальным аргументом класса Object. Процедура выводит на консоль переданное ей имя аргумента, его тип и значение. Вот ее текст:
///

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

/// - Имя второго аргумента /// - Допустим аргумент любого типа void WhoIsWho(string name, object any) { Console.WriteLine("type {0} is {1} , value is {2}", name, any.GetType(), any.ToString()); }
Вот открытый (public) метод класса Testing, в котором многократно вызывается метод WhoIsWho с аргументами разного типа:
///

/// получаем информацию о типе и значении /// переданного аргумента - переменной или выражения ///

public void WhoTest() { WhoIsWho("x",x); WhoIsWho("ux",ux); WhoIsWho("y",y); WhoIsWho("dy",dy); WhoIsWho("s",s); WhoIsWho("11 + 5.55 + 5.5f",11 + 5.55 + 5.5f); obj = 11 + 5.55 + 5.5f; WhoIsWho("obj",obj); }



Заметьте, сущность any - формальный аргумент класса Object при каждом вызове - динамически изменяет тип, связываясь с объектом, заданным фактическим аргументом. Поэтому тип аргумента, выдаваемый на консоль, - это тип фактического аргумента. Заметьте также, что наследуемый от класса Object метод GetType возвращает тип FCL, то есть тот тип, на который отражается тип языка и с которым реально идет работа при выполнении модуля. В большинстве вызовов фактическим аргументом является переменная - соответствующее свойство класса Testing, но в одном случае передается обычное арифметическое выражение, автоматически преобразуемое в объект. Аналогичная ситуация имеет место и при выполнении присваивания в рассматриваемой процедуре.
На рис. 3.1 показаны результаты вывода на консоль, полученные при вызове метода WhoTest в приведенной выше процедуре Main класса Class1.

Рис. 3.1.  Вывод на печать результатов теста WhoTest

в лекции 14. Здесь они

Некоторые комментарии к этой процедуре.
Регулярные выражения задаются @-константами, описанными в лекции 14. Здесь они как нельзя кстати.
В первом образце используется последовательность символов \w+, обозначающая, как следует из таблицы 15.1, непустую последовательность латиницы и цифр. В совокупности образец задает подстроку, начинающуюся символом a, за которым следуют буквы или цифры (хотя бы одна). Этот образец применяется к двум различным строкам.
В следующем образце используется символ * для обозначения итерации. В целом регулярное выражение задает строки, начинающиеся с символа a и заканчивающиеся символом f, между которыми находится возможно пустая последовательность символов из b и d.
Последующие два образца демонстрируют использование диапазонов и escape-последовательностей для представления символов, заданных кодами (в Unicode и шестнадцатиричной кодировке).
Взгляните на результаты, полученные при работе этой процедуры.

Рис. 15.1.  Регулярные выражения. Поиск по образцу

Примеры работы с регулярными выражениями

Полагаю, что примеры дополнят краткое описание возможностей регулярных выражений и позволят лучше понять, как с ними работать. Начну с функции FindMatch, которая производит поиск первого вхождения подстроки, соответствующей образцу:
string FindMatch(string str, string strpat) { Regex pat = new Regex(strpat); Match match =pat.Match(str); string found = ""; if (match.Success) { found =match.Value; Console.WriteLine("Строка ={0}\tОбразец={1}\ tНайдено={2}", str,strpat,found); } return(found); }//FindMatch
В качестве входных аргументов функции передается строка str, в которой ищется вхождение, и строка strpat, задающая образец - регулярное выражение. Функция возвращает найденную в результате поиска подстроку. Если соответствия нет, то возвращается пустая строка. Функция начинает свою работу с создания объекта pat класса Regex, конструктору которого передается образец поиска. Затем вызывается метод Match этого объекта, создающий объект match класса Match. Далее анализируются свойства этого объекта. Если соответствие обнаружено, то найденная подстрока возвращается в качестве результата, а соответствующая информация выводится на печать. (Чтобы спокойно работать с классами регулярных выражений, я не забыл добавить в начало проекта предложение: using System.Text.RegularExpressions.)
Поскольку запись регулярных выражений - вещь, привычная не для всех программистов, я приведу достаточно много примеров:
public void TestSinglePat() { //поиск по образцу первого вхождения string str,strpat,found; Console.WriteLine("Поиск по образцу"); //образец задает подстроку, начинающуюся с символа a, //далее идут буквы или цифры. str ="start"; strpat =@"a\w+"; found = FindMatch(str,strpat); str ="fab77cd efg"; found = FindMatch(str,strpat); //образец задает подстроку,начинающуюся с символа a, //заканчивающуюся f с возможными символами b и d в середине strpat = "a(b|d)*f"; str = "fabadddbdf"; found = FindMatch(str,strpat); //диапазоны и escape-символы strpat = "[X-Z]+"; str = "aXYb"; found = FindMatch(str,strpat); strpat = @"\u0058Y\x5A"; str = "aXYZb"; found = FindMatch(str,strpat); }//TestSinglePat

Приоритет и порядок выполнения операций

Большинство операций в языке C#, их приоритет и порядок наследованы из языка C++. Однако имеются и различия: например, нет операции " , ", позволяющей вычислять список выражений; добавлены уже упоминавшиеся операции checked и unchecked, применимые к выражениям.
Как это обычно делается, приведем таблицу приоритетов операций, в каждой строке которой собраны операции одного приоритета, а строки следуют в порядке приоритетов, от высшего к низшему.
ПриоритетКатегорияОперацииПорядок

0	Первичные	(expr) x.y f(x) a[x] x++ x-- new sizeof(t) typeof(t) checked(expr) unchecked(expr)	Слева направо
1	Унарные	+ - ! ~ ++x --x (T)x	Слева направо
2	Мультипликативные (Умножение)	* / %	Слева направо
3	Аддитивные (Сложение)	+ -	Слева направо
4	Сдвиг	<< >>	Слева направо
5	Отношения, проверка типов	< > <= >= is as	Слева направо
6	Эквивалентность	== !=	Слева направо
7	Логическое И	&	Слева направо
8	Логическое исключающее ИЛИ (XOR)	^	Слева направо
9	Логическое ИЛИ (OR)	|	Слева направо
10	Условное И	&&	Слева направо
11	Условное ИЛИ		Слева направо
12	Условное выражение	? :	Справа налево
13	Присваивание	= *= /= %= += -= <<= >>= &= ^= |=	Справа налево

Присваивание

В большинстве языков программирования присваивание - это оператор, а не операция. В языке C# присваивание унаследовало многие особенности присваивания языка C++. В C# оно толкуется как операция, используемая в выражениях. Однако в большинстве случаев присваивание следует рассматривать и использовать как обычный оператор.
Возьмем полезный случай реального использования присваивания как операции. В ситуации, называемой множественным присваиванием, списку переменных присваивается одно и тоже значение. Вот пример:
///

/// анализ присваивания ///

public void Assign() { double x,y,z,w =1, u =7, v= 5; x = y = z = w =(u+v+w)/(u-v-w); }//Assign
По мере изложения в метод Assign будут добавляться фрагменты кода, связанные с рассматриваемой темой присваивания.
О семантике присваивания говорилось уже достаточно много. Но следует внести еще некоторые уточнения. Правильно построенное выражение присваивания состоит из левой и правой части. Левая часть - это список переменных, в котором знак равенства выступает в качестве разделителя. Правая часть - это выражение. Выражение правой части вычисляется, при необходимости приводится к типу переменных левой части, после чего все переменные левой части получают значение вычисленного выражения. Последние действия можно рассматривать как побочный эффект операции присваивания. Заметьте, все переменные в списке левой части должны иметь один тип или неявно приводиться к одному типу. Операция присваивания выполняется справа налево, поэтому вначале значение выражения получит самая правая переменная списка левой части, при этом значение самого выражения не меняется. Затем значение получает следующая справа по списку переменная - и так до тех пор, пока не будет достигнут конец списка. Так что реально можно говорить об одновременном присваивании, в котором все переменные списка получают одно и то же значение. В нашем примере, несмотря на то, что переменная w первой получит значение, а выражение в правой части зависит от w, все переменные будут иметь значение 13.0. Рассмотрим еще один фрагмент кода:
bool b; x=5; y=6; //b= x=y; //if (x=y) z=1;else z=-1;
В программе на языке C++ можно было снять комментарии с операторов, и этот фрагмент кода компилировался и выполнялся бы без ошибок. Другое дело, что результат мог быть некорректен, поскольку, вероятнее всего, операция присваивания "x=y" написана по ошибке и ее следует заменить операцией эквивалентности "x==y". В языке C# оба закомментированных оператора, к счастью, приведут к ошибке трансляции, поскольку результат присваивания имеет тип double, для которого нет неявного преобразования в тип bool. На C# такая программа будет выполняться, только если x и y будут иметь тип bool, но в этом случае, возможно, применение операции присваивания имеет смысл. С типами double корректная программа на C# может быть такой:
x =y; b= (y!=0); if(y!=0) z=1; else z = -1;
В программе появился лишний оператор, но исчезла двусмысленность, порождаемая операцией присваивания.

Проблемы множественного наследования

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

Процедуры и функции - функциональные модули

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

Процедуры и функции - методы класса

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

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

В языке C# нет специальных ключевых слов - procedure и function, но присутствуют сами эти понятия. Синтаксис объявления метода позволяет однозначно определить, чем является метод - процедурой или функцией.
Прежнюю роль библиотек процедур и функций теперь играют библиотеки классов. Библиотека классов FCL, доступная в языке C#, существенно расширяет возможности языка. Знание классов этой библиотеки и методов этих классов совершенно необходимо для практического программирования на C# с использованием всей его мощи.

Уже в лекции 1 мы говорили о роли библиотеки FCL - статическом компоненте Framework .Net. В лекции 4 рассматривались возможности класса Convert этой библиотеки, а в лекции 7 - классы Math и Random. Изучение классов FCL будет постоянно сопровождать наш курс.

Процедуры и функции. Отличия

Функция отличается от процедуры двумя особенностями:

• всегда вычисляет некоторое значение, возвращаемое в качестве результата функции;
• вызывается в выражениях.

Процедура C# имеет свои особенности:

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

Хорошо известно, что одновременное существование в языке процедур и функций в каком-то смысле избыточно. Добавив еще один выходной аргумент, любую функцию можно записать в виде процедуры. Справедливо и обратное. Если допускать функции с побочным эффектом, то любую процедуру можно записать в виде функции. В языке С - дедушке C# - так и сделали, оставив только функции. Однако значительно удобнее иметь обе формы реализации метода: и процедуры, и функции. Обычно метод предпочитают реализовать в виде функции тогда, когда он имеет один выходной аргумент, рассматриваемый как результат вычисления значения функции. Возможность вызова функций в выражениях также влияет на выбор в пользу реализации метода в виде функции. В других случаях метод реализуют в виде процедуры.

Процедуры и массивы

В наших примерах массивы неоднократно передавались процедурам в качестве входных аргументов и возвращались в качестве результатов.
В лекции 9 подробно описывались особенности передачи аргументов в процедуру. Остается подчеркнуть только некоторые детали:

• В процедуру достаточно передавать только сам объект - массив. Все его характеристики (размерность, границы) можно определить, используя свойства и методы этого объекта.
• Когда массив является выходным аргументом процедуры, как аргумент C в процедуре MultMatr, выходной аргумент совсем не обязательно снабжать ключевым словом ref или out (хотя и допустимо). Передача аргумента по значению в таких ситуациях так же хороша, как и передача по ссылке. В результате вычислений меняется сам массив в динамической памяти, а ссылка на него остается постоянной. Процедура и ее вызов без ключевых слов выглядит проще, поэтому обычно они опускаются. Заметьте, в процедуре GetSizes, где определялись границы массива, ключевое слово out, сопровождающее аргументы, совершенно необходимо.
• Может ли процедура-функция возвращать массив в качестве результата? В C# ответ на этот вопрос положителен. В следующей лекции будет приведен пример подобной функции.

Проект "Город и его службы"

Завершить лекцию о событиях хочется содержательным учебным проектом, в котором моделируется жизнь города, происходящие в нем события и реакция на них городских служб. Наша главная цель в данном проекте - еще раз показать, как возникающее событие, в данном случае - пожар в одном из домов города, обрабатывается по-разному городскими службами - пожарными, милицией, скорой помощью. Конечно, все упрощено, в реальном городе событиями являются не только пожары и преступления, но и более приятные ситуации: день города, открытие фестивалей и выставок, строительство новых театров и институтов.
Начнем с описания класса, задающего наш город. Этот класс уже появлялся и в этой, и в предыдущей лекции, здесь его описание будет расширено. Начнем со свойств класса:
public class NewTown { //свойства private int build, BuildingNumber; //дом и число домов в городе private int day, days; //Текущий день года //городские службы private Police policeman ; private Ambulance ambulanceman ; private FireDetect fireman ; //события в городе public event FireEventHandler Fire; //моделирование случайных событий private Random rnd = new Random(); //вероятность пожара в доме в текущий день: p= m/n private int m = 3, n= 10000;
В нашем городе есть дома; есть время, текущее день за днем; городские службы; событие "пожар", которое, к сожалению, может случайно с заданной вероятностью возникать каждый день в каждом доме. Рассмотрим конструктор объектов нашего класса:
//конструктор класса public NewTown(int TownSize, int Days) { BuildingNumber = rnd.Next(TownSize); days = Days; policeman = new Police(this); ambulanceman= new Ambulance(this); fireman= new FireDetect(this); policeman.On(); ambulanceman.On(); fireman.On(); }
При создании объектов этого класса задается размер города - число его домов и период времени, в течение которого будет моделироваться жизнь города. При создании объекта создаются его службы - объекты соответствующих классов Police, Ambulance, FireDetect, которым передается ссылка на сам объект "город". При создании служб вызываются методы On, подключающие обработчики события Fire каждой из этих служб к событию.
В соответствии с ранее описанной технологией определим метод OnFire, включающий событие:
protected virtual void OnFire(FireEventArgs e) { if(Fire != null) Fire(this, e); }



Где и когда будет включаться событие Fire? Напишем метод, моделирующий жизнь города, где для каждого дома каждый день будет проверяться, а не возник ли пожар, и, если это случится, то будет включено событие Fire:

public void LifeOurTown() { for(day = 1; day<=days; day++) for(build =1; build <= BuildingNumber; build++) { if( rnd.Next(n) <=m) //загорелся дом { //аргументы события FireEventArgs e = new FireEventArgs(build, day, true); OnFire(e); if(e.Permit) Console.WriteLine("Пожар потушен!" + " Ситуация нормализована."); else Console.WriteLine("Пожар продолжается." + " Требуются дополнительные средства!"); } } }

Рассмотрим теперь классы Receiver, обрабатывающие событие Fire. Их у нас три, по одному на каждую городскую службу. Все три класса устроены по одному образцу. Напомню, каждый такой разумно устроенный класс, кроме обработчика события, имеет конструктор, инициализирующий ссылку на объект, создающий события, методы подключения и отсоединения обработчика от события. В такой ситуации целесообразно построить вначале абстрактный класс Receiver, в котором будет предусмотрен обработчик события, но не задана его реализация, а затем для каждой службы построить класс-потомок. Начнем с описания родительского класса:

public abstract class Receiver { private NewTown town; public Receiver(NewTown town) {this.town = town;} public void On() { town.Fire += new FireEventHandler(It_is_Fire); } public void Off() { town.Fire -= new FireEventHandler(It_is_Fire); town = null; } public abstract void It_is_Fire(object sender, FireEventArgs e); }//class Receiver

Для классов потомков абстрактный метод It_is_Fire будет определен. Вот их описания:

public class Police : Receiver { public Police (NewTown town): base(town){} public override void It_is_Fire(object sender, FireEventArgs e) { Console.WriteLine("Пожар в доме {0}. День {1}-й." + " Милиция ищет виновных!", e.Build,e.Day); e.Permit &= true; } }// class Police public class FireDetect : Receiver { public FireDetect (NewTown town): base(town){} public override void It_is_Fire(object sender, FireEventArgs e) { Console.WriteLine("Пожар в доме {0}. День {1}-й."+ " Пожарные тушат пожар!", e.Build,e.Day); Random rnd = new Random(e.Build); if(rnd.Next(10) >5) e.Permit &= false; else e.Permit &=true; } }// class FireDetect public class Ambulance : Receiver { public Ambulance(NewTown town): base(town){} public override void It_is_Fire(object sender, FireEventArgs e) { Console.WriteLine("Пожар в доме {0}. День {1}-й."+ " Скорая спасает пострадавших!", e.Build,e.Day); e.Permit &= true; } }// class Ambulance



Для каждого потомка задан конструктор, вызывающий базовый метод родителя. Каждый потомок по-своему определяет обработчика события Fire. Обратите внимание на то, как в данном проекте решается проблема с выходным параметром события - Permit. Принята следующая стратегия: возвращаемое значение Permit будет истинно, если все обработчики согласны с этим. Поэтому каждый обработчик использует конъюнкцию выработанного им значения со значением, пришедшим от предыдущего обработчика. В данном примере все зависит от пожарных, которые могут вырабатывать разные решения.

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

public class FireEventArgs : EventArgs { private int build; private int day; private bool permit; public int Build { get{ return(build);} ///set{ build = value;} } public int Day { get{ return(day);} ///set{ day = value;} } public bool Permit { get{ return(permit);} set{ permit = value;} } public FireEventArgs(int build, int day, bool permit) { this.build = build; this.day = day; this.permit = permit; } }//class FireEventArgs

Входные параметры события - build и day защищены от обработчиков события, а корректность выходного параметра гарантируется тщательным программированием самих обработчиков.

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

public void TestLifeTown() { NewTown sometown = new NewTown(100,100); sometown.LifeOurTown(); }

Результаты ее работы зависят от случайностей. Вот как выглядит один из экспериментов:

Рис. 21.3.  События в жизни города

Проект "Паутина Безье, кисти и краски"

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

Рис. 24.13.  Кнопочная форма "кисть или перо"
Выбор соответствующей командной кнопки открывает форму для рисования пером или кистью.

Проект Variables

Как обычно, для рассмотрения примеров построен специальный проект. В данной лекции это консольный проект с именем Variables. Построенный по умолчанию класс Class1 содержит точку входа Main. Добавленный в проект класс Testing содержит набор скалярных переменных и методов, тестирующих разные аспекты работы со скалярными переменными в C#. В процедуре Main создается объект класса Testing и поочередно вызываются его методы, каждый из которых призван проиллюстрировать те или иные моменты работы.

Проект WindowsHello

Давайте расширим приложение по умолчанию до традиционного приветствия в Windows-стиле, добавив окошки для ввода и вывода информации. Как уже говорилось, при создании Windows-приложения по умолчанию создается не только объект класса Form1 - потомка класса Form, но и его видимый образ - форма, с которой можно работать в режиме проектирования, населяя ее элементами управления. Добавим в форму следующие элементы управления:

• текстовое окно и метку. По умолчанию они получат имена textBox1 и label1. Текстовое окно предназначается для ввода имени пользователя, метка, визуально связанная с окном, позволит указать назначение текстового окна. Я установил свойство Multiline для текстового окна как true, свойство Text у метки - Ваше Имя;
• аналогичная пара элементов управления - textBox2 и label2 - предназначены для вывода приветствия. Поскольку окно textBox2 предназначено для вывода, то я включил его свойство ReadOnly;
• я посадил на форму командную кнопку, обработчик события Click которой и будет организовывать чтение имени пользователя из окна textBox1 и вывод приветствия в окно textBox2.

На рис. 2.4 показано, как выглядит наша форма в результате проектирования.

Рис. 2.4.  Форма "Приветствие"
Я не буду далее столь же подробно описывать действия по проектированию интерфейса форм, полагая, что все это интуитивно ясно и большинству хорошо знакомо. Более важно понимать то, что все действия по проектированию интерфейса незамедлительно транслируются в программный код, добавляемый в класс Form1. Мы вручную сажаем элемент управления на форму, тут же в классе появляется закрытое свойство, задающее этот элемент, а в процедуре InitailizeComponent выполняется его инициализация. Мы меняем некоторое свойство элемента управления, это незамедлительно находит отражение в программном коде указанной процедуры.
Вот как выглядит автоматически добавленное в класс описание элементов управления:
private System.Windows.Forms.Label label1; private System.Windows.Forms.TextBox textBox1; private System.Windows.Forms.Button button1; private System.Windows.Forms.TextBox textBox2; private System.Windows.Forms.Label label2;



А вот фрагмент текста процедуры InitailizeComponent:

#region Windows Form Designer generated code ///

/// Required method for Designer support - do not /// modify the contents of this method with the code /// editor. ///

private void InitializeComponent() { this.label1 = new System.Windows.Forms.Label(); this.textBox1 = new System.Windows.Forms.TextBox(); this.button1 = new System.Windows.Forms.Button(); this.textBox2 = new System.Windows.Forms.TextBox(); this.label2 = new System.Windows.Forms.Label(); this.SuspendLayout(); // label1 this.label1.Location = new System.Drawing.Point(24, 40); this.label1.Name = "label1"; this.label1.Size = new System.Drawing.Size(152, 32); this.label1.TabIndex = 0; this.label1.Text = "Ваше имя"; this.label1.TextAlign = System.Drawing.ContentAlignment.MiddleCenter; ... аналогично задаются описания свойств всех элементов управления ... ... далее задаются свойства самой формы ... // Form1 // this.AutoScaleBaseSize = new System.Drawing.Size(6, 15); this.ClientSize = new System.Drawing.Size(528, 268); this.Controls.AddRange(new System.Windows.Forms.Control[] { this.textBox2, this.label2, this.button1, this.textBox1, this.label1 }); this.Name = "Form1"; this.Text = "Приветствие"; this.Load += new System.EventHandler(this.Form1_Load); this.ResumeLayout(false); } #endregion

Заметьте, в теге

нас предупреждают, что этот метод требуется специальному инструментарию - Дизайнеру формы - и он не предназначен для редактирования пользователем; добавление и удаление кода этого метода производится автоматически. Обращаю внимание, что после заполнения свойств элементов управления заключительным шагом является их добавление в коллекцию Controls, хранящую все элементы управления. Здесь используется метод AddRange, позволяющий добавить в коллекцию одним махом целый массив элементов управления. Метод Add позволяет добавлять в коллекцию по одному элементу. Позже нам придется добавлять элементы управления в форму программно, динамически изменяя интерфейс формы. Для этого мы будем выполнять те же операции: объявить элемент управления, создать его, используя конструкцию new, задать нужные свойства и добавить в коллекцию Controls.

В заключение приведу текст обработчика событий командной кнопки. Как задается обработчик того или иного события для элементов управления? Это можно делать по-разному. Есть стандартный способ включения событий. Достаточно выделить нужный элемент в форме, в окне свойств нажать кнопку событий (со значком молнии) и из списка событий выбрать нужное событие и щелкнуть по нему. В данной ситуации все можно сделать проще - двойной щелчок по кнопке включает событие, и автоматически строится заготовка обработчика события с нужным именем и параметрами. Вот как она выглядит:

private void button1_Click(object sender,System.EventArgs e) {

}

Нам остается добавить свой текст. Я добавил следующие строки:

string temp; temp = textBox1.Text; if( temp == "") textBox2.Text = "Здравствуй, мир!"; else textBox2.Text = "Здравствуй, " + temp + " !";

И вот как это работает.

Рис. 2.5.  Форма "Приветствие" в процессе работы

На этом мы закончим первое знакомство с проектaми на C# и в последующих лекциях приступим к систематическому изучению возможностей языка.

Проектирование класса Rational

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

, описывающего назначение класса, его свойства и поведение. Вот этот текст:
///

/// Класс Rational /// определяет новый тип данных - рациональные числа и /// основные операции над ними - сложение, умножение, /// вычитание и деление. Рациональное число задается парой /// целых чисел (m,n) и изображается обычно в виде дроби m/n. /// Число m называется числителем,n - знаменателем. Для /// каждого рационального числа существует множество его /// представлений, например, 1/2, 2/4, 3/6, 6/12 - задают /// одно и тоже рациональное число. Среди всех представлений /// можно выделить то, в котором числитель и знаменатель /// взаимно несократимы. Такой представитель будет храниться /// в полях класса. Операции над рациональными числами /// определяются естественным для математики образом ///

public class Rational { // Описание тела класса Rational }//Rational

Пространство имен RegularExpression и классы регулярных выражений

Стандартный класс String позволяет выполнять над строками различные операции, в том числе поиск, замену, вставку и удаление подстрок. Существуют специальные операции, такие как Join, Split, которые облегчают разбор строки на элементы. Тем не менее, есть классы задач по обработке символьной информации, где стандартных возможностей явно не хватает. Чтобы облегчить решение подобных задач, в Net Framework встроен более мощный аппарат работы со строками, основанный на регулярных выражениях. Специальное пространство имен RegularExpression, содержит набор классов, обеспечивающих работу с регулярными выражениями. Все классы этого пространства доступны для C# и всех языков, использующих каркас Net Framework. В основе регулярных выражений лежит хорошая теория и хорошая практика их применения. Полное описание, как теоретических основ, так и практических особенностей применения этого аппарата в C#, требует отдельной книги. Придется ограничиться введением в эту интересную область работы со строками, не рассматривая подробно все классы, входящие в пространство имен RegularExpression.

Проверяемые преобразования

Уже упоминалось о том, что при выполнении явных преобразований могут возникать нежелательные явления, например, потеря точности. Я говорил, что вся ответственность за это ложится на программиста, и легче ему от этого не становится. А какую часть этого бремени может взять на себя язык программирования? Что можно предусмотреть для обнаружения ситуаций, когда такие явления все-таки возникают? В языке C# имеются необходимые для этого средства.
Язык C# позволяет создать проверяемый блок, в котором будет осуществляться проверка результата вычисления арифметических выражений. Если результат вычисления значения источника выходит за диапазон возможных значений целевой переменной, то возникнет исключение (говорят также: "будет выброшено исключение") соответствующего типа. Если предусмотрена обработка исключения, то дальнейшее зависит от обработчика исключения. В лучшем случае, программа сможет продолжить корректное выполнение. В худшем, - она остановится и выдаст информацию об ошибке. Заметьте, не произойдет самого опасного - продолжения работы программы с неверными данными.
Синтаксически проверяемый блок предваряется ключевым словом checked. В теле такого блока арифметические преобразования проверяются на допустимость. Естественно, подобная проверка требует дополнительных временных затрат. Если группа операторов в теле такого блока нам кажется безопасной, то их можно выделить в непроверяемый блок, используя ключевое слово unchecked. Замечу еще, что и в непроверяемом блоке при работе методов Convert все опасные преобразования проверяются и приводят к выбрасыванию исключений. Приведу пример, демонстрирующий все описанные ситуации:
///

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

public void CheckUncheckTest() { x = -25^2; WhoIsWho ("x", x); b= 255; WhoIsWho("b",b); // Проверяемые опасные преобразования. // Возникают исключения, перехватываемые catch-блоком. checked { try { b += 1; } catch (Exception e) { Console.WriteLine("Переполнение при вычислении b"); Console.WriteLine(e); } try { b = (byte)x; } catch (Exception e) { Console.WriteLine("Переполнение при преобразовании к byte"); Console.WriteLine(e); } // непроверяемые опасные преобразования unchecked { try { b +=1; WhoIsWho ("b", b); b = (byte)x; WhoIsWho ("b", b); ux= (uint)x; WhoIsWho ("ux", ux); Console.WriteLine("Исключений нет, но результаты не верны!"); } catch (Exception e) { Console.WriteLine("Этот текст не должен появляться"); Console.WriteLine(e); } // автоматическая проверка преобразований в Convert // исключения возникают, несмотря на unchecked try { b = Convert.ToByte(x); } catch (Exception e) { Console.WriteLine("Переполнение при преобразовании к byte!"); Console.WriteLine(e); } try { ux= Convert.ToUInt32(x); } catch (Exception e) { Console.WriteLine("Потеря знака при преобразовании к uint!"); Console.WriteLine(e); } } } }

Пустой оператор

Пустой оператор - это "пусто", завершаемое точкой с запятой. Иногда полезно рассматривать отсутствие операторов как существующий пустой оператор. Синтаксически допустимо ставить лишние точки с запятой, полагая, что вставляются пустые операторы. Например, синтаксически допустима следующая конструкция:
for (int j=1; j<5; j++) {;;;};
Она может рассматриваться как задержка по времени, работа на холостом ходе.

Работа со списками (еще один шаблон)

Для организации интерфейса разработано большое число элементов управления, часть из них показана на рис. 24.1. Все они обладают обширным набором свойств, методов и событий, их описание может занять отдельную книгу. Такие элементы, как, например, ListView, TreeView, DataGrid, несомненно, заслуживают отдельного рассмотрения, но не здесь и не сейчас. Я ограничусь более подробным разбором лишь одного элемента управления - ListBox, - позволяющего отображать данные в виде некоторого списка.

Расширение определения клиента класса

До сих пор мы говорили, что клиент содержит поле, представляющее объект класса поставщика. Это частая, но не единственная ситуация, когда класс является клиентом другого класса. Возможна ситуация, когда метод клиентского класса локально создает объект поставщика, вызывает его методы в собственных целях, но по завершении метода локальный объект заканчивает свою жизнь. Еще одна возможная ситуация - когда объекты поставщика вообще не создаются ни конструктором, ни методами класса клиента, но клиент вызывает статические методы класса поставщика. Оба эти варианта демонстрируют следующие два метода класса B:
public void MethodB2() { ClassA loc = new ClassA("локальный объект А",77); loc.MethodA(); } public void MethodB3() { ClassA.StatMethodA(); }
Дадим теперь расширенное определение клиента.
Определение 3. Класс B называется клиентом класса A, если в классе B создаются объекты класса A - поля или локальные переменные - или вызываются статические поля или методы класса A.

Рассмотрим объявления:

int x=3, y=5; object obj1, obj2;
Здесь объявлены четыре сущности: две переменные значимого типа и две - объектного. Значимые переменные x и y проинициализированы и имеют значения, объектные переменные obj1 и obj2 являются пустыми ссылками со значением void. Рассмотрим присваивания:
obj1 = x; obj2 = y;
Эти присваивания ссылочные (из-за типа левой части), поэтому правая часть приводится к ссылочному типу. В результате неявного преобразования - операции boxing - в динамической памяти создаются два объекта, обертывающие соответственно значения переменных x и y. Сущности obj1 и obj2 получают значения ссылок на эти объекты.

Развернутые и ссылочные типы

Рассмотрим объявление объекта класса T с инициализацией:
T x = new T();
Напомню, как выполняется этот оператор. В памяти создается объект типа T, основанного на классе T, и сущность x связывается с этим объектом. Сущность, не прошедшая инициализацию (явную или неявную), не связана ни с одним объектом, а потому не может использоваться в вычислениях - у нее нет полей, хранящих значения, она не может вызывать методы класса. Объектам нужна память, чтобы с ними можно было работать. Есть две классические стратегии выделения памяти и связывания объекта, создаваемого в памяти, и сущности, объявленной в тексте.
Определение 1. Класс T относится к развернутому типу, если память отводится сущности x; объект разворачивается на памяти, жестко связанной с сущностью.
Определение 2. Класс T относится к ссылочному типу, если память отводится объекту; сущность x является ссылкой на объект.
Для развернутого типа характерно то, что каждая сущность ни с кем не разделяет свою память; сущность жестко связывается со своим объектом. В этом случае сущность и объект можно и не различать, они становятся неделимым понятием. Для ссылочных типов ситуация иная - несколько сущностей могут ссылаться на один и тот же объект. Такие сущности разделяют память и являются разными именами одного объекта. Полезно понимать разницу между сущностью, заданной ссылкой, и объектом, на который в текущий момент указывает ссылка.
Развернутые и ссылочные типы порождают две различные семантики присваивания - развернутое присваивание и ссылочное присваивание. Рассмотрим присваивание:
y = x;
Когда сущность y и выражение x принадлежат развернутому типу, то при присваивании изменяется объект. Значения полей объекта, связанного с сущностью y, изменяются, получая значения полей объекта, связанного с x. Когда сущность y и выражение x принадлежат ссылочному типу, то изменяется ссылка, но не объект. Ссылка y получает значение ссылки x, и обе они после присваивания указывают на один и тот же объект.
Язык программирования должен позволять программисту в момент определения класса указать, к развернутому или ссылочному типу относится класс. К сожалению, язык C# не позволяет этого сделать напрямую - в нем у класса нет модификатора, позволяющего задать развернутый или ссылочный тип. Какие же средства языка позволяют частично решить эту важную задачу? В лекции 3, где рассматривалась система типов языка C#, отмечалось, что все типы языка делятся на ссылочные и значимые. Термин "значимый" является синонимом термина "развернутый". Беда только в том, что деление на значимые и ссылочные типы предопределено языком и не управляется программистом. Напомню, к значимым типам относятся все встроенные арифметические типы, булев тип, структуры; к ссылочным типам - массивы, строки, классы. Так можно ли в C# спроектировать свой собственный класс так, чтобы он относился к значимым типам? Ответ на этот вопрос положительный, хотя и с рядом оговорок. Для того чтобы класс отнести к значимым типам, его нужно реализовать как структуру.

Рекурсия

Рекурсия является одним из наиболее мощных средств в арсенале программиста. Рекурсивные структуры данных и рекурсивные методы широко используются при построении программных систем. Рекурсивные методы, как правило, наиболее всего удобны при работе с рекурсивными структурами данных - списками, деревьями. Рекурсивные методы обхода деревьев служат классическим примером.
Определение 6 (рекурсивного метода): метод P (процедура или функция) называется рекурсивным, если при выполнении тела метода происходит вызов метода P.
Рекурсия может быть прямой, если вызов P происходит непосредственно в теле метода P. Рекурсия может быть косвенной, если в теле P вызывается метод Q (эта цепочка может быть продолжена), в теле которого вызывается метод P. Определения методов P и Q взаимно рекурсивны, если в теле метода Q вызывается метод P, вызывающий, в свою очередь, метод Q.
Для того чтобы рекурсия не приводила к зацикливанию, в тело нормального рекурсивного метода всегда встраивается оператор выбора, одна из ветвей которого не содержит рекурсивных вызовов. Если в теле рекурсивного метода рекурсивный вызов встречается только один раз, значит, что рекурсию можно заменить обычным циклом, что приводит к более эффективной программе, поскольку реализация рекурсии требует временных затрат и работы со стековой памятью. Приведу вначале простейший пример рекурсивного определения функции, вычисляющей факториал целого числа:
public long factorial(int n) { if (n<=1) return(1); else return(n*factorial(n-1)); }//factorial
Функция factorial является примером прямого рекурсивного определения - в ее теле она сама себя вызывает. Здесь, как и положено, есть нерекурсивная ветвь, завершающая вычисления, когда n становится равным единице. Это пример так называемой "хвостовой" рекурсии, когда в теле встречается ровно один рекурсивный вызов, стоящий в конце соответствующего выражения. Хвостовую рекурсию намного проще записать в виде обычного цикла. Вот циклическое определение той же функции:
public long fact(int n) { long res =1; for(int i = 2; i <=n; i++) res*=i; return(res); }//fact



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

public void TestTailRec() { Hanoi han = new Hanoi(5); long time1, time2; long f=0; time1 = getTimeInMilliseconds(); for(int i = 1; i <1000000; i++)f =han.fact(15); time2 =getTimeInMilliseconds(); Console.WriteLine(" f= {0}, " + "Время работы циклической процедуры: {1}",f,time2 -time1); time1 = getTimeInMilliseconds(); for(int i = 1; i <1000000; i++)f =han.factorial(15); time2 =getTimeInMilliseconds(); Console.WriteLine(" f= {0}, " + "Время работы рекурсивной процедуры: {1}",f,time2 -time1); }

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

Проводить сравнение эффективности работы различных вариантов - это частый прием, используемый при разработке программ. И я им буду пользоваться неоднократно. Встроенный тип DateTime обеспечивает необходимую поддержку для получения текущего времени. Он совершенно необходим, когда приходится работать с датами. Я не буду подробно описывать его многочисленные статические и динамические методы и свойства. Ограничусь лишь приведением функции, которую я написал для получения текущего времени, измеряемого в миллисекундах. Статический метод Now класса DateTime возвращает объект этого класса, соответствующий дате и времени в момент создания объекта. Многочисленные свойства этого объекта позволяют извлечь требуемые характеристики. Приведу текст функции getTimeInMilliseconds:

long getTimeInMilliseconds() { DateTime time = DateTime.Now; return(((time.Hour*60 + time.Minute)*60 + time.Second)*1000 + time.Millisecond); }

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

Рис. 10.1.  Сравнение времени работы циклической и рекурсивной функций

Вовсе не обязательно, что рекурсивные методы будут работать медленнее нерекурсивных. Классическим примером являются методы сортировки. Известно, что время работы нерекурсивной пузырьковой сортировки имеет порядок c*n2, где c - некоторая константа. Для рекурсивной процедуры сортировки слиянием время работы - q*n*log(n), где q - константа. Понятно, что для больших n сортировка слиянием работает быстрее, независимо от соотношения значений констант. Сортировка слиянием - хороший пример применения рекурсивных методов. Она демонстрирует известный прием, называемый "разделяй и властвуй". Его суть в том, что исходная задача разбивается на подзадачи меньшей размерности, допускающие решение тем же алгоритмом. Решения отдельных подзадач затем объединяются, давая решение исходной задачи. В задаче сортировки исходный массив размерности n можно разбить на два массива размерности n/2, для каждого из которых рекурсивно вызывается метод сортировки слиянием. Полученные отсортированные массивы сливаются в единый массив с сохранением упорядоченности.

На примере сортировки слиянием покажем, как можно оценить время работы рекурсивной процедуры. Обозначим через T(n) время работы процедуры на массиве размерности n. Учитывая, что слияние можно выполнить за линейное время, справедливо следующее соотношение:

T(n) = 2T(n/2) + cn

Предположим для простоты, что n задается степенью числа 2, то есть n = 2k. Тогда наше соотношение имеет вид:

T(2k) = 2T(2k-1) + c2k

Полагая, что T(1) =c, путем несложных преобразований, используя индукцию, можно получить окончательный результат:

T(2k) = c*k*2k = c*n*log(n)

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

Рекурсивное решение задачи "Ханойские башни"

Рассмотрим известную задачу о конце света - "Ханойские башни". Ее содержательная постановка такова. В одном из буддийских монастырей монахи уже тысячу лет занимаются перекладыванием колец. Они располагают тремя пирамидами, на которых надеты кольца разных размеров.
В начальном состоянии 64 кольца были надеты на первую пирамиду и упорядочены по размеру. Монахи должны переложить все кольца с первой пирамиды на вторую, выполняя единственное условие - кольцо нельзя положить на кольцо меньшего размера. При перекладывании можно использовать все три пирамиды. Монахи перекладывают одно кольцо за одну секунду. Как только они закончат свою работу, наступит конец света.
Беспокоиться о близком конце света не стоит. Задача эта не под силу и современным компьютерам. Число ходов в ней равно 264, а это, как известно, большое число, и компьютер, работающий в сотню миллионов раз быстрее монахов, не справится с этой задачей в ближайшие тысячелетия.
Рассмотрим эту задачу в компьютерной постановке. Я спроектировал класс Hanoi, в котором роль пирамид играют три массива, а числа играют роль колец. Вот описание данных этого класса и некоторых его методов:
public class Hanoi { int size,moves; int[] tower1, tower2,tower3; int top1,top2,top3; Random rnd = new Random(); public Hanoi(int size) { this.size = size; tower1 = new int[size]; tower2 = new int[size]; tower3 = new int[size]; top1 = size; top2=top3=moves =0; } public void Fill() { for(int i =0; i< size; i++) tower1[i]=size-i; } }//Hanoi
Массивы tower играют роль ханойских башен, связанные с ними переменные top задают вершину - первую свободную ячейку при перекладывании колец (чисел). Переменная size задает размер массивов (число колец), а переменная moves используется для подсчета числа ходов. Для дальнейших экспериментов нам понадобится генерирование случайных чисел, поэтому в классе определен объект уже известного нам класса Random (см. лекцию 7). Конструктор класса инициализирует поля класса, а метод Fill формирует начальное состояние, задавая для первой пирамиды числа, идущие в порядке убывания к ее вершине (top).
Займемся теперь непосредственно методом, реализующим нашу игру и перекладывающим кольца в соответствии с правилами игры. Заметьте, написать нерекурсивный вариант ханойских башен совсем не просто. Можно, конечно, написать цикл, завершающийся по достижению требуемой конфигурации, на каждом шаге которого выполняется очередной ход. Но даже первый ход не тривиален. Поскольку фиксирована пирамида, где должны быть собраны кольца, то неясно, куда нужно переложить первое кольцо - на вторую или третью пирамиду?
Рекурсивный вариант решения задачи прозрачен, хотя и напоминает некоторый род фокуса, что характерно для рекурсивного стиля мышления. Базис рекурсии прост. Для перекладывания одного кольца задумываться о решении не нужно - оно делается в один ход. Если есть базисное решение, то оставшаяся часть также очевидна. Нужно применить рекурсивно алгоритм, переложив n-1 кольцо с первой пирамиды на третью пирамиду. Затем сделать очевидный ход, переложив последнее самое большое кольцо с первой пирамиды на вторую. Затем снова применить рекурсию, переложив n-1 кольцо с третьей пирамиды на вторую пирамиду. Задача решена. Столь же проста ее запись на языке программирования:
public void HanoiTowers() { HT(ref tower1,ref tower2, ref tower3, ref top1, ref top2, ref top3,size); Console.WriteLine("\nВсего ходов 2^n -1 = {0}",moves); }



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

///

/// Перенос count колец с tower1 на tower2, соблюдая /// правила и используя tower3. Свободные вершины /// башен - top1, top2, top3 ///

void HT(ref int[] t1, ref int[] t2, ref int[] t3, ref int top1, ref int top2, ref int top3, int count) { if (count == 1)Move(ref t1,ref t2, ref top1,ref top2); else { HT(ref t1,ref t3,ref t2,ref top1,ref top3, ref top2,count-1); Move(ref t1,ref t2,ref top1, ref top2); HT(ref t3,ref t2,ref t1,ref top3,ref top2, ref top1,count-1); } }//HT

Процедура Move описывает очередной ход. Ее аргументы однозначно задают, с какой и на какую пирамиду нужно перенести кольцо. Никаких сложностей в ее реализации нет:

void Move(ref int[]t1, ref int[] t2, ref int top1, ref int top2) { t2[top2] = t1[top1-1]; top1--; top2++; moves++; //PrintTowers(); }//Move

Метод PrintTowers позволяет проследить за ходом переноса. Приведу еще метод класса Testing, тестирующий работу по переносу колец:

public void TestHanoiTowers() { Hanoi han = new Hanoi(10); Console.WriteLine("Ханойские башни"); han.Fill(); han.PrintTowers(); han.HanoiTowers(); han.PrintTowers(); }

На рис. 10.2 показаны результаты работы с включенной печатью каждого хода для случая переноса трех колец.

Рис. 10.2.  "Ханойские башни"

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

Решение исходной задачи свелось к решению двух подзадач и одному ходу. В отличие от задачи сортировки слиянием, обе подзадачи имеют не половинный размер, а размер, лишь на единицу меньший исходного. Это, казалось бы, незначительное изменение приводит к серьезным потерям эффективности вычислений. Если сложность в первом случае имела порядок n*log(n), то теперь она становится экспоненциальной. Давайте проведем анализ временных затрат для ханойских башен (и всех задач, сводящихся к решению двух подзадач размерности n-1). Подсчитаем требуемое число ходов T(n). С учетом структуры решения:

T(n) = 2T(n-1) +1

Простое доказательство по индукции дает:

T(n) = 2n-1 + 2n-2 + ... + 2 +1 = 2n -1

Можно показать, что последовательность ходов, реализуемая рекурсивным алгоритмом, является оптимальной, так что никакой другой алгоритм не может решить задачу за меньшее число ходов.

Рисование в форме

Графика необходима при организации пользовательского интерфейса. Образы информативнее текста. Framework .Net реализует расширенный графический интерфейс GDI+, обладающий широким набором возможностей. Но для рисования в формах достаточно иметь три объекта - перо, кисть и, хочется сказать, бумагу, но третий нужный объект - это объект класса Graphics, методы которого позволяют в формах заниматься графикой - рисовать и раскрашивать.

Родовое порождение класса. Предложение using

До сих пор рассматривалась ситуация родового порождения экземпляров универсального класса. Фактические типы задавались в момент создания экземпляра. Это наглядно показывает преимущества применяемой технологии, поскольку очевидно, что не создается дублирующий код для каждого класса, порожденного универсальным классом. И все-таки остается естественный вопрос: можно ли породить класс из универсального класса путем подстановки фактических параметров, а потом спокойно использовать этот класс обычным образом? Такая вещь возможна. Это можно сделать не совсем обычным путем - не в программном коде, а в предложении using, назначение которого и состоит в выполнении подобных подстановок.
Давайте вернемся к универсальному классу OneLinkStack, введенному в начале этой лекции, и породим на его основе вполне конкретный класс IntStack, заменив формальный параметр T фактическим - int. Для этого достаточно задать следующее предложение using:
using IntStack = Generic.OneLinkStack;
Вот тест, в котором создаются несколько объектов этого класса:
public void TestIntStack() { IntStack stack1 = new IntStack(); IntStack stack2 = new IntStack(); IntStack stack3 = new IntStack(); stack1.put(11); stack1.put(22); int x1 = stack1.item(), x2 = stack1.item(); if ((x1 == x2) && (x1 == 22)) Console.WriteLine("OK!"); stack1.remove(); x2 = stack1.item(); if ((x1 != x2) && (x2 == 11)) Console.WriteLine("OK!"); stack1.remove(); x2 = (stack1.empty()) ? 77 : stack1.item(); if ((x1 != x2) && (x2 == 77)) Console.WriteLine("OK!"); stack2.put(55); stack2.put(66); stack2.remove(); int s = stack2.item(); if (!stack2.empty()) Console.WriteLine(s); stack3.put(333); stack3.put((int)Math.Sqrt(Math.PI)); int res = stack3.item(); stack3.remove(); res += stack3.item(); Console.WriteLine("res= {0}", res); }
Все работает заданным образом, можете поверить.

С чего начинается выполнение выражения

Вычисление выражения начинается с выполнения операций высшего приоритета. Первым делом вычисляются выражения в круглых скобках - (expr), определяются значения полей объекта - x.y, вычисляются функции - f(x), переменные с индексами - a[i]. Выполнение этих операций достаточно понятно и не нуждается в комментировании. Операции checked и unchecked включают и выключают проверку преобразований арифметического типа в выражениях, которым они предшествуют. О других операциях этой категории скажу чуть подробнее.

Сам себе клиент

Зададимся вопросом, может ли класс быть сам себе клиентом, другими словами, может ли поле класса быть объектом описываемого класса? Другой, не менее интересный вопрос - могут ли два класса быть одновременно клиентами и поставщиками друг для друга? Ответы на оба вопросы положительны, и подобные ситуации типичны и не являются какой-либо экзотикой.
Первая ситуация характерна для динамических структур данных. Элемент односвязного списка имеет поле, представляющее элемент односвязного списка; элемент двусвязного списка имеет два таких поля; узел двоичного дерева имеет два поля, представляющих узлы двоичного дерева. Эта ситуация характерна не только для рекурсивно определяемых структур данных. Вот еще один типичный пример. В классе Person могут быть заданы два поля - Father и Mother, задающие родителей персоны, и массив Children. Понятно, что все эти объекты могут быть того же класса Person.
Не менее часто встречается ситуация, когда классы имеют поля, взаимно ссылающиеся друг на друга. Типичным примером могут служить классы Man и Woman, первый из которых имеет поле wife класса Woman, а второй - поле husband класса Man.
Заметьте, классы устроены довольно просто - их тексты понятны, отношения между классами очевидны. А вот динамический мир объектов этих классов может быть довольно сложным, отношения между объектами могут быть запутанными; для объектов характерны не только любовные треугольники, но и куда более сложные фигуры.

Сборщик мусора - Garbage Collector - и управление памятью

Еще одной важной особенностью построения CLR является то, что исполнительная среда берет на себя часть функций, традиционно входящих в ведение разработчиков трансляторов, и облегчает тем самым их работу. Один из таких наиболее значимых компонентов CLR - сборщик мусора (Garbage Collector). Под сборкой мусора понимается освобождение памяти, занятой объектами, которые стали бесполезными и не используются в дальнейшей работе приложения. В ряде языков программирования (классическим примером является язык C/C++) память освобождает сам программист, в явной форме отдавая команды как на создание, так и на удаление объекта. В этом есть своя логика - "я тебя породил, я тебя и убью". Однако можно и нужно освободить человека от этой работы. Неизбежные ошибки программиста при работе с памятью тяжелы по последствиям, и их крайне тяжело обнаружить. Как правило, объект удаляется в одном модуле, а необходимость в нем обнаруживается в другом, далеком модуле. Обоснование того, что программист не должен заниматься удалением объектов, а сборка мусора должна стать частью исполнительной среды, дано достаточно давно. Наиболее полно оно обосновано в работах Бертрана Мейера и в его книге "Object-Oriented Construction Software", первое издание которой появилось еще в 1988 году.
В CLR эта идея реализована в полной мере. Задача сборки мусора снята не только с программистов, но и с разработчиков трансляторов, она решается в нужное время и в нужном месте - исполнительной средой, ответственной за выполнение вычислений. Здесь же решаются и многие другие вопросы, связанные с использованием памяти, в частности, проверяются возможные нарушения использования "чужой" памяти и другие нарушения, например, с использованием нетипизированных указателей. Данные, удовлетворяющие требованиям CLR и допускающие сборку мусора, называются управляемыми данными.
Но, как же, спросите вы, быть с языком C++ и другими языками, где есть нетипизированные указатели, адресная арифметика, возможности удаления объектов программистом? Такие возможности сохранены и в языке C#. Ответ следующий - CLR позволяет работать как с управляемыми, так и с неуправляемыми данными. Однако использование неуправляемых данных регламентируется и не поощряется. Так, в C# модуль, использующий неуправляемые данные (указатели, адресную арифметику), должен быть помечен как небезопасный (unsafe), и эти данные должны быть четко зафиксированы. Об этом мы еще будем говорить при рассмотрении языка C# в последующих лекциях. Исполнительная среда, не ограничивая возможности языка и программистов, вводит определенную дисциплину в применении потенциально опасных средств языков программирования.

Семантика присваивания. Преобразования между ссылочными и значимыми типами

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

• Цель и источник значимого типа. Здесь наличествует семантика значимого присваивания. В этом случае источник и цель имеют собственную память для хранения значений. Значения источника заменяют значения соответствующих полей цели. Источник и цель после этого продолжают жить независимо. У них своя память, хранящая после присваивания одинаковые значения.
• Цель и источник ссылочного типа. Здесь имеет место семантика ссылочного присваивания. В этом случае значениями источника и цели являются ссылки на объекты, хранящиеся в памяти ("куче"). При ссылочном присваивании цель разрывает связь с тем объектом, на который она ссылалась до присваивания, и становится ссылкой на объект, связанный с источником. Результат ссылочного присваивания двоякий. Объект, на который ссылалась цель, теряет одну из своих ссылок и может стать висячим, так что его дальнейшую судьбу определит сборщик мусора. С объектом в памяти, на который ссылался источник, теперь связываются, по меньшей мере, две ссылки, рассматриваемые как различные имена одного объекта. Ссылочное присваивание приводит к созданию псевдонимов - к появлению разных имен у одного объекта. Особо следует учитывать ситуацию, когда цель и/или источник имеет значение void. Если такое значение имеет источник, то в результате присваивания цель получает это значение и более не ссылается ни на какой объект. Если же цель имела значение void, а источник - нет, то в результате присваивания ранее "висячая" цель становится ссылкой на объект, связанный с источником.
• Цель ссылочного типа, источник значимого типа. В этом случае "на лету" значимый тип преобразуется в ссылочный. Как обеспечивается двойственность существования значимого и ссылочного типа - переменной и объекта? Ответ прост: за счет специальных, эффективно реализованных операций, преобразующих переменную значимого типа в объект и обратно. Операция "упаковать" (boxing) выполняется автоматически и неявно в тот момент, когда по контексту требуется объект, а не переменная. Например, при вызове процедуры WhoIsWho требуется, чтобы аргумент any был объектом. Если фактический аргумент является переменной значимого типа, то автоматически выполняется операция "упаковать". При ее выполнении создается настоящий объект, хранящий значение переменной. Можно считать, что происходит упаковка переменной в объект. Необходимость в упаковке возникает достаточно часто. Примером может служить и процедура консольного вывода WriteLine класса Console, которой требуются объекты, а передаются зачастую переменные значимого типа.
• Цель значимого типа, источник ссылочного типа. В этом случае "на лету" ссылочный тип преобразуется в значимый. Операция "распаковать" (unboxing) выполняет обратную операцию, - она "сдирает" объектную упаковку и извлекает хранимое значение. Заметьте, операция "распаковать" не является обратной к операции "упаковать" в строгом смысле этого слова. Оператор obj = x корректен, но выполняемый следом оператор x = obj приведет к ошибке. Недостаточно, чтобы хранимое значение в упакованном объекте точно совпадало по типу с переменной, которой присваивается объект. Необходимо явно заданное преобразование к нужному типу.

Семантика присваивания

Рассмотрим присваивание:
x = e.
Чтобы присваивание было допустимым, типы переменной x и выражения e должны быть согласованными. Пусть сущность x согласно объявлению принадлежит классу T. Будем говорить, что тип T основан на классе T и является базовым типом x, так что базовый тип определяется классом объявления. Пусть теперь в рассматриваемом нами присваивании выражение e связано с объектом типа T1.
Определение: тип T1 согласован по присваиванию с базовым типом T переменной x, если класс T1 является потомком класса T.
Присваивание допустимо, если и только если имеет место согласование типов. Так как все классы в языке C# - встроенные и определенные пользователем - по определению являются потомками класса Object, то отсюда и следует наш частный случай - переменным класса Object можно присваивать выражения любого типа.
Несмотря на то, что обстоятельный разговор о наследовании, родителях и потомках нам еще предстоит, лучше с самого начала понимать отношения между родительским классом и классом-потомком, отношения между объектами этих классов. Класс-потомок при создании наследует все свойства и методы родителя. Родительский класс не имеет возможности наследовать свойства и методы, создаваемые его потомками. Наследование - это односторонняя операция от родителя к потомку. Ситуация с присваиванием симметричная. Объекту родительского класса присваивается объект класса-потомка. Объекту класса-потомка не может быть присвоен объект родительского класса. Присваивание - это односторонняя операция от потомка к родителю. Одностороннее присваивание реально означает, что ссылочная переменная родительского класса может быть связана с любыми объектами, имеющими тип потомков родительского класса.
Например, пусть задан некоторый класс Parent, а класс Child - его потомок, объявленный следующим образом:
class Child:Parent {...}
Пусть теперь в некотором классе, являющемся клиентом классов Parent и Child, объявлены переменные этих классов и созданы связанные с ними объекты:
Parent p1 = new Parent(), p2 = new Parent(); Child ch1 = new Child(), ch2 = new Child();
Тогда допустимы присваивания:
p1 = p2; p2= p1; ch1=ch2; ch2 = ch1; p1 = ch1; p1 = ch2;
Но недопустимы присваивания:
ch1 = p1; ch2 = p1; ch2 = p2; ch1 = p2;
Заметьте, ситуация не столь удручающая - сын может вернуть себе переданный родителю объект, задав явное преобразование. Так что следующие присваивания допустимы:
p1 = ch1; ... ch1 = (Child)p1;
Семантика присваивания справедлива и для другого важного случая - при рассмотрении соответствия между формальными и фактическими аргументами процедур и функций. Если формальный аргумент согласно объявлению имеет тип T, а выражение, задающее фактический аргумент, имеет тип T1, то имеет место согласование типов формального и фактического аргумента, если и только если класс T1 является потомком класса T. Отсюда незамедлительно следует, что если формальный параметр процедуры принадлежит классу Object, то фактический аргумент может быть выражением любого типа.

Сериализация объектов

При работе с программной системой зачастую возникает необходимость в сериализации объектов. Под сериализацией понимают процесс сохранения объектов в долговременной памяти (файлах) в период выполнения системы. Под десериализацией понимают обратный процесс - восстановление состояния объектов, хранимых в долговременной памяти. Механизмы сериализации C# и Framework .Net поддерживают два формата сохранения данных - в бинарном файле и XML-файле. В первом случае данные при сериализации преобразуются в бинарный поток символов, который при десериализации автоматически преобразуется в нужное состояние объектов. Другой возможный преобразователь (SOAP formatter) запоминает состояние объекта в формате xml.
Сериализация позволяет запомнить рубежные состояния системы объектов с возможностью последующего возвращения к этим состояниям. Она необходима, когда завершение сеанса работы не означает завершение вычислений. В этом случае очередной сеанс работы начинается с восстановления состояния, сохраненного в конце предыдущего сеанса работы. Альтернативой сериализации является работа с обычной файловой системой, с базами данных и другими хранилищами данных. Поскольку механизмы сериализации, предоставляемые языком C#, эффективно поддерживаются .Net Framework, то при необходимости сохранения данных значительно проще и эффективнее пользоваться сериализацией, чем самому организовывать их хранение и восстановление.
Еще одно важное применение сериализации - это обмен данными удаленных систем. При удаленном обмене данными предпочтительнее формат xml из-за открытого стандарта передачи данных в Интернете по soap-протоколу, из-за открытого стандарта на структуру xml-документов. Обмен становится достаточно простым даже для систем, построенных на разных платформах и в разных средах разработки.
Так же, как и клонирование, сериализация может быть поверхностной, когда сериализуется на одном шаге единственный объект, и глубокой, когда, начиная с корневого объекта, сериализуется совокупность объектов, связанных взаимными ссылками (граф объектов). Глубокую сериализацию, часто обязательную, самому организовать непросто, так как она требует, как правило, рекурсивного обхода структуры объектов.
Если класс объявить с атрибутом [Serializable], то в него встраивается стандартный механизм сериализации, поддерживающий, что крайне приятно, глубокую сериализацию. Если по каким-либо причинам стандартная сериализация нас не устраивает, то класс следует объявить наследником интерфейса ISerialzable, реализация методов которого позволит управлять процессом сериализации. Мы рассмотрим обе эти возможности.

Шаблон формы для работы с классом

Можно предложить следующий образец формы, предназначенной для поддержки работы с объектами некоторого класса. Напомню, каждый класс представляет тип данных. Операции над типом данных можно разделить на три категории: конструкторы, команды и запросы. Конструкторы класса позволяют создать соответствующий объект; команды, реализуемые процедурами, изменяют состояние объекта; запросы, реализуемые функциями без побочных эффектов, возвращают информацию о состоянии объекта, не изменяя самого состояния. Исходя из этого, можно сконструировать интерфейс формы, выделив в нем три секции. В первой секции, разделенной на три раздела, будут представлены команды, запросы и конструкторы. Следующая секция выделяется для окон, в которые можно вводить аргументы исполняемых команд. Последняя секция предназначается для окон, в которых будут отображаться результаты запросов.
На рис. 24.3 показана форма для списка с курсором, построенная в соответствии с описанным шаблоном.

Рис. 24.3.  Форма для списка с курсором, построенная по образцу
Список с курсором имеет группу команд, позволяющих перемещать курсор влево, вправо, к началу и концу списка, к элементу с заданным номером. Другая группа команд позволяет производить операции по вставке элементов слева или справа от курсора, удалять элемент, отмеченный курсором. Еще одна группа позволяет производить поиск элементов в списке. Запросы позволяют получить данные об активном элементе, отмеченном курсором, определить число элементов в списке и получить другую полезную информацию.

Схема Бертрана обработки исключительных ситуаций

Схема обработки исключительных ситуаций, предложенная в языке C#, обладает одним существенным изъяном - ее можно применить некорректно. Она позволяет, в случае возникновения исключительной ситуации, уведомить о ее возникновении и спокойно продолжить работу, что в конечном счете приведет к неверным результатам. Из двух зол - прервать вычисление с уведомлением о невозможности продолжения работы или закончить вычисления с ошибочным результатом вычисления - следует выбирать первое. Некорректно примененная схема C# приведет к ошибочным результатам. Приведу несколько примеров. Представьте, оформляется заказ на отдых где-нибудь на Канарах. В ходе оформления возникает исключительная ситуация - нет свободных мест в гостинице - обработчик исключения посылает уведомление с принесением извинений, но оформление заказа продолжается. Вероятно, предпочтительнее отказаться от отдыха на Канарах и выбрать другое место, чем оказаться без крыши над головой, ночуя на берегу океана. Эта ситуация не является критически важной. А что, если в процессе подготовки операции выясняется, что проведение ее в данном случае опасно? Никакие извинения не могут избавить от вреда, нанесенного операцией. Операция должна быть отменена.
Бертран Мейер в книге [1], в которой все механизмы, используемые в объектной технологии, тщательно обосновываются, предложил следующую схему обработки исключительных ситуаций. В основе ее лежит подход к проектированию программной системы на принципах Проектирования по Контракту. Модули программной системы, вызывающие друг друга, заключают между собой контракты. Вызывающий модуль обязан обеспечить истинность предусловия, необходимого для корректной работы вызванного модуля. Вызванный модуль обязан гарантировать истинность постусловия по завершении своей работы. Если в вызванном модуле возникает исключительная ситуация, то это означает, что он не может выполнить свою часть контракта. Что должен делать обработчик исключительной ситуации? У него только две возможности - Retry и Rescue. Первая (Retry) - попытаться внести некоторые коррективы и вернуть управление охраняемому модулю, который может предпринять очередную попытку выполнить свой контракт. Модуль может, например в следующей попытке запустить другой алгоритм, использовать другой файл, другие данные. Если все закончится успешно и работа модуля будет соответствовать его постусловию, то появление исключительной ситуации можно рассматривать как временные трудности, успешно преодоленные. Если же ситуация возникает вновь и вновь, тогда обработчик события применяет вторую стратегию (Rescue), выбрасывая исключение и передавая управление вызывающему модулю, который и должен теперь попытаться исправить ситуацию. Важная тонкость в схеме, предложенной Бертраном, состоит в том, что исключение, выбрасываемое обработчиком, следует рассматривать не как панику, не как бегство, а как отход на заранее подготовленные позиции. Обработчик исключения должен позаботиться о восстановлении состояния, предшествующего вызову модуля, который привел к исключительной ситуации, и это гарантирует нахождение всей системы в корректном состоянии.
Схема Бертрана является схемой с возобновлением, и она наиболее точно описывает разумную стратегию обработки исключительных ситуаций. Не следует думать, что эта схема не может быть реализована на C#, просто она требует понимания сути и определенной структурной организации модуля. Приведу возможную реализацию такой схемы на C#:
public void Pattern() { do { try { bool Danger = false; Success = true; MakeJob(); Danger = CheckDanger(); if (Danger) throw (new MyException()); MakeLastJob(); } catch (MyException me) { if(count > maxcount) throw(new MyException("Три попытки были безуспешны")); Success = false; count++; //корректировка ситуации Console.WriteLine("Попытка исправить ситуацию!"); level +=1; } }while (!Success); }



Приведу краткие комментарии к этой процедуре, которую можно рассматривать как некоторый образец организации обработки исключительной ситуации:

• Конструкция try-catch блоков помещается в цикл do-while(!Success), завершаемый в случае успешной работы охраняемого блока, за чем следит булева переменная Success.
• В данном образце предполагается, что в теле охраняемого блока анализируется возможность возникновения исключительной ситуации и, в случае обнаружения опасности, выбрасывается собственное исключение, класс которого задан программно. В соответствии с этим тело try-блока содержит вызов метода MakeJob, выполняющего некоторую часть работы, после чего вызывается метод CheckDanger, выясняющий, не возникла ли опасность нарушения спецификации и может ли работа быть продолжена. Если все нормально, то выполняется метод MakeLastJob, выполняющий заключительную часть работы. Управление вычислением достигает конца try-блока, он успешно завершается и, поскольку остается истинной переменная Success, значение true которой установлено в начале try-блока, то цикл while, окаймляющий охраняемый блок и его обработчиков исключений, также успешно завершается.
• Если в методе CheckDanger выясняется, что нормальное продолжение вычислений невозможно, то выбрасывается исключение класса MyException. Оно перехватывается обработчиком исключения, стоящим за try-блоком, поскольку класс MyException указан как класс формального аргумента.
• Для простоты приведен только один catch-блок. В общем случае их может быть несколько, но все они строятся по единому образцу. Предполагается, что обработчик исключения может сделать несколько попыток исправить ситуацию, после чего повторно выполняется охраняемый блок. Если же число попыток, за которым следит переменная count, превосходит максимально допустимое, то обработчик выбрасывает новое исключение, задавая дополнительную информацию и передавая тем самым обработку ошибки на следующий уровень - вызываемой программе.
• Когда число попыток еще не исчерпано, обработчик исключения переменной Success дает значение false, гарантирующее повтор выполнения try-блока, увеличивает счетчик числа попыток и пытается исправить ситуацию.
• Как видите, эта схема реализует два корректных исхода обработки исключительной ситуации - Retry и Rescue - повтору с надеждой выполнить обязательства и передачи управления вызывающей программе, чтобы она предприняла попытки исправления ситуации, когда вызванная программа не смогла с этим справиться.

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

Определим первым делом собственный класс исключений:

public class MyException :Exception { public MyException() {} public MyException (string message) : base(message) {} public MyException (string message, Exception e) : base(message, e) {} }

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

В классе Excepts, методом которого является наш образец Pattern, определим следующие поля класса:

Random rnd = new Random(); int level = -10; bool Success; //true - нормальное завершение int count =1; // число попыток выполнения const int maxcount =3;

Определим теперь методы, вызываемые в теле охраняемого блока:

void MakeJob() { Console.WriteLine("Подготовительные работы завершены"); } bool CheckDanger() { //проверка качества и возможности продолжения работ int low = rnd.Next(level,10); if ( low > 6) return(false); return(true); } void MakeLastJob() { Console.WriteLine("Все работы завершены успешно"); }

В классе Testing зададим метод, вызывающий метод Pattern:

public void TestPattern() { Excepts ex1 = new Excepts(); try { ex1.Pattern(); } catch (Exception e) { Console.WriteLine("исключительная ситуация при вызове Pattern"); Console.WriteLine(e.ToString()); } }

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

На рис. 23.6 показаны три варианта запуска метода TestPattern. В одном из них исключительной ситуации при вызове метода Pattern вообще не возникало, в другом - ситуация возникала, но коррекция обработчика исключения помогла и при повторе выполнения охраняемого блока в Pattern все прошло нормально. В третьем варианте метод Pattern не смог справиться с исключительной ситуацией, и она обрабатывалась в catch-блоке метода TestPattern.

Рис. 23.6.  Обработка исключительных ситуаций. Три случая

Схема обработки исключений в C#

Язык C# наследовал схему исключений языка С++, внеся в нее свои коррективы. Рассмотрим схему подробнее и начнем с синтаксиса конструкции try-catch-finally:
try {...} catch (T1 e1) {...} ... catch(Tk ek) {...} finally {...}
Всюду в тексте модуля, где синтаксически допускается использование блока, этот блок можно сделать охраняемым, добавив ключевое слово try. Вслед за try-блоком могут следовать catch-блоки, называемые блоками-обработчиками исключительных ситуаций, их может быть несколько, они могут и отсутствовать. Завершает эту последовательность finally-блок - блок финализации, который также может отсутствовать. Вся эта конструкция может быть вложенной - в состав try-блока может входить конструкция try-catch-finally.

Синтаксис класса

Ни одна из предыдущих лекций не обходилась без появления классов и обсуждения многих деталей, связанных с ними. Сейчас попробуем сделать некоторые уточнения, подвести итоги и с новых позиций взглянуть на уже знакомые вещи. Начнем с синтаксиса описания класса:
[атрибуты][модификаторы]class имя_класса[:список_родителей] {тело_класса}
Атрибутам будет посвящена отдельная лекция. Возможными модификаторами в объявлении класса могут быть модификаторы new, abstract, sealed, о которых подробно будет говориться при рассмотрении наследования, и четыре модификатора доступа, два из которых - private и protected - могут быть заданы только для вложенных классов. Обычно класс имеет атрибут доступа public, являющийся значением по умолчанию. Так что в простых случаях объявление класса выглядит так:
public class Rational {тело_класса}
В теле класса могут быть объявлены:

• константы;
• поля;
• конструкторы и деструкторы;
• методы;
• события;
• делегаты;
• классы (структуры, интерфейсы, перечисления).

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

Синтаксис объявления

Общий синтаксис объявления сущностей в C# похож на синтаксис объявления в C++, хотя и имеет ряд отличий. Вот какова общая структура объявления:
[<атрибуты>] [<модификаторы>] <тип> <объявители>;
Об атрибутах - этой новинке языка C# - уже шла речь, о них будем говорить и в последующих лекциях курса. Модификаторы будут появляться по мере необходимости. При объявлении переменных чаще всего задаются модификаторы доступа - public, private и другие. Если атрибуты и модификаторы могут и не указываться в объявлении, то задание типа необходимо всегда. Ограничимся пока рассмотрением уже изученных встроенных типов. Когда в роли типа выступают имена типов из таблицы 3.1, это означает, что объявляются простые скалярные переменные. Структурные типы - массивы, перечисления, структуры и другие пользовательские типы - будут изучаться в последующих лекциях.
При объявлении простых переменных указывается их тип и список объявителей, где объявитель - это имя или имя с инициализацией. Список объявителей позволяет в одном объявлении задать несколько переменных одного типа. Если объявитель задается именем переменной, то имеет место объявление с отложенной инициализацией. Хороший стиль программирования предполагает задание инициализации переменной в момент ее объявления. Инициализацию можно осуществлять двояко - обычным присваиванием или в объектной манере. Во втором случае для переменной используется конструкция new и вызывается конструктор по умолчанию. Процедура SimpleVars класса Testing иллюстрирует различные способы объявления переменных и простейшие вычисления над ними:
public void SimpleVars() { //Объявления локальных переменных int x, s; //без инициализации int y =0, u = 77; //обычный способ инициализации //допустимая инициализация float w1=0f, w2 = 5.5f, w3 =w1+ w2 + 125.25f; //допустимая инициализация в объектном стиле int z= new int(); //Недопустимая инициализация. //Конструктор с параметрами не определен //int v = new int(77); x=u+y; //теперь x инициализирована if(x> 5) s = 4; for (x=1; x<5; x++)s=5; //Инициализация в if и for не рассматривается, //поэтому s считается неинициализированной переменной //Ошибка компиляции:использование неинициализированной переменной //Console.WriteLine("s= {0}",s); } //SimpleVars



В первой строке объявляются переменные x и s с отложенной инициализацией. Заметьте (и это важно!), что всякая попытка использовать еще не инициализированную переменную в правых частях операторов присваивания, в вызовах функций, вообще в вычислениях приводит к ошибке уже на этапе компиляции.
Последующие объявления переменных эквивалентны по сути, но демонстрируют два стиля инициализации - обычный и объектный. Обычная форма инициализации предпочтительнее не только в силу своей естественности, но она и более эффективна, поскольку в этом случае инициализирующее выражение может быть достаточно сложным, с переменными и функциями. На практике объектный стиль для скалярных переменных используется редко. Вместе с тем полезно понимать, что объявление с инициализацией int y =0 можно рассматривать как создание нового объекта (new) и вызова для него конструктора по умолчанию. При инициализации в объектной форме может быть вызван только конструктор по умолчанию, другие конструкторы с параметрами для встроенных типов не определены. В примере закомментировано объявление переменной v с инициализацией в объектном стиле, приводящее к ошибке, где делается попытка дать переменной значение, передавая его конструктору в качестве параметра.
Откладывать инициализацию не стоит, как показывает пример с переменной s, объявленной с отложенной инициализацией. В вычислениях она дважды получает значение: один раз в операторе if, другой - в операторе цикла for. Тем не менее, при компиляции возникнет ошибка, утверждающая, что в процедуре WriteLine делается попытка использовать неинициализированную переменную s. Связано это с тем, что для операторов if и for на этапе компиляции не вычисляются условия, зависящие от переменных. Поэтому компилятор предполагает худшее - условия ложны, инициализация s в этих операторах не происходит. А за инициализацией наш компилятор следит строго, ты так и знай!

Синтаксис ограничений

Уточним некоторые синтаксические правила записи ограничений. Если задан универсальный класс с типовыми параметрами T1, ... Tn, то на каждый параметр могут быть наложены ограничения всех типов. Ограничения задаются предложением where, начинающимся соответствующим ключевым словом, после которого следует имя параметра, а затем через двоеточие - ограничения первого, второго или третьего типа, разделенных запятыми. Порядок их важен: если присутствует ограничение третьего типа, то оно записывается первым. Заметьте, предложения where для разных параметров отделяются лишь пробелами; как правило, они записываются на отдельных строчках. Предложения where записываются в конце заголовка класса после имени и списка его типовых параметров, после родительских классов и интерфейсов, если они заданы для универсального класса. Вот синтаксически корректные объявления классов с ограничением универсальности:
public class Father { } public class Base { public void M1() { } public void M2() { } } public class Child :Father where T1:Base,IEnumerable, new() where T2:struct,IComparable { }
Класс Child с ограниченной универсальностью к данным типа T1 имеет право применять методы M1 и M2 базового класса Base; так же, как и методы интерфейса IEnumerable, он может создавать объекты типа T1, используя конструктор по умолчанию. Фактический тип, подставляемый вместо формального типа T2, должен быть значимым, и объекты этого типа разрешается сравнивать между собой.

Синтаксис регулярных выражений

Регулярное выражение на C# задается строковой константой. Это может быть обычная или @-константа. Чаще всего, следует использовать именно @-константу. Дело в том, что символ "\" широко применяется в регулярных выражениях как для записи escape-последовательностей, так и в других ситуациях. Обычные константы в таких случаях будут выдавать синтаксическую ошибку, а @-константы не выдают ошибок и корректно интерпретируют запись регулярного выражения.
Синтаксис регулярного выражения простой формулой не описать, здесь используются набор разнообразных средств:

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

Конечно, регулярное выражение может быть совсем простым, например, строка "abc" задает образец поиска, так что при вызове соответствующего метода будут разыскиваться одно или все вхождения подстроки "abc" в искомую строку. Но могут существовать и очень сложно устроенные регулярные выражения. Приведу таблицу, (15.1) в которой дается интерпретация символов в соответствии с их делением на группы. Таблица не полна, в ней отражаются не все группы, а описание группы не содержит всех символов. Она позволяет дать общее представление о синтаксисе, которое будет дополнено большим числом примеров. За деталями придется обращаться к справочной системе, которая, к сожалению, далеко не идеальна для данного раздела.
Повторяю, данная таблица не полна. В ней не отражены, например, такие категории, как подстановки, обратные ссылки, утверждения.
Для приведенных категорий также не дан полный список возможных символов.

Таблица 15.1. Символы, используемые в регулярных выраженияхСимволИнтерпретацияКатегория: escape-последовательностиКатегория: подмножества (классы) символовКатегория: Операции (модификаторы)Категория: Группирование

\b	При использовании его в квадратных скобках соответствует символу "обратная косая черта" с кодом - \u0008
\t	Соответствует символу табуляции \u0009
\r	Соответствует символу возврата каретки \u000D
\n	Соответствует символу новой строки \u000A
\e	Соответствует символу escape \u001B
\040	Соответствует символу ASCII, заданному кодом до трех цифр в восьмеричной системе
\x20	Соответствует символу ASCII, заданному кодом из двух цифр в шестнадцатиричной системе
\u0020	Соответствует символу Unicode, заданному кодом из четырех цифр в шестнадцатиричной системе
.	Соответствует любому символу, за исключением символа конца строки
[aeiou]	Соответствует любому символу из множества, заданного в квадратных скобках
[^aeiou]	Отрицание. Соответствует любому символу, за исключением символов, заданных в квадратных скобках
[0-9a-fA-F]	Задание диапазона символов, упорядоченных по коду. Так, 0-9 задает любую цифру
\p{name}	Соответствует любому символу, заданному множеству с именем name, например, имя Ll задает множество букв латиницы в нижнем регистре. Поскольку все символы разбиты на подмножества, задаваемые категорией Unicode, то в качестве имени можно задавать имя категории
\P{name}	Отрицание. Большая буква всегда задает отрицание множества, заданного малой буквой
\w	Множество символов, используемых при задании идентификаторов - большие и малые символы латиницы, цифры и знак подчеркивания
\s	Соответствует символам белого пробела
\d	Соответствует любому символу из множества цифр
*	Итерация. Задает ноль или более соответствий; например, \w*
(abc)*.	Аналогично, {0,}
+	Положительная итерация. Задает одно или более соответствий; например, \w+ или (abc)+. Аналогично, {1,}
?	Задает ноль или одно соответствие; например, \w? или (abc)?. Аналогично, {0,1}
{n}	Задает в точности n соответствий; например, \w{2}
{n,}	Задает, по меньшей мере, n соответствий; например, (abc){2,}
{n,m}	Задает, по меньшей мере, n, но не более m соответствий; например, (abc){2,5}
(?)	При обнаружении соответствия выражению, заданному в круглых скобках, создается именованная группа, которой дается имя Name. Например, (? \d{7}). При обнаружении последовательности из семи цифр будет создана группа с именем tel
()	Круглые скобки разбивают регулярное выражение на группы. Для каждого подвыражения, заключенного в круглые скобки, создается группа, автоматически получающая номер. Номера следуют в обратном порядке, поэтому полному регулярному выражению соответствует группа с номером 0
(?imnsx)	Включает или выключает в группе любую из пяти возможных опций. Для выключения опции перед ней ставится знак минус. Например, (?i-s: ) включает опцию i, задающую нечувствительность к регистру, и выключает опцию s - статус single-line

Синтаксис структур

Синтаксис объявления структуры аналогичен синтаксису объявления класса:
[атрибуты][модификаторы]struct имя_структуры[:список_интерфейсов] {тело_структуры}
Какие изменения произошли в синтаксисе в сравнении с синтаксисом класса, описанным в лекции 16? Их немного. Перечислим их:

• ключевое слово class изменено на слово struct;
• список родителей, который для классов, наряду с именами интерфейсов, мог включать имя родительского класса, заменен списком интерфейсов. Для структур не может быть задан родитель (класс или структура). Заметьте, структура может наследовать интерфейсы;
• для структур неприменимы модификаторы abstract и sealed. Причиной является отсутствие механизма наследования.

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

• Самое серьезное ограничение связано с ограничением наследования. У структуры не может быть наследников. У структуры не может быть задан родительский класс или родительская структура. Конечно, всякая структура, как и любой класс в C#, является наследником класса Object, наследуя все свойства и методы этого класса. Структура может быть наследником одного или нескольких интерфейсов, реализуя методы этих интерфейсов.
• Второе серьезное ограничение связано с процессом создания объектов. Пусть T - структура, и дано объявление без инициализации - T x. Это объявление корректно, в результате будет создан объект без явного вызова операции new. Сущности x будет отведена память, и на этой памяти будет развернут объект. Но поля объекта не будут инициализированы и, следовательно, не будут доступны для использования в вычислениях. Об этих особенностях подробно говорилось при рассмотрении значимых типов. В этом отношении все, что верно для типа int, верно и для всех структур.
• Если при объявлении класса его поля можно инициализировать, что найдет отражение при работе конструктора класса, то поля структуры не могут быть инициализированы.
• Конструктор по умолчанию у структур имеется, при его вызове поля инициализируются значениями по умолчанию. Этот конструктор нельзя заменить, создав собственный конструктор без аргументов.
• В конструкторе нельзя вызывать методы класса. Поля структуры должны быть проинициализированы до вызова методов.

Синтаксис универсального класса

Объявить класс C# универсальным просто: для этого достаточно указать в объявлении класса, какие из используемых им типов являются параметрами. Список типовых параметров класса, заключенный в угловые скобки, добавляется к имени класса:
class MyClass {...}
Как и всякие формальные параметры, Ti являются именами (идентификаторами). В теле класса эти имена могут задавать типы некоторых полей класса, типы аргументов и возвращаемых значений методов класса. В некоторый момент (об этом скажем чуть позже) формальные имена типов будут заменены фактическими параметрами, представляющими уже конкретные типы - имена встроенных классов, классов библиотеки FCL, классов, определенных пользователем.
В C# универсальными могут быть как классы, так и все их частные случаи - интерфейсы, структуры, делегаты, события.

Система типов

Давайте рассмотрим, как устроена система типов в языке C#, но вначале для сравнения приведу классификацию типов в стандарте языка C++.
Стандарт языка C++ включает следующий набор фундаментальных типов.

1. Логический тип (bool).
2. Символьный тип (char).
3. Целые типы. Целые типы могут быть одного из трех размеров - short, int, long, сопровождаемые описателем signed или unsigned, который указывает, как интерпретируется значение, - со знаком или без оного.
4. Типы с плавающей точкой. Эти типы также могут быть одного из трех размеров - float, double, long double.
   Кроме того, в языке есть
   
5. Тип void, используемый для указания на отсутствие информации.
   Язык позволяет конструировать типы.
   
6. Указатели (например, int* - типизированный указатель на переменную типа int).
7. Ссылки (например, double& - типизированная ссылка на переменную типа double).
8. Массивы (например, char[] - массив элементов типа char).
   Язык позволяет конструировать пользовательские типы
   
9. Перечислимые типы (enum) для представления значений из конкретного множества.
10. Структуры (struct).
11. Классы.

Первые три вида типов называются интегральными или счетными. Значения их перечислимы и упорядочены. Целые типы и типы с плавающей точкой относятся к арифметическому типу. Типы подразделяются также на встроенные и типы, определенные пользователем.
Эта схема типов сохранена и в языке C#. Однако здесь на верхнем уровне используется и другая классификация, носящая для C# принципиальный характер. Согласно этой классификации все типы можно разделить на четыре категории:

1. Типы-значения (value), или значимые типы.
2. Ссылочные (reference).
3. Указатели (pointer).
4. Тип void.

Эта классификация основана на том, где и как хранятся значения типов. Для ссылочного типа значение задает ссылку на область памяти в "куче", где расположен соответствующий объект. Для значимого типа используется прямая адресация, значение хранит собственно данные, и память для них отводится, как правило, в стеке.
В отдельную категорию выделены указатели, что подчеркивает их особую роль в языке. Указатели имеют ограниченную область действия и могут использоваться только в небезопасных блоках, помеченных как unsafe.
Особый статус имеет и тип void, указывающий на отсутствие какого-либо значения.
В языке C# жестко определено, какие типы относятся к ссылочным, а какие - к значимым. К значимым типам относятся: логический, арифметический, структуры, перечисление. Массивы, строки и классы относятся к ссылочным типам. На первый взгляд, такая классификация может вызывать некоторое недоумение, почему это структуры, которые в C++ близки к классам, относятся к значимым типам, а массивы и строки - к ссылочным. Однако ничего удивительного здесь нет. В C# массивы рассматриваются как динамические, их размер может определяться на этапе вычислений, а не в момент трансляции. Строки в C# также рассматриваются как динамические переменные, длина которых может изменяться. Поэтому строки и массивы относятся к ссылочным типам, требующим распределения памяти в "куче".
Со структурами дело сложнее. Структуры C# представляют частный случай класса. Определив свой класс как структуру, программист получает возможность отнести класс к значимым типам, что иногда бывает крайне полезно. Замечу, что в хорошем объектном языке Eiffel программист может любой класс объявить развернутым (expanded), что эквивалентно отнесению к значимому типу. У программиста C# только благодаря структурам появляется возможность управлять отнесением класса к значимым или ссылочным типам. Правда, это неполноценное средство, поскольку на структуры накладываются дополнительные ограничения по сравнению с обычными классами.
Рассмотрим классификацию, согласно которой все типы делятся на встроенные и определенные пользователем. Все встроенные типы C# однозначно отображаются, а фактически совпадают с системными типами каркаса Net Framework, размещенными в пространстве имен System. Поэтому всюду, где можно использовать имя типа, например, - int, с тем же успехом можно использовать и имя System.Int32.

Замечание: Следует понимать тесную связь и идентичность встроенных типов языка C# и типов каркаса. Какими именами типов следует пользоваться в программных текстах - это спорный вопрос. Джеффри Рихтер в своей известной книге "Программирование на платформе Framework .Net" рекомендует использовать системные имена. Другие авторы считают, что следует пользоваться именами типов, принятыми в языке. Возможно, в модулях, предназначенных для межъязыкового взаимодействия, разумны системные имена, а в остальных случаях - имена конкретного языка программирования.

<


В заключение этого раздела приведу таблицу (3.1), содержащую описание всех встроенных типов языка C# и их основные характеристики.

Логический типИмя типаСистемный типЗначенияРазмерАрифметические целочисленные типыИмя типаСистемный типДиапазонРазмерАрифметический тип с плавающей точкойИмя типаСистемный типДиапазонТочностьАрифметический тип с фиксированной точкойИмя типаСистемный типДиапазонТочностьСимвольные типыИмя типаСистемный типДиапазонТочностьОбъектный типИмя типаСистемный типПримечание

Bool	System.Boolean	true, false	8 бит
Sbyte	System.SByte	-128 — 127	Знаковое, 8 Бит
Byte	System.Byte	0 — 255	Беззнаковое, 8 Бит
Short	System.Short	-32768 —32767	Знаковое, 16 Бит
Ushort	System.UShort	0 — 65535	Беззнаковое, 16 Бит
Int	System.Int32	?(-2*10^9 — 2*10^9)	Знаковое, 32 Бит
Uint	System.UInt32	?(0 — 4*10^9)	Беззнаковое, 32 Бит
Long	System.Int64	?(-9*10^18 — 9*10^18)	Знаковое, 64 Бит
Ulong	System.UInt64	?(0— 18*10^18)	Беззнаковое, 64 Бит
Float	System.Single	+1.5*10^-45 - +3.4*10^38	7 цифр
Double	System.Double	+5.0*10^-324 - +1.7*10^308	15-16 цифр
Decimal	System.Decimal	+1.0*10^-28 - +7.9*10^28	28-29 значащих цифр
Char	System.Char	U+0000 - U+ffff	16 бит Unicode символ
String	System.String	Строка из символов Unicode
Object	System.Object	Прародитель всех встроенных и пользовательских типов

Система встроенных типов языка C# не только содержит практически все встроенные типы (за исключением long double) стандарта языка C++, но и перекрывает его разумным образом. В частности тип string является встроенным в язык, что вполне естественно. В области совпадения сохранены имена типов, принятые в C++, что облегчает жизнь тем, кто привык работать на C++, но собирается по тем или иным причинам перейти на язык C#.

Событие Paint

Вызов метода DrawWeb добавлен еще и в обработчик события Paint:
protected override void OnPaint(System.Windows.Forms.PaintEventArgs e) { pen = SystemPens.ControlText; DrawWeb(); Debug.WriteLine(count++); }
Говоря о рисовании, нельзя не упомянуть о событии Paint. Оно возникает всякий раз, когда область, в которой происходило рисование, повреждена. Причины этого могут быть разные - пользователь свернул форму, изменил ее размеры, произошло перекрытие другой формой, был вызван метод Invalidate - во всех этих случаях требуется перерисовать область. Тогда-то и возникает событие Paint, в задачу его обработчика входит перерисовка поврежденной области. Первый раз событие Paint возникает при открытии формы. Переменная count, введенная нами, позволяет в режиме отладки подсчитывать число вызовов события Paint.
Событие Paint подключают обычно не так, как это делалось, например, для события MouseMove. Вместо этого переопределяют родительский метод OnPaint. (Как переопределяются родительские методы группы On, занимающиеся обработкой событий, другие методы классов родителей и базовых интерфейсов? В режиме проектирования в окне классов, отражающем структуру класса, нужно выбрать соответствующий класс (в нашем случае класс формы BezierWeb), раскрыть узел BasesAndInterfaces этого класса и из появившегося списка всех наследованных свойств и методов выбрать нужный (в нашем случае метод OnPaint). В результате появится заготовка для переопределения метода.)
В данном контексте перерисовка сводится, как это обычно делается, к вызову метода, выполняющего рисование. Для повышения эффективности можно анализировать поврежденную область и выполнять рисование только в ее пределах.
Закончим на этом с рисованием пером и перейдем к рассмотрению рисования кистью.

У CLR есть свое видение

У CLR есть свое видение того, что представляет собой тип. Есть формальное описание общей системы типов CTS - Common Type System. В соответствии с этим описанием, каждый тип, помимо полей, методов и свойств, может содержать и события. При возникновении событий в процессе работы с тем или иным объектом данного типа посылаются сообщения, которые могут получать другие объекты. Механизм обмена сообщениями основан на делегатах - функциональном типе. Надо ли говорить, что в язык C# встроен механизм событий, полностью согласованный с возможностями CLR. Мы подробно изучим все эти механизмы, рассматривая их на уровне языка.
Исполнительная среда CLR обладает мощными динамическими механизмами - сборки мусора, динамического связывания, обработки исключительных ситуаций и событий. Все эти механизмы и их реализация в CLR созданы на основании практики существующих языков программирования. Но уже созданная исполнительная среда, в свою очередь, влияет на языки, ориентированные на использование CLR. Поскольку язык C# создавался одновременно с созданием CLR, то, естественно, он стал языком, наиболее согласованным с исполнительной средой, и средства языка напрямую отображаются в средства исполнительной среды.

Сортировка и поиск. Статические методы класса Array

Статические методы класса Array позволяют решать самые разнообразные задачи:

1. Copy - позволяет копировать весь массив или его часть в другой массив.
2. IndexOf, LastIndexOf - определяют индексы первого и последнего вхождения образца в массив, возвращая -1, если такового вхождения не обнаружено.
3. Reverse - выполняет обращение массива, переставляя элементы в обратном порядке.
4. Sort - осуществляет сортировку массива.
5. BinarySearch - определяет индекс первого вхождения образца в отсортированный массив, используя алгоритм двоичного поиска.

Все методы перегружены и имеют ряд модификаций. Большинство из этих методов применимо только к одномерным массивам. Приведу примеры различных операций, доступных при работе с массивами, благодаря наследованию от класса Array:
public void TestCollection() { //операции над массивами int nc = 7; int[] col1 = new int[nc], col2 = new int[nc]; double[] col3 = new double[nc]; int[,] col4 = new int[2,2]; Arrs.CreateCollection(col1); Arrs.PrintCollection("col1",col1); Arrs.CreateCollection(col2); Arrs.PrintCollection("col2",col2); Arrs.CreateCollection(col3); Arrs.PrintCollection("col3",col3); Arrs.CreateTwoDimAr(col4); Arrs.PrintCollection("col4",col4); //сортировка, поиск, копирование // поиск элемента int first = Array.IndexOf(col1, 2); int last = Array.LastIndexOf(col1,2); if (first == -1) Console.WriteLine("Нет вхождений 2 в массив col1"); else if (first ==last) Console.WriteLine("Одно вхождение 2 в массив col1"); else Console.WriteLine("Несколько вхождений 2 в массив col1"); //first = Array.IndexOf(col4, 4); //только одномерный массив Array.Reverse(col1); Console.WriteLine("Обращение массива col1:"); Arrs.PrintCollection("col1",col1); //Копирование Array.Copy(col1, col3, col1.Length); Console.WriteLine(" Массив col3 после копирования массива col1:"); Arrs.PrintCollection("col3",col3); Array.Copy(col1,1,col2,1,2); Console.WriteLine("копирование двух элементов col1 в col2:"); Arrs.PrintCollection("col1",col1); Arrs.PrintCollection("col2",col2); //быстрая сортировка Хоара Array.Sort(col1); Console.WriteLine("Отсортированный массив col1:"); Arrs.PrintCollection("col1",col1); first = Array.BinarySearch(col1, 2); Console.WriteLine("Индекс вхождения 2 в col1: {0}",first); //Создание экземпляра (массива) Array my2Dar = Array.CreateInstance(typeof(double), 2,3); Arrs.PrintCollection("my2Dar",my2Dar); //клонирование my2Dar = (Array)col4.Clone(); Console.WriteLine("Массив my2Dar после клонирования col4:"); Arrs.PrintCollection("my2Dar",my2Dar); //копирование CopyTo col1.CopyTo(col2,0); Console.WriteLine("Массив col2 после копирования col1:"); Arrs.PrintCollection("col2",col2); }



В этой процедуре продемонстрированы вызовы различных статических методов класса Array. Для метода Copy показан вызов двух реализаций этого метода, когда копируется весь массив и часть массива. Закомментированный оператор вызова метода IndexOf напоминает о невозможности использования методов поиска при работе с многомерными массивами. Приведу результаты вывода, порожденные этим кодом.

Рис. 12.3.  Результаты применения статических методов класса Array

Таблица 12.1. Свойства класса ArrayСвойствоРодительОписание

IsFixedSize	Интерфейс IList	True, если массив статический
IsReadOnly	Интерфейс IList	Для всех массивов имеет значение false
IsSynchronized	Интерфейс ICollection	True или False, в зависимости от того, установлена ли синхронизация доступа для массива
SyncRoot	Интерфейс ICollection	Собственный метод синхронизации доступа к массиву. При работе с массивом его можно закрыть на время обработки, что запрещает его модификацию каким-либо потоком: Array myCol = new int[]; lock( myCol.SyncRoot ) { foreach ( Object item in myCol ) { // безопасная обработка массива }
Length		Число элементов массива
Rank		Размерность массива

Таблица 12.2. Статические методы класса ArrayМетодОписание

BinarySearch	Двоичный поиск. Описание и примеры даны в тексте
Clear	Выполняет начальную инициализацию элементов. В зависимости от типа элементов устанавливает значение 0 для арифметического типа, false - для логического типа, Null для ссылок, "" - для строк.
Copy	Копирование части или всего массива в другой массив. Описание и примеры даны в тексте
CreateInstance	Класс Array, в отличие от многих классов, может создавать свои экземпляры не только с помощью конструктора new, но и при вызове метода CreateInstance: Array my2Dar = Array.CreateInstance(typeof(double), 2,2)
IndexOf	Индекс первого вхождения образца в массив. Описание и примеры даны в тексте
LastIndexOf	Индекс последнего вхождения образца в массив. Описание и примеры даны в тексте
Reverse	Обращение одномерного массива. Описание и примеры даны в тексте
Sort	Сортировка массива. Описание и примеры даны в тексте

Создание C#

Язык C# является наиболее известной новинкой в области создания языков программирования. В отличие от 60-х годов XX века - периода бурного языкотворчества - в нынешнее время языки создаются крайне редко. За последние 15 лет большое влияние на теорию и практику программирования оказали лишь два языка: Eiffel, лучший, по моему мнению, объектно-ориентированный язык, и Java, ставший популярным во многом благодаря технологии его использования в Интернете и появления такого понятия как виртуальная Java-машина. Чтобы новый язык получил признание, он должен действительно обладать принципиально новыми качествами. Языку C# повезло с родителями. Явившись на свет в недрах Microsoft, будучи наследником C++, он с первых своих шагов получил мощную поддержку. Однако этого явно недостаточно для настоящего признания достоинств языка. Попробуем разобраться, имеет ли он большое будущее?
Создателем языка является сотрудник Microsoft Андреас Хейлсберг. Он стал известным в мире программистов задолго до того, как пришел в Microsoft. Хейлсберг входил в число ведущих разработчиков одной из самых популярных сред разработки - Delphi. В Microsoft он участвовал в создании версии Java - J++, так что опыта в написании языков и сред программирования ему не занимать. Как отмечал сам Андреас Хейлсберг, C# создавался как язык компонентного программирования, и в этом одно из главных достоинств языка, направленное на возможность повторного использования созданных компонентов. Из других объективных факторов отметим следующие:

• C# создавался параллельно с каркасом Framework .Net и в полной мере учитывает все его возможности - как FCL, так и CLR;
• C# является полностью объектно-ориентированным языком, где даже типы, встроенные в язык, представлены классами;
• C# является мощным объектным языком с возможностями наследования и универсализации;
• C# является наследником языков C/C++, сохраняя лучшие черты этих популярных языков программирования. Общий с этими языками синтаксис, знакомые операторы языка облегчают переход программистов от С++ к C#;
• сохранив основные черты своего великого родителя, язык стал проще и надежнее. Простота и надежность, главным образом, связаны с тем, что на C# хотя и допускаются, но не поощряются такие опасные свойства С++ как указатели, адресация, разыменование, адресная арифметика;
• благодаря каркасу Framework .Net, ставшему надстройкой над операционной системой, программисты C# получают те же преимущества работы с виртуальной машиной, что и программисты Java. Эффективность кода даже повышается, поскольку исполнительная среда CLR представляет собой компилятор промежуточного языка, в то время как виртуальная Java-машина является интерпретатором байт-кода;
• мощная библиотека каркаса поддерживает удобство построения различных типов приложений на C#, позволяя легко строить Web-службы, другие виды компонентов, достаточно просто сохранять и получать информацию из базы данных и других хранилищ данных;
• реализация, сочетающая построение надежного и эффективного кода, является немаловажным фактором, способствующим успеху C#.

Создание инструментальной панели с командными кнопками

Панель с командными кнопками дополняет меню. Панель устроена проще, поскольку здесь нет иерархии. На панели располагаются кнопки, щелчок по каждой из которых запускает на выполнение соответствующую команду, заданную обработчиком события Click. Как правило, команды, задаваемые кнопками панелей, соответствуют наиболее часто используемым командам меню и являются альтернативным способом их запуска. Но это не обязательно, и команды, задаваемые кнопками панели, могут не пересекаться с командами меню.
Роль контейнерного класса для командных кнопок играет класс, определяющий панель - ToolBar. Командные кнопки - элементы, располагаемые на панели, - задаются классом ToolBarButton.
Давайте спроектируем панель с тремя кнопками, задающими команды Open, Save и Color, повторяющие команды меню. Принято кнопки делать красивыми, вынося на них рисунки, ассоциированные с командами. Поэтому посадим на форму два элемента управления - ImageList, хранящий рисунки, связываемые с кнопками, и ToolBar - панель, на которой будут располагаться кнопки. В коллекцию объекта imageList1 добавим три подходящие картинки, свяжем этот объект со свойством ImageList объекта toolBar1. Затем добавим три кнопки в коллекцию объекта toolBar1 и зададим для них нужные свойства - текст, появляющийся на кнопке, подсказку к кнопке и индекс элемента из списка ImageList. На рис. 24.11 показан процесс задания кнопки и установки ее свойств.

Рис. 24.11.  Проектирование панели с командными кнопками
Проанализируем теперь созданный дизайнером программный код. Как всегда начнем с полей класса, хранящих созданные в процессе проектирования элементы:
private System.Windows.Forms.ToolBar toolBar1; private System.Windows.Forms.ImageList imageList1; private System.Windows.Forms.ToolBarButton toolBarButton1; private System.Windows.Forms.ToolBarButton toolBarButton2; private System.Windows.Forms.ToolBarButton toolBarButton3;
В методе InitializeComponent эти объекты создаются и инициализируются:
this.toolBar1 = new System.Windows.Forms.ToolBar(); this.imageList1 = new System.Windows.Forms.ImageList(this.components); this.toolBarButton1 = new System.Windows.Forms.ToolBarButton(); this.toolBarButton2 = new System.Windows.Forms.ToolBarButton(); this.toolBarButton3 = new System.Windows.Forms.ToolBarButton(); ... // toolBar1 this.toolBar1.Buttons.AddRange(new System.Windows.Forms.ToolBarButton[] {this.toolBarButton1, this.toolBarButton2,this.toolBarButton3}); this.toolBar1.DropDownArrows = true; this.toolBar1.ImageList = this.imageList1; this.toolBar1.Name = "toolBar1"; this.toolBar1.ShowToolTips = true; this.toolBar1.Size = new System.Drawing.Size(432, 42); this.toolBar1.TabIndex = 1; this.toolBar1.ButtonClick += new System.Windows.Forms.ToolBarButtonClickEventHandler( this.toolBar1_ButtonClick); // toolBarButton1 this.toolBarButton1.ImageIndex = 0; this.toolBarButton1.Text = "OpenFile"; this.toolBarButton1.ToolTipText = "Диалоговое окно открытия файла"; ...



Этот текст должен быть понятен без комментариев, а вот об обработчике события Click стоит сказать несколько слов. Во-первых, событие Click не связывается с каждой командной кнопкой, расположенной на панели, - оно связано с самой панелью. Так что в обработчике происходит разбор случаев с анализом того, какая кнопка была нажата. Вот как это делается:

private void toolBar1_ButtonClick(object sender, System.Windows.Forms.ToolBarButtonClickEventArgs e) { int buttonNumber = toolBar1.Buttons.IndexOf(e.Button); switch (buttonNumber) { case 0: OpenFileDialog openFileDialog1 = new OpenFileDialog(); openFileDialog1.ShowDialog(); //код, показывающий, что делать с открытым файлом textBox1.Text = "Открытие Файла!"; break; case 1: SaveFileDialog saveFileDialog1 = new SaveFileDialog(); saveFileDialog1.ShowDialog(); //код, анализирующий результат операции сохранения файла textBox1.Text = "Сохранение Файла!"; break; default: ColorDialog colorDialog1 = new ColorDialog(); if (colorDialog1.ShowDialog()== DialogResult.OK) this.textBox1.BackColor =colorDialog1.Color; break; } }

В заключение взгляните на спроектированную форму с меню и панелью с командными кнопками.

Рис. 24.12.  Форма с меню и инструментальной панелью

Создание меню в режиме проектирования

Для построения в режиме проектирования главного меню и связанной с ним структуры достаточно перетащить на форму элемент управления, называемый MainMenu. (В Visual Studio 2005 элемент управления для создания меню называется MenuStrip, а для создания инструментальных панелей - ToolStrip.)
После перетаскивания метка с изображением этого элемента управления появляется ниже формы, а на форме появляется элемент меню с информационным полем, в котором можно задать название пункта меню, и двумя указателями на правого брата и старшего сына, позволяющими перейти к следующему пункту меню того же уровня или опуститься на нижний уровень. Технология создания меню вручную интуитивно ясна и не вызывает обычно никаких проблем. На рис. 24.9 показан процесс создания меню.

Рис. 24.9.  Создание меню в режиме проектирования
Рассмотрим пример, в котором главное меню содержит 3 пункта - File, Figure, Color. Меню File содержит две команды - Open и Save. Меню Figure состоит из двух пунктов - Closed и Unclosed, первый из которых содержит две команды - Circle и Rectangle, второй содержит одну команду - Line. Пункт Color главного меню в данном случае является командой и не содержит выпадающего меню. Полагаю, что для демонстрации возможностей этой структуры вполне достаточно. Создать ее вручную - минутное дело. Содержательный пример появится в следующей заключительной главе, а в этой ограничимся демонстрационной версией.
Посадим на форму еще один элемент управления - текстовое окно - и свяжем с командами меню обработчики события Click. Для команд Open, Save и Color, имеющих общепринятый смысл, обработчики будут открывать соответствующие этим командам диалоговые окна, позволяющие в диалоге с пользователем открыть файл, сохранить файл и выбрать подходящий цвет. Диалоговые окна - это важный элемент организации интерфейса, который, пользуясь случаем, хочется продемонстрировать.
Связывание команды меню с обработчиком события в режиме проектирования выполняется стандартным образом - выделяется соответствующая команда меню, затем в окне Properties щелкается значок молнии и из списка событий выбирается событие Click, после чего открывается заготовка обработчика события, заполняемая нужным кодом.
Вот как выглядят обработчики события Click команд Open, Save и Color:
private void menuItem4_Click(object sender, System.EventArgs e) { OpenFileDialog openFileDialog1 = new OpenFileDialog(); openFileDialog1.ShowDialog(); //код, показывающий, что делать с открытым файлом textBox1.Text = "Открытие Файла!"; } private void menuItem10_Click(object sender, System.EventArgs e) { SaveFileDialog saveFileDialog1 = new SaveFileDialog(); saveFileDialog1.ShowDialog(); //код, анализирующий результат операции сохранения файла textBox1.Text = "Сохранение Файла!"; } private void menuItem3_Click(object sender, System.EventArgs e) { ColorDialog colorDialog1 = new ColorDialog(); if (colorDialog1.ShowDialog()== DialogResult.OK) this.textBox1.BackColor =colorDialog1.Color; }



На рис. 24. 10 показано диалоговое окно для выбора цвета, открытое при выборе команды Color.

Рис. 24.10.  Диалоговое окно ColorDialog, позволяющее выбрать цвет

Для полноты картины зададим обработчики событий для команд меню Circle, Rectangle, Line, не выполняющие пока содержательной работы, а лишь информирующие о намерениях:

private void menuItem7_Click(object sender, System.EventArgs e) { textBox1.Text = "Рисование круга!"; } private void menuItem8_Click(object sender, System.EventArgs e) { textBox1.Text = "Рисование прямоугольника!"; } private void menuItem9_Click(object sender, System.EventArgs e) { textBox1.Text = "Рисование прямой!"; }

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

Создание надежного кода

Большинство вопросов, затрагиваемых в этой лекции, в том числе и проблемы создания надежного кода, заслуживают отдельного и глубокого рассмотрения. К сожалению, придется ограничиться лишь высказыванием ряда тезисов.
Для повышения надежности нужно уменьшить сложность системы, и главное в этом процессе - это повторное использование. В идеале большая часть системы должна быть собрана из уже готовых компонентов. Объектная технология проектирования вносит свой вклад в повышение надежности кода. Наследование и универсализация позволяют, не изменяя уже существующие классы, создать новые классы, новые типы данных, придающие проектируемой системе новые свойства при минимальных добавлениях нового кода. Статический контроль типов позволяет выявить многие ошибки еще на этапе компиляции. Динамическое связывание и полиморфизм позволяют автоматически включать объекты классов-потомков в уже существующие схемы работы - методы родителя могут вызывать методы потомков, ничего не зная о появлении этих новых потомков. Автоматическая сборка мусора позволяет снять с разработчика обязанности управления освобождением памяти и предотвратить появление крайне неприятных и опасных ошибок, связанных с некорректным удалением объектов.
Крайне важную роль в создании надежного кода играют спецификации методов класса, класса в целом, системы классов. Спецификации являются частью документации, встроенной в проект, и вообще важной его частью. Их существование облегчает не только создание корректного кода, соответствующего спецификации, но и создание системы тестов, проверяющих корректность кода. Нужно сказать, что существуют специальные инструментальные средства, поддерживающие автоматическое создание тестов на основе спецификаций. Незаменима роль спецификаций на этапе сопровождения и повторного использования компонентов. Невозможно повторно использовать компонент, если у него нет ясной и полной спецификации.

Специальные случаи присваивания

В языке C++ для двух частных случаев присваивания предложен отдельный синтаксис. Язык C# наследовал эти полезные свойства. Для присваиваний вида "x=x+1", в которых переменная увеличивается или уменьшается на единицу, используются специальные префиксные и постфиксные операции "++" и "--". Другой важный частный случай - это присваивания вида:
X = X (expression)
Для таких присваиваний используется краткая форма записи:
X = expression
В качестве операции разрешается использовать арифметические, логические (побитовые) операции и операции сдвига языка C#. Семантика такого присваивания достаточно очевидна, и я ограничусь простым примером:
x += u+v; y /=(u-v); b &= (x Однако и здесь есть один подводный камень, когда x= x+a не эквивалентно x +=a. Рассмотрим следующий пример:
byte b3 = 21; b3 +=1; //Это допустимо //b3 = b3+1; //А это недопустимо:результат типа int
Закомментированный оператор приведет к ошибке компиляции, поскольку правая часть имеет тип int, а неявное преобразование к типу byte отсутствует. Следует понимать, что преимущество первой формы записи - только кажущееся: если при инициализации переменная b получит допустимое значение 255, то следующий оператор присваивания в краткой форме не выдаст ошибки, но даст неверный результат, а это - самое худшее, что может случиться в программе. Так что надежнее пользоваться полной формой записи присваивания, не экономя на паре символов.

Список формальных аргументов

Как уже отмечалось, список формальных аргументов метода может быть пустым, и это довольно типичная ситуация для методов класса. Список может содержать фиксированное число аргументов, разделяемых символом запятой.
Рассмотрим теперь синтаксис объявления формального аргумента:
[ref|out|params]тип_аргумента имя_аргумента
Обязательным является указание типа и имени аргумента. Заметьте, никаких ограничений на тип аргумента не накладывается. Он может быть любым скалярным типом, массивом, классом, структурой, интерфейсом, перечислением, функциональным типом.
Несмотря на фиксированное число формальных аргументов, есть возможность при вызове метода передавать ему произвольное число фактических аргументов. Для реализации этой возможности в списке формальных аргументов необходимо задать ключевое слово params. Оно задается один раз и указывается только для последнего аргумента списка, объявляемого как массив произвольного типа. При вызове метода этому формальному аргументу соответствует произвольное число фактических аргументов.
Содержательно, все аргументы метода разделяются на три группы: входные, выходные и обновляемые. Аргументы первой группы передают информацию методу, их значения в теле метода только читаются. Аргументы второй группы представляют собой результаты метода, они получают значения в ходе работы метода. Аргументы третьей группы выполняют обе функции. Их значения используются в ходе вычислений и обновляются в результате работы метода. Выходные аргументы всегда должны сопровождаться ключевым словом out, обновляемые - ref. Что же касается входных аргументов, то, как правило, они задаются без ключевого слова, хотя иногда их полезно объявлять с параметром ref, о чем подробнее скажу чуть позже. Заметьте, если аргумент объявлен как выходной с ключевым словом out, то в теле метода обязательно должен присутствовать оператор присваивания, задающий значение этому аргументу. В противном случае возникает ошибка еще на этапе компиляции.
Для иллюстрации давайте рассмотрим группу методов класса Testing из проекта ProcAndFun, сопровождающего эту лекцию:
///

/// Группа перегруженных методов A() /// первый аргумент представляет сумму кубов /// произвольного числа оставшихся аргументов /// Аргументы могут быть разного типа. ///

void A(out long p2, int p1) { p2 =(long) Math.Pow(p1,3); Console.WriteLine("Метод A-1"); } void A(out long p2, params int[] p) { p2=0; for(int i=0; i /// Функция с побочным эффектом ///

/// Увеличивается на 1 /// значение a на входе int f(ref int a) { return(a++); }



Четыре перегруженных метода с именем A и метод f будут использоваться при объяснении перегрузки и побочного эффекта. Сейчас проанализируем только их заголовки. Все методы закрыты, поскольку объявлены без модификатора доступа. Перегруженные методы с именем A являются процедурами, метод f - функцией. Все четыре перегруженных метода имеют разную сигнатуру. Хотя имена и число аргументов у всех методов одинаковы, но типы и ключевые слова, предшествующие аргументам, различны. Первый аргумент у всех четырех перегруженных методов - выходной и сопровождается ключевым словом out, в теле метода этому аргументу присваивается значение. Аргумент функции f - обновляемый, он снабжен ключевым словом ref, в теле функции используется его значение для получения результата функции, но и само значение аргумента изменяется в теле функции. Два метода из группы перегруженных методов используют ключевое слово params для своего последнего аргумента. Позже мы увидим, что при вызове этих методов указанному аргументу будет соответствовать несколько фактических аргументов, число которых может быть произвольным.

Список с курсором. Динамические структуры данных

Добавим в проект классы, задающие динамические структуры данных. Конечно, можно было бы воспользоваться стандартными... Но для обучения крайне полезно уметь создавать собственные классы, задающие такие структуры данных. Список с курсором - один из важнейших образцов подобных классов:
using System; namespace Shapes { ///

/// Класс TwoWayList(G) описывает двусвязный список с /// курсором. Элементами списка являются объекты /// TwoLinkable, хранящие, помимо указателей на двух /// преемников, объекты типа G.Курсор будет определять /// текущий (активный) элемент списка. Класс будет /// определять симметричные операции по отношению к /// курсору. /// Конструкторы: /// Конструктор без параметров будет создавать пустой /// список /// Запросы: /// empty: require: true; возвращает true для пустого списка /// item: require: not empty(); возвращает активный элемент типа G; /// require: true; возвращает число элементов списка; /// count: count in[0,n] (count == 0) eqviv empty(); /// index: require: not empty(); возвращает индекс активного элемента. /// search_res: require: true; возвращает true, если последний поиск был успешным. /// Команды: /// put_left(elem): require: true; /// ensure: добавить новый элемент (elem) слева от курсора; /// put_right(elem): require: true; /// ensure: добавить новый элемент (elem) справа от курсора; /// remove: require: not empty(); /// ensure: удалить активный элемент; /// особо обрабатывается удаление последнего и единственного элементов /// операции с курсором: /// start: require: true; /// ensure: сделать активным первый элемент; /// finish: require: true; /// ensure: сделать активным последний элемент; /// go_prev: require: not (index = 1); /// ensure: сделать активным предыдущий элемент; /// go_next: require: not (index = count); /// ensure: сделать активным последующий элемент; /// go_i(i): require: (i in [1, count]); /// ensure: сделать активным элемент с индексом i; /// операции поиска: /// search_prev(elem): require: not (index = 1); /// ensure: сделать активным первый элемент elem слева от курсора; /// Успех или неуспех поиска сохранять в булевской /// переменной search_res /// search_next: require: not (index = count); /// ensure: сделать активным первый элемент elem справа от курсора; /// успех или неуспех поиска сохранять в булевской переменной search_res ///

public class TwoWayList { public TwoWayList() { first = cursor = last = null; count = index = 0; search_res = false; }//конструктор ///

/// first, cursor, last - ссылки на первый, /// активный и последний элементы списка /// Запросы count, index search_res также /// реализуются атрибутами. /// Запросы empty, item реализуются функциями ///

protected TwoLinkable first, cursor, last; protected int count, index; protected bool search_res; //доступ на чтение к закрытым свойствам; public int Count { get { return(count); } } public int Index { get { return(index); } } public bool Search_res { get { return(search_res); } } ///

/// require: true; возвращает true для непустого списка ///

/// public bool empty() { return(first == null); }//empty ///

/// require: not empty(); возвращает активный /// элемент типа G; ///

/// public Figure item() { return(cursor.Item); }//item ///

/// require: true; /// ensure: добавить новый элемент (elem) слева /// от курсора; ///

/// Тип Figure играет роль /// родового типа G /// хранимого элемента elem public void put_left(Figure elem) { TwoLinkable newitem = new TwoLinkable(); newitem.Item = elem; newitem.Next = cursor; if (empty()) //список пуст { first = cursor = last = newitem; index =1; count = 1; } else { if (index == 1) first =newitem; else cursor.Prev.Next = newitem; newitem.Prev = cursor.Prev; cursor.Prev = newitem; count++; index++; } }//put_right ///

/// require: true; /// ensure: добавить новый элемент (elem) справа /// от курсора; ///

/// Тип Figure играет роль /// родового типа G /// хранимого элемента elem public void put_right(Figure elem) { TwoLinkable newitem = new TwoLinkable(); newitem.Item = elem; newitem.Prev = cursor; if (empty()) //список пуст { first = cursor = last = newitem; index =1; count = 1; } else { if (index == count) last =newitem; else cursor.Next.Prev = newitem;



newitem.Next = cursor.Next; cursor.Next = newitem; count++; } }//put_right public void remove() { if(count == 1) { first = last = cursor = null; index=0; } else if(index==1) { first = cursor.Next; cursor.Prev = null; cursor = cursor.Next; } else if(index == count) { last = cursor.Prev; cursor.Next = null; cursor = cursor.Prev; index--; } else { cursor.Prev.Next = cursor.Next; cursor.Next.Prev = cursor.Prev; cursor = cursor.Next; } count--; }//remove /// операции с курсором: ///

/// start: require: true; /// ensure: сделать активным первый элемент; ///

public void start() { cursor = first; index = 1; }//start ///

/// finish: require: true; /// ensure: сделать активным последний элемент; ///

public void finish() { cursor = last; index = count; }//finish ///

/// go_prev: require: not (index = 1); /// ensure: сделать активным предыдущий элемент; ///

public void go_prev() { cursor = cursor.Prev; index--; }// go_prev ///

/// go_next: require: not (index = count); /// ensure: сделать активным последующий элемент; ///

public void go_next() { cursor = cursor.Next; index++; }// go_next ///

/// go_i(i): require: (i in [1, count]); /// ensure: сделать активным элемент с индексом i; ///

/// public void go_i(int i) { if(i >index) while (i>index) { cursor = cursor.Next; index++; } else if(i /// search_prev(elem): require: not (index = 1); /// ensure: сделать активным первый элемент elem /// слева от курсора; ///

/// искомый элемент public virtual void search_prev(Figure elem) { bool found = false; while (!found && (index !=1)) { cursor = cursor.Prev; index--; found = (elem == item()); } search_res = found; }// search_prev ///

/// успех или неуспех поиска сохранять в булевской /// переменной search_res /// search_next: require: not (index = count); /// ensure: сделать активным первый элемент elem /// справа от курсора; /// успех или неуспех поиска сохранять в булевской /// переменной search_res ///

/// public virtual void search_next(Figure elem) { bool found = false; while (!found && (index !=count)) { cursor = cursor.Next; index++; found = (elem == item()); } search_res = found; }//search_next } }

Заметьте, класс подробно документирован. Для методов класса указываются предусловия и постусловия. Обратите внимание, в соответствии с принципами контрактного программирования клиент класса, прежде чем вызвать метод, должен проверить выполнимость предусловия, что повышает корректность работы системы в целом. Именно так и будет реализован вызов этих методов в классе формы, где осуществляется работа со списком.

Список с возможностью поиска элементов по ключу

Ключевые идеи ограниченной универсальности, надеюсь, понятны. Давайте теперь рассмотрим пример построения подобного класса, где можно будет увидеть все детали. Возьмем классическую и саму по себе интересную задачу построения списка с курсором. Как и всякий контейнер данных, список следует сделать универсальным, допускающим хранение данных разного типа. С другой стороны, мы не хотим, чтобы в одном списке происходило смешение типов, - уж если там хранятся персоны, то чисел int в нем не должно быть. По этим причинам класс должен быть универсальным, имея в качестве параметра тип T, задающий тип хранимых данных. Мы потребуем также, чтобы данные хранились с их ключами. И поскольку не хочется заранее накладывать ограничения на тип ключей - они могут быть строковыми или числовыми, - то тип хранимых ключей будет еще одним параметром нашего класса. Поскольку мы хотим определить над списком операцию поиска по ключу, то нам придется выполнять проверку ключей на равенство, поэтому универсальность типа ключей должна быть ограниченной. Проще всего сделать этот тип наследником стандартного интерфейса IComparable.
Чтобы не затемнять ситуацию сложностью списка, рассмотрим достаточно простой односвязный список с курсором. Элементы этого списка будут принадлежать классу Node, два поля которого будут хранить ключ и сам элемент, а третье поле будет задавать указатель на следующий элемент списка. Очевидно, что этот класс должен быть универсальным классом. Вот как выглядит текст этого класса:
class Node where K:IComparable { public Node() { next = null; key = default(K); item = default( T); } public K key; public T item; public Node next; }
Класс Node имеет два родовых параметра, задающих тип ключей и тип элементов. Ограничение на тип ключей позволяет выполнять их сравнение. В конструкторе класса поля инициализируются значениями по умолчанию соответствующего типа.
Рассмотрим теперь организацию односвязного списка. Начнем с того, как устроены его данные:
public class OneLinkList where K : IComparable { Node first, cursor; }



Являясь клиентом универсального класса Node, наш класс сохраняет родовые параметры клиента и ограничения, накладываемые на них. Два поля класса - first и cursor - задают указатели на первый и текущий элементы списка. Операции над списком связываются с курсором, позволяя перемещать курсор по списку. Рассмотрим вначале набор операций, перемещающих курсор:

public void start() { cursor = first; } public void finish() { while (cursor.next != null) cursor = cursor.next; } public void forth() { if (cursor.next != null) cursor = cursor.next; }

Операция start передвигает курсор к началу списка, finish - к концу, а forth - к следующему элементу справа от курсора. Операции finish и forth определены только для непустых списков. Конец списка является барьером, и курсор не переходит через барьер. Нарушая принципы ради краткости текста, я не привожу формальных спецификаций методов, записанных в тегах

.

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

public void add(K key, T item) { Node newnode = new Node(); if (first == null) { first = newnode; cursor = newnode; newnode.key = key; newnode.item = item; } else { newnode.next = cursor.next; cursor.next = newnode; newnode.key = key; newnode.item = item; } }

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

Рассмотрим теперь операцию поиска элемента по ключу, реализация которой потребовала ограничения универсальности типа ключа K:

public bool findstart(K key) { Node temp = first; while (temp != null) { if (temp.key.CompareTo(key) == 0) {cursor=temp; return(true);} temp= temp.next; } return (false); }

Искомые элементы разыскиваются во всем списке. Если элемент найден, то курсор устанавливается на найденном элементе и метод возвращает значение true. Если элемента с заданным ключом нет в списке, то позиция курсора не меняется, а метод возвращает значение false. В процессе поиска для каждого очередного элемента списка вызывается допускаемый ограничением метод CompareTo интерфейса IComparable. При отсутствии ограничений универсальности вызов этого метода или операции эквивалентности приводил бы к ошибке, обнаруживаемой на этапе компиляции.

Два метода класса являются запросами, позволяющими извлечь ключ и элемент списка, который отмечен курсором:

public K Key() { return (cursor.key); } public T Item() { return(cursor.item); }



Давайте рассмотрим теперь тестирующую процедуру - клиента нашего списка, демонстрирующую работу со списками, в которых элементы и ключи имеют разные типы:

public void TestConstraint() { OneLinkList list1 = new OneLinkList (); list1.add(33, "thirty three"); list1.add(22, "twenty two"); if(list1.findstart(33)) Console.WriteLine ("33 - найдено!"); else Console.WriteLine("33 - не найдено!"); if (list1.findstart(22)) Console.WriteLine ("22 - найдено!"); else Console.WriteLine("22 - не найдено!"); if (list1.findstart(44)) Console.WriteLine ("44 - найдено!"); else Console.WriteLine("44 - не найдено!"); Person pers1 = new Person("Савлов", 25, 1500); Person pers2 = new Person("Павлов", 35, 2100); OneLinkList list2 = new OneLinkList < string, Person>(); list2.add("Савл", pers1); list2.add( "Павел", pers2); if (list2.findstart("Павел")) Console.WriteLine ("Павел - найдено!"); else Console.WriteLine("Павел - не найдено!"); if (list2.findstart("Савл")) Console.WriteLine ("Савл - найдено!"); else Console.WriteLine("Савл - не найдено!"); if (list2.findstart("Иоанн")) Console.WriteLine ("Иоанн - найдено!"); else Console.WriteLine("Иоанн - не найдено!"); Person pers3 = new Person("Иванов", 33, 3000); list2.add("Иоанн", pers3); list2.start(); Person pers = list2.Item(); pers.PrintPerson(); list2.findstart("Иоанн"); pers = list2.Item(); pers.PrintPerson(); }

Рис. 22.5.  Поиск в списке с ограниченной универсальностью

Обратите внимание на строки, где создаются два списка:

OneLinkList list1 = new OneLinkList(); OneLinkList list2 = new OneLinkList< string, Person>();

У списка list1 ключи имеют тип int, у списка list2 - string. Заметьте, оба фактических типа, согласно обязательствам, реализуют интерфейс IComparable. У первого списка тип элементов - string, у второго - Person. Все работает прекрасно. Вот результаты вычислений по этой процедуре:

Статические поля и методы арифметических классов

Все арифметические классы, в том числе класс Int, обладают двумя полезными полями (свойствами) - MinValue и MaxValue. Эти поля возвращают минимальное и максимальное значение, которое могут иметь экземпляры класса. Поля являются статическими и потому недоступны для экземпляров класса и могут быть вызваны только при указании имени класса. Разумно привести пример вызова этих полей для класса Int и, например, для класса Double:
//Min и Max значения типов Console.WriteLine("Class int"); Console.WriteLine("Мин. значение int = " + int.MinValue); Console.WriteLine("Макс. значение int = " + int.MaxValue); Console.WriteLine("Class double"); Console.WriteLine("Мин. значение double = " + double.MinValue); Console.WriteLine("Макс. значение double = " + double.MaxValue);
Все арифметические классы, в том числе класс Int, обладают перегруженным статическим методом Parse, у которого первым обязательным параметром является строка, задающая значение соответствующего арифметического типа в привычной для данного региона (локализованной) форме. Форматом строки и стилем ее представления можно управлять с помощью других параметров метода Parse. Вот пример вызова этого метода для классов Int и Double:
///

/// Преобразования типа с использованием метода Parse ///

public void Parsing() { //method Parse Console.WriteLine("Введите целое"); string strdata = Console.ReadLine(); int intdata = int.Parse(strdata); Console.WriteLine("Введите число с дробной частью и порядком"); strdata = Console.ReadLine(); double doubdata = double.Parse(strdata); Console.WriteLine("intdata = {0}; doubdata = {1}", intdata, doubdata); } //Parsing
Как видите, метод Parse с успехом заменяет соответствующий метод класса Convert.
На рис. 6.3 можно увидеть консольный вывод, полученный в результате работы процедуры Parsing.

Рис. 6.3.  Результаты работы процедуры Parsing

Статические поля и методы класса

Ранее говорилось, что когда конструктор класса создает новый объект, то в памяти создается структура данных с полями, определяемыми классом. Уточним теперь это описание. Не все поля отражаются в структуре объекта. У класса могут быть поля, связанные не с объектами, а с самим классом. Эти поля объявляются как статические с модификатором static. Статические поля доступны всем методам класса. Независимо от того, какой объект вызвал метод, используются одни и те же статические поля, позволяя методу использовать информацию, созданную другими объектами класса. Статические поля представляют общий информационный пул для всех объектов классов, позволяя извлекать и создавать общую информацию. Например, у класса Person может быть статическое поле message, в котором каждый объект может оставить сообщение для других объектов класса.
Аналогично полям, у класса могут быть и статические методы, объявленные с модификатором static. Такие методы не используют информацию о свойствах конкретных объектов класса - они обрабатывают общую для класса информацию, хранящуюся в его статических полях. Например, в классе Person может быть статический метод, обрабатывающий данные из статического поля message. Другим частым случаем применения статических методов является ситуация, когда класс предоставляет свои сервисы объектам других классов. Таковым является класс Math из библиотеки FCL, который не имеет собственных полей - все его статические методы работают с объектами арифметических классов.
Как вызываются статические поля и методы? Напомню, что всякий вызов метода в объектных вычислениях имеет вид x.F(...); где x - это цель вызова. Обычно целью вызова является объект, который вызывает методы класса, не являющиеся статическими (динамическими или экземплярными). В этом случае поля целевого объекта доступны методу и служат глобальным источником информации. Если же необходимо вызвать статический метод (поле), то целью должен быть сам класс. Можно полагать, что для каждого класса автоматически создается статический объект с именем класса, содержащий статические поля и обладающий статическими методами. Этот объект и его методы доступны и тогда, когда ни один другой динамический объект класса еще не создан. (Полагаю, что разумно обратиться к лекции 2, а именно, к разделу, описывающему точку большого взрыва, процесс вычислений в ОО-системах, вызовы статических методов.)

Статические свойства и методы класса String

Таблица 14.1. Статические методы и свойства класса StringМетодОписание

Empty	Возвращается пустая строка. Свойство со статусом read only
Compare	Сравнение двух строк. Метод перегружен. Реализации метода позволяют сравнивать как строки, так и подстроки. При этом можно учитывать или не учитывать регистр, особенности национального форматирования дат, чисел и т.д.
CompareOrdinal	Сравнение двух строк. Метод перегружен. Реализации метода позволяют сравнивать как строки, так и подстроки. Сравниваются коды символов
Concat	Конкатенация строк. Метод перегружен, допускает сцепление произвольного числа строк
Copy	Создается копия строки
Format	Выполняет форматирование в соответствии с заданными спецификациями формата. Ниже приведено более полное описание метода
Intern, IsIntern	Отыскивается и возвращается ссылка на строку, если таковая уже хранится во внутреннем пуле данных. Если же строки нет, то первый из методов добавляет строку во внутренний пул, второй - возвращает null. Методы применяются обычно тогда, когда строка создается с использованием построителя строк - класса StringBuilder
Join	Конкатенация массива строк в единую строку. При конкатенации между элементами массива вставляются разделители. Операция, заданная методом Join, является обратной к операции, заданной методом Split. Последний является динамическим методом и, используя разделители, осуществляет разделение строки на элементы

Статический контроль типов и динамическое связывание

Рассмотрим семейство классов A1, A2, ... An, связанных отношением наследования. Класс Ak+1 является прямым потомком класса Ak. Пусть создана последовательность объектов x1, x2, ... xn, где xk - это объект класса Ak. Пусть в классе A1 создан метод M с модификатором virtual, переопределяемый всеми потомками, так что в рамках семейства классов метод M существует в n-формах, каждая из которых задает реализацию метода, выбранную соответствующим потомком. Рассмотрим основную операцию, инициирующую объектные вычисления - вызов объектом метода класса:
x1.M(arg1, arg2, ... argN)
Контролем типов называется проверка каждого вызова, удостоверяющая, что:

• в классе A1 объекта x1 действительно имеется метод M;
• список фактических аргументов в точке вызова соответствует по числу и типам списку формальных аргументов метода M, заданного в классе A1.

Язык C#, как и большинство других языков программирования, позволяет выполнить эту проверку еще на этапе компиляции и в случае нарушений выдать сообщение об ошибке периода компиляции. Контроль типов, выполняемый на этапе компиляции, называется статическим контролем типов. Некоторые языки, например Smalltalk, производят этот контроль динамически - непосредственно перед выполнением метода. Понятно, что ошибки, обнаруживаемые при динамическом контроле типов, трудно исправимы и потому приводят к более тяжелым последствиям. В таких случаях остается уповать на то, что система тщательно отлажена, иначе непонятно, что будет делать конечный пользователь, получивший сообщение о том, что вызываемого метода вообще нет в классе данного объекта.
Перейдем к рассмотрению связывания. Напомним, что в рассматриваемом семействе классов метод M полиморфен: имея одно и то же имя и сигнатуру, он существует в разных формах - для каждого класса задана собственная реализация метода. С другой стороны, из-за возможностей, предоставляемых односторонним присваиванием, в точке вызова неясно, с объектом какого класса семейства в данный момент связана сущность x1 (вызову мог предшествовать такой оператор присваивания if(B) x1 = xk;).
Статическим связыванием называется связывание цели вызова и вызываемого метода на этапе компиляции, когда с сущностью связывается метод класса, заданного при объявлении сущности.
Динамическим связыванием называется связывание цели вызова и вызываемого метода на этапе выполнения, когда с сущностью связывается метод класса объекта, связанного с сущностью в момент выполнения.
При статическом связывании метод выбирается из класса сущности, при динамическом - из класса объекта, связанного с сущностью. Понятно, что на этапе компиляции возможно только статическое связывание, поскольку только в период выполнения можно определить, с объектом какого класса связана данная сущность. Это может быть класс любого из потомков класса сущности.
Какой же из видов связывания следует применять? Статическое связывание более эффективно в реализации, поскольку может быть сделано на этапе компиляции, так что при выполнении не потребуется никаких проверок. Динамическое связывание требует накладных расходов в период выполнения. Однако во многих случаях преимущества динамического связывания столь значительны, что о затратах не стоит и беспокоиться.
Уже достаточно давно разработан эффективный механизм реализации динамического связывания. Еще на этапе компиляции подготавливается так называемая таблица виртуальных методов, содержащая их адреса. Связывание объекта xk с принадлежащим ему методом Mk производится выбором соответствующего элемента из этой таблицы и выполняется ненамного сложнее, чем получение по индексу соответствующего элемента массива.
В языке C# принята следующая стратегия связывания. По умолчанию предполагается статическое связывание. Для того чтобы выполнялось динамическое связывание, метод родительского класса должен снабжаться модификатором virtual или abstract, а его потомки должны иметь модификатор override.

Стек. От абстрактного, универсального класса к конкретным версиям

Возьмем классическую задачу определения стека. Следуя схеме, определим абстрактный универсальный класс, описывающий всевозможные представления стеков:
///

/// Абстрактный класс GenStack задает контейнер с /// доступом LIFO: /// Функции: /// конструктор new: -> GenStack /// запросы: /// item: GenStack -> T /// empty: GenStack -> Boolean /// процедуры: /// put: GenStack*T -> GenStack /// remove: GenStack -> GenStack /// Аксиомы: /// remove(put(s,x)) = s /// item(put(s,x)) = x /// empty(new)= true /// empty(put(s,x)) = false ///

abstract public class GenStack { ///

/// require: not empty(); ///

/// элемент вершины(последний пришедший) abstract public T item(); ///

/// require: not empty(); /// ensure: удален элемент вершины(последний пришедший) ///

abstract public void remove(); ///

/// require: true; ensure: elem находится в вершине стека ///

/// abstract public void put(T t); ///

/// require: true; ///

/// true если стек пуст, иначе false abstract public bool empty(); }// class GenStack
В приведенном примере программного текста чуть-чуть. Это объявление абстрактного универсального класса:
abstract public class GenStack
и четыре строки с объявлением сигнатуры его методов. Основной текст задает описание спецификации класса и его методов. Заметьте, здесь спецификации заданы достаточно формально с использованием аксиом, характеризующих смысл операций, которые выполняются над стеком.
Не хочется вдаваться в математические подробности, отмечу лишь, что, если задать последовательность операций над стеком, то аксиомы позволяют точно определить состояние стека в результате выполнения этих операций. Как неоднократно отмечалось с первых лекций курса, XML-отчет, построенный по этому проекту, будет содержать в читаемой форме все спецификации нашего класса. Отмечу еще, что все потомки класса должны удовлетворять этим спецификациям, хотя могут добавлять и собственные ограничения.
Наш класс является универсальным - стек может хранить элементы любого типа, и конкретизация типа будет производиться в момент создания экземпляра стека.
Наш класс является абстрактным - не задана ни реализация методов, ни то, как стек будет представлен. Эти вопросы будут решать потомки класса.
Перейдем теперь ко второму этапу и построим потомков класса, каждый из которых задает некоторое представление стека и соответствующую этому представлению реализацию методов. Из всех возможных представлений ограничимся двумя. В первом из них стек будет представлен линейной односвязной списковой структурой. Во втором - он строится на массиве фиксированного размера, задавая стек ограниченной емкости. Вот как выглядит первый потомок абстрактного класса:
///

/// Стек, построенный на односвязных элементах списка GenLinkable ///

public class OneLinkStack : GenStack { public OneLinkStack() { last = null; } GenLinkable last; //ссылка на стек (вершину стека) public override T item() { return (last.Item); }//item public override bool empty() { return (last == null); }//empty public override void put(T elem) { GenLinkable newitem = new GenLinkable(); newitem.Item = elem; newitem.Next = last; last = newitem; }//put public override void remove() { last = last.Next; }//remove }//class OneLinkStack



Посмотрите, что происходит при наследовании от универсального класса. Во-первых, сам потомок также является универсальным классом:

public class OneLinkStack : GenStack

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

GenLinkable last; //ссылка на стек (элемент стека)

В-третьих, тип T встречается в тексте потомка всюду, где речь идет о типе элементов, добавляемых в стек, как, например:

public override void put(T elem)

По ходу дела нам понадобился класс, задающий представление элементов стека в списковом представлении. Объявим его:

public class GenLinkable { public T Item; public GenLinkable Next; public GenLinkable() { Item = default(T); Next = null; } }

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

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

public class ArrayUpStack : GenStack { int SizeOfStack; T[] stack; int top; ///

/// конструктор ///

/// размер стека public ArrayUpStack(int size) { SizeOfStack = size; stack = new T[SizeOfStack]; top = 0; } ///

/// require: (top < SizeOfStack) ///

/// элемент, помещаемый в стек public override void put(T x) { stack[top] = x; top++; }



public override void remove() { top--; } public override T item() { return (stack[top-1]); } public override bool empty() { return (top == 0); } }//class ArrayUpStack

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

public void TestStacks() { OneLinkStack stack1 = new OneLinkStack(); OneLinkStack stack2 = new OneLinkStack(); ArrayUpStack stack3 = new ArrayUpStack (10); stack1.put(11); stack1.put(22); int x1 = stack1.item(), x2 = stack1.item(); if ((x1 == x2) && (x1 == 22)) Console.WriteLine("OK!"); stack1.remove(); x2 = stack1.item(); if ((x1 != x2) && (x2 == 11)) Console.WriteLine("OK!"); stack1.remove(); x2 = (stack1.empty())? 77 : stack1.item(); if ((x1 != x2) && (x2 == 77)) Console.WriteLine("OK!"); stack2.put("first"); stack2.put("second"); stack2.remove(); string s = stack2.item(); if (!stack2.empty()) Console.WriteLine(s); stack3.put(3.33); stack3.put(Math.Sqrt(Math.PI)); double res = stack3.item(); stack3.remove(); res += stack3.item(); Console.WriteLine("res= {0}", res); }

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

Рис. 22.3.  Три разных стека, порожденных абстрактным универсальным классом

Дополним наше рассмотрение еще одним примером работы с вариацией стеков, в том числе хранящим объекты класса Person:

public void TestPerson() { OneLinkStack stack1 = new OneLinkStack(); OneLinkStack stack2 = new OneLinkStack(); ArrayUpStack stack3 = new ArrayUpStack (10); ArrayUpStack stack4 = new ArrayUpStack(7); stack2.put("Петров"); stack2.put("Васильев"); stack2.put("Шустов"); stack1.put(27); stack1.put(45); stack1.put(53); stack3.put(21550.5); stack3.put(12345.7); stack3.put(32458.8); stack4.put(new Person(stack2.item(), stack1.item(), stack3.item())); stack1.remove(); stack2.remove(); stack3.remove(); stack4.put(new Person(stack2.item(), stack1.item(), stack3.item())); stack1.remove(); stack2.remove(); stack3.remove(); stack4.put(new Person(stack2.item(), stack1.item(), stack3.item())); Person pers = stack4.item(); pers.PrintPerson(); stack4.remove(); pers = stack4.item(); pers.PrintPerson(); stack4.remove(); pers = stack4.item(); pers.PrintPerson(); stack4.remove(); if (stack4.empty()) Console.WriteLine("OK!"); }

Результаты работы этой процедуры приведены на рис. 22.4.

Рис. 22.4.  Работа со стеками

Строки С++

В языке С++ есть все виды строк. Символьный тип char используется для задания отдельных символов. Для строк постоянной длины можно использовать массив символов - char[]. Особенностью, характерной для языка С++, точнее для языка С, является завершение строки символом с нулевым кодом. Строки, завершаемые нулем, называются обычно строками С. Массив char[] задает строку С и потому должен иметь размер, по крайней мере, на единицу больше фактического размера строки. Вот пример объявления подобных строк в С++:
//Массивы и строки char strM1[] = "Hello, World!"; char strM2[20] = "Yes";
Массив strM1 состоит из 14 символов, массив strM2 - из 20, но его четвертый символ имеет код 0, сигнализирующий о фактическом конце строки.
Другой способ задания строк С, заканчивающихся нулем, состоит в использовании типизированного указателя - char*.
//Строки, заданные указателем char* char* strPM1 ="Hello, World!"; char* strPM2;
Два типа, char[] и char*, допускают взаимные преобразования.
Не могу удержаться, чтобы не привести процедуру копирования строк, соответствующую духу и стилю С++:
void mycpy(char* p, const char* q) { while(*p++ = *q++); }
Эта процедура копирует содержимое строки q в строку p. В этой короткой программе, в которой, кроме условия цикла while, ничего больше нет, фактически используются многие средства языка С++ - разыменование указателей, адресная арифметика, присваивание как операция, завершение строки нулем, логическая интерпретация значений. Раз уж я привел эту программу, то поясню, как она работает. Вначале указатель q задает адрес начала строки, поэтому разыменование *q задает первый символ копируемой строки. Это значение присваивается первому символу строки p. Суффиксные операции p++ и q++ увеличивают значение указателей на единицу, но поскольку используется адресная арифметика, то в результате вычисляется адрес, задающий следующий символ соответствующих строк, и процесс копирования продолжается. При достижении последнего символа строки q - символа с кодом нуль - он также будет скопирован в строку p. Но в этот момент выражение присваивание впервые вернет в качестве значения результат 0, который будет проинтерпретирован в условии цикла while как false, и цикл завершит свою работу. Строка будет скопирована.
Можно восхищаться этой короткой и эффективной программой, можно ругать ее за сложность восприятия. Трудно назвать ее интуитивно понятной. Но во многом все определяется вкусом и привычкой.
Тип string не является частью языка С++, но входит в библиотеку, определяемую стандартом языка. Стандартные библиотеки, по сути, являются продолжением языка. Тип (класс) string обеспечивает работу со строками переменной длины и поддерживает многие полезные операции над строками.



Давайте разберемся, как устроены строки C# и что взято из языка С++.

Строковые константы

Без констант не обойтись. В C# существуют два вида строковых констант:

• обычные константы, которые представляют строку символов, заключенную в кавычки;
• @-константы, заданные обычной константой c предшествующим знаком @.

В обычных константах некоторые символы интерпретируются особым образом. Связано это прежде всего с тем, что необходимо уметь задавать в строке непечатаемые символы, такие, как, например, символ табуляции. Возникает необходимость задавать символы их кодом - в виде escape-последовательностей. Для всех этих целей используется комбинация символов, начинающаяся символом "\" - обратная косая черта. Так, пары символов: "\n", "\t", "\\", "\"" задают соответственно символ перехода на новую строку, символ табуляции, сам символ обратной косой черты, символ кавычки, вставляемый в строку, но не сигнализирующий о ее окончании. Комбинация "\xNNNN" задает символ, определяемый шестнадцатеричным кодом NNNN. Хотя такое решение возникающих проблем совершенно естественно, иногда возникают неудобства: например, при задании констант, определяющих путь к файлу, приходится каждый раз удваивать символ обратной косой черты. Это одна из причин, по которой появились @-константы.
В @-константах все символы трактуются в полном соответствии с их изображением. Поэтому путь к файлу лучше задавать @-константой. Единственная проблема в таких случаях: как задать символ кавычки, чтобы он не воспринимался как конец самой константы. Решением является удвоение символа. Вот соответствующие примеры:
//Два вида констант s1= "\x50"; s2=@"\x50"""; b1= (s1==s2); Console.WriteLine("s1={0}, s2={1}, b1={2}", s1,s2,b1); s1 = "c:\\c#book\\ch5\\chapter5.doc"; s2 = @"c:\c#book\ch5\chapter5.doc"; b1= (s1==s2); Console.WriteLine("s1={0}, s2={1}, b1={2}", s1,s2,b1); s1= "\"A\""; s2=@"""A"""; b1= (s1==s2); Console.WriteLine("s1={0}, s2={1}, b1={2}", s1,s2,b1);
Взгляните на результаты работы приведенных фрагментов кода, полученные при вызове процедур TestDeclStrings и TestOpers.

Рис. 14.1.  Объявления, константы и операции над объектами string

Структурные типы

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

Структуры

Рассмотрим теперь более подробно вопросы описания структур, их синтаксиса, семантики и тех особенностей, что отличают их от классов.

Существует ли в C# тип char*

В языке C# указатели допускаются в блоках, отмеченных как небезопасные. Теоретически в таких блоках можно объявить переменную типа Char*, но все равно не удастся написать столь же короткую, как в С++, процедуру копирования строк. Правильно считать, что в C# строки типа char* использовать не рекомендуется.

Сводка свойств и методов класса Array

Многие возможности, которыми можно пользоваться при работе с массивами, уже обсуждены. В завершение этой темы в таблицах 12.1-12.3 приведем сводку всех свойств и методов класса Array.

Таблица 12.3. Динамические методы класса ArrayМетодРодительОписание

Equals	Класс Object	Описание и примеры даны в предыдущих главах.
GetHashCode	Класс Object	Описание и примеры даны в предыдущих главах.
GetType	Класс Object	Описание и примеры даны в предыдущих главах.
ToString	Класс Object	Описание и примеры даны в предыдущих главах.
Clone	Интерфейс ICloneable	Позволяет создать плоскую или глубокую копию массива. В первом случае создаются только элементы первого уровня, а ссылки указывают на те же самые объекты. Во втором случае копируются объекты на всех уровнях. Для массивов создается только плоская копия.
CopyTo	Интерфейс ICollection	Копируются все элементы одномерного массива в другой одномерный массив, начиная с заданного индекса: col1.CopyTo(col2,0);
GetEnumerator	Интерфейс IEnumerable	Стоит за спиной цикла ForEach
GetLength		Возвращает число элементов массива по указанному измерению. Описание и примеры даны в тексте главы.
GetLowerBound, GetUpperBound		Возвращает нижнюю и верхнюю границу по указанному измерению. Для массивов нижняя граница всегда равна нулю.
GetValue, SetValue		Возвращает или устанавливает значение элемента массива с указанными индексами.
Initialize		Может быть применен только к массивам значимого типа. Инициализирует элементы, вызывая соответствующий конструктор. Как правило, не используется в обычных программах.

Свойства класса Rational

Два целых числа - m и n представляют рациональное число. Они и становятся полями класса. Совершенно естественно сделать эти поля закрытыми. Разумная стратегия доступа к ним - "ни чтения, ни записи", поскольку пользователь не должен знать, как представлено рациональное число в классе, и не должен иметь доступа к составляющим рационального числа. Поэтому для таких закрытых полей не будут определяться методы-свойства. Вот объявление полей класса:
//Поля класса. Числитель и знаменатель рационального числа. int m,n;

Тело метода

Синтаксически тело метода является блоком, который представляет собой последовательность операторов и описаний переменных, заключенную в фигурные скобки. Если речь идет о теле функции, то в блоке должен быть хотя бы один оператор перехода, возвращающий значение функции в форме return (выражение).
Оператор return описан в лекции 8.
Переменные, описанные в блоке, считаются локализованными в этом блоке. В записи операторов блока участвуют имена локальных переменных блока, имена полей класса и имена аргументов метода.

Область видимости, время жизни переменных, конфликты имен рассмотрены в лекции 5, семантика операторов - в лекции 8. Дополнительные сведения о семантике выполнения метода будут даны в этой лекции.

Знания семантики описаний и операторов достаточно для понимания семантики блока. Необходимые уточнения будут даны чуть позже.

Тестирование создания рациональных чисел

В классе Testing, предназначенном для тестирования нашей работы и являющегося клиентом класса Rational, создадим процедуру, позволяющую проверить корректность создания рациональных чисел. Вот эта процедура:
public void TestCreateRational() { Rational r1=new Rational(0,0), r2 = new Rational(1,1); Rational r3=new Rational(10,8), r4 = new Rational(2,6); Rational r5=new Rational(4,-12), r6 = new Rational (-12,-14); r1.PrintRational("r1:(0,0)"); r2.PrintRational("r2:(1,1)"); r3.PrintRational("r3:(10,8)"); r4.PrintRational("r4:(2,6)"); r5.PrintRational("r5: (4,-12)"); r6.PrintRational("r6: (-12,-14)"); }
Она создает и печатает шесть рациональных чисел. Вот как выглядят результаты ее работы.

Рис. 16.3.  Создание и печать рациональных чисел

Типы или классы? И типы, и классы

Язык C# в большей степени, чем язык C++, является языком объектного программирования. В чем это выражается? В языке C# сглажено различие между типом и классом. Все типы - встроенные и пользовательские - одновременно являются классами, связанными отношением наследования. Родительским, базовым классом является класс Object. Все остальные типы или, точнее, классы являются его потомками, наследуя методы этого класса. У класса Object есть четыре наследуемых метода:

1. bool Equals (object obj) - проверяет эквивалентность текущего объекта и объекта, переданного в качестве аргумента;
2. System.Type GetType () - возвращает системный тип текущего объекта;
3. string ToString () - возвращает строку, связанную с объектом. Для арифметических типов возвращается значение, преобразованное в строку;
4. int GetHashCode() - служит как хэш-функция в соответствующих алгоритмах поиска по ключу при хранении данных в хэш-таблицах.

Естественно, что все встроенные типы нужным образом переопределяют методы родителя и добавляют собственные методы и свойства. Учитывая, что и типы, создаваемые пользователем, также являются потомками класса Object, то для них необходимо переопределить методы родителя, если предполагается использование этих методов; реализация родителя, предоставляемая по умолчанию, не обеспечивает нужного эффекта.
Перейдем теперь к примерам, на которых будем объяснять дальнейшие вопросы, связанные с типами и классами, переменными и объектами. Начнем с вполне корректного в языке C# примера объявления переменных и присваивания им значений:
int x=11; int v = new Int32(); v = 007; string s1 = "Agent"; s1 = s1 + v.ToString() +x.ToString();
В этом примере переменная x объявляется как обычная переменная типа int. В то же время для объявления переменной v того же типа int используется стиль, принятый для объектов. В объявлении применяется конструкция new и вызов конструктора класса. В операторе присваивания, записанном в последней строке фрагмента, для обеих переменных вызывается метод ToString, как это делается при работе с объектами. Этот метод, наследуемый от родительского класса Object, переопределенный в классе int, возвращает строку с записью целого. Сообщу еще, что класс int не только наследует методы родителя - класса Object, - но и дополнительно определяет метод CompareTo, выполняющий сравнение целых, и метод GetTypeCode, возвращающий системный код типа. Для класса Int определены также статические методы и поля, о которых расскажу чуть позже.
Так что же такое после этого int, спросите Вы: тип или класс? Ведь ранее говорилось, что int относится к value-типам, следовательно, он хранит в стеке значения своих переменных, в то время как объекты должны задаваться ссылками. С другой стороны, создание экземпляра с помощью конструктора, вызов методов, наконец, существование родительского класса Object, - все это указывает на то, что int - это настоящий класс. Правильный ответ состоит в том, что int - это и тип, и класс. В зависимости от контекста x может восприниматься как переменная типа int или как объект класса int. Это же верно и для всех остальных value- типов. Замечу еще, что все значимые типы фактически реализованы как структуры, представляющие частный случай класса.
Остается понять, для чего в языке C# введена такая двойственность. Для int и других значимых типов сохранена концепция типа не только из-за ностальгических воспоминаний о типах. Дело в том, что значимые типы эффективнее в реализации, им проще отводить память, так что именно соображения эффективности реализации заставили авторов языка сохранить значимые типы. Более важно, что зачастую необходимо оперировать значениями, а не ссылками на них, хотя бы из-за различий в семантике присваивания для переменных ссылочных и значимых типов.
С другой стороны, в определенном контексте крайне полезно рассматривать переменные типа int как настоящие объекты и обращаться с ними как с объектами. В частности, полезно иметь возможность создавать и работать со списками, чьи элементы являются разнородными объектами, в том числе и принадлежащими к значимым типам.
Дальнейшие примеры работы с типами и проект Types
Обсуждение особенностей тех или иных конструкций языка невозможно без приведения примеров. Для каждой лекции я строю один или несколько проектов, сохраняя по возможности одну и ту же схему и реально выполняя проекты в среде Visual Studio .Net. Для работы с примерами данной лекции построен консольный проект с именем Types, содержащий два класса: Class1 и Testing. Расскажу чуть подробнее о той схеме, по которой выстраиваются проекты. Класс Class1 строится автоматически при начальном создании проекта. Он содержит процедуру Main - точку входа в проект. В процедуре Main создается объект класса Testing и вызываются методы этого класса, тестирующие те или иные ситуации. Для решения специальных задач, помимо всегда создаваемого класса Testing, создаются один или несколько классов. Добавление нового класса в проект я осуществляю выбором пункта меню Project/Add Class. В этом случае автоматически строится заготовка для нового класса, содержащая конструктор без параметров. Дальнейшая работа над классом ведется над этой заготовкой. Создаваемые таким образом классы хранятся в проекте в отдельных файлах. Это особенно удобно, если классы используются в разных проектах. Функционально связанную группу классов удобнее хранить в одном файле, что не возбраняется.
Все проекты в книге являются самодокументируемыми. Классы и их методы сопровождаются тегами

. В результате появляются подсказки при вызове методов и возможность построения XML-отчета, играющего роль спецификации проекта.
Приведу текст класса Class1:
using System; namespace Types { ///

/// Проект Types содержит примеры, иллюстрирующие работу /// со встроенными скалярными типами языка С#. /// Проект содержит классы: Testing, Class1. /// ///

class Class1 { ///

/// Точка входа проекта. /// В ней создается объект класса Testing /// и вызываются его методы. ///

[STAThread] static void Main() { Testing tm = new Testing(); Console.WriteLine("Testing.Who Test"); tm.WhoTest(); Console.WriteLine("Testing.Back Test"); tm.BackTest(); Console.WriteLine("Testing.OLoad Test"); tm.OLoadTest(); Console.WriteLine("Testing.ToString Test"); tm.ToStringTest(); Console.WriteLine("Testing.FromString Test"); tm.FromStringTest(); Console.WriteLine("Testing.CheckUncheck Test"); tm.CheckUncheckTest(); } } }
Класс Class1 содержит точку входа Main и ничего более. В процедуре Main создается объект tm класса Testing, затем поочередно вызываются семь методов этого класса. Каждому вызову предшествует выдача соответствующего сообщения на консоль. Каждый метод - это отдельный пример, подлежащий обсуждению.

Третий закон (закон чечако)

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

В классе Found определены два

В классе Found определены два невиртуальных метода NonVirtmethod и Work, наследуемые потомками Derived и ChildDerived без всяких переопределений. Вы ошибаетесь, если думаете, что работа этих методов полностью определяется базовым классом Found. Полиморфизм делает их работу куда более интересной. Давайте рассмотрим в деталях работу метода Work:

public void Work() { VirtMethod(); NonVirtMethod(); Analysis(); }

При компиляции метода Work будет обнаружено, что вызываемый метод VirtMethod является виртуальным, поэтому для него будет применяться динамическое связывание. Это означает, что вопрос о вызове метода откладывается до момента, когда метод Work будет вызван объектом, связанным с x. Объект может принадлежать как классу Found, так и классам Derived и ChildDerived, в зависимости от класса объекта и будет вызван метод этого класса.

Для не виртуальных методов NonVirtMethod и Analysis будет применено статическое связывание, так что Work всегда будет вызывать методы, принадлежащие классу Found. Однако и здесь не все просто. Метод NonVirtMethod

public void NonVirtMethod() { Console.WriteLine ("Мать: "+ this.ToString()); }

в процессе своей работы вызывает виртуальный метод ToString. Опять-таки, для метода ToString будет применяться динамическое связывание, и в момент выполнения будет вызываться метод класса объекта.

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

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

Класс Found, создающий метод Work, говорит примерно следующее: "Я предоставляю этот метод своим потомкам. Потомок, вызвавший этот метод, должен иметь VirtMethod, выполняющий специфическую для потомка часть работы; конечно, потомок может воспользоваться и моей реализацией, но допустима и его собственная реализация. Затем часть работы выполняю я сам, но выдача информации об объекте определяется самим объектом. Заключительную часть работы, связанную с анализом, я потомкам не доверяю и делаю ее сам".

Три механизма, обеспечивающие полиморфизм

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

• одностороннее присваивание объектов внутри семейства классов; сущность, базовым классом которой является класс предка, можно связать с объектом любого из потомков. Другими словами, для введенной нами последовательности объектов xk присваивание xi = xj допустимо для всех j >=i;
• переопределение потомком метода, наследованного от родителя. Благодаря переопределению, в семействе классов существует совокупность полиморфных методов с одним именем и сигнатурой;
• динамическое связывание, позволяющее в момент выполнения вызывать метод, который принадлежит целевому объекту.

В совокупности это и называется полиморфизмом семейства классов. Целевую сущность часто называют полиморфной сущностью, вызываемый метод - полиморфным методом, сам вызов - полиморфным вызовом.
Вернемся к нашему примеру с классами Found, Derived, ChildDerived. Напомню, в родительском классе определен виртуальный метод VirtMethod и переопределен виртуальный метод ToString родительского класса object. Потомок класса Found - класс Derived переопределяет эти методы:
public override void VirtMethod() { Console.WriteLine("Сын: " + this.ToString()); } public override string ToString() { return(String.Format("поля: name = {0}, credit = {1},debet ={2}",name, credit, debet)); }
Потомок класса Derived - класс ChildDerived не создает новых полей. Поэтому он использует во многом методы родителя. Его конструктор состоит из вызова конструктора родителя:
public ChildDerived(string name, int cred, int deb):base (name,cred, deb) {}
Нет и переопределения метода Tostring, поскольку используется реализация родителя. А вот метод VirtMethod переопределяется:
public override void VirtMethod() { Console.WriteLine("внук: " + this.ToString()); }

Универсальность и специальные случаи классов

Универсальность - это механизм, воздействующий на все элементы языка. Поэтому он применим ко всем частным случаям классов C# .

Универсальные делегаты

Делегаты также могут иметь родовые параметры. Чаще встречается ситуация, когда делегат объявляется в универсальном классе и использует в своем объявлении параметры универсального класса. Давайте рассмотрим ситуацию с делегатами более подробно. Вот объявление универсального класса, не очень удачно названного Delegate, в котором объявляется функциональный тип - delegate:
class Delegate { public delegate T Del(T a, T b); }
Как видите, тип аргументов и возвращаемого значения в сигнатуре функционального типа определяется классом Delegate.
Добавим в класс функцию высшего порядка FunAr, одним из аргументов которой будет функция типа Del, заданного делегатом. Эта функция будет применяться к элементам массива, передаваемого также функции FunAr. Приведу описание:
public T FunAr(T[] arr, T a0, Del f) { T temp = a0; for(int i =0; i Эта универсальная функция с успехом может применяться для вычисления сумм, произведения, минимума и других подобных характеристик массива.
Рассмотрим теперь клиентский класс Testing, в котором определен набор функций:
public int max2(int a, int b) { return (a > b) ? a : b; } public double min2(double a, double b) { return (a < b) ? a : b; } public string sum2(string a, string b) { return a + b; } public float prod2(float a, float b) { return a * b; }
Хотя все функции имеют разные типы, все они соответствуют определению класса Del - имеют два аргумента одного типа и возвращают результат того же типа. Посмотрим, как они применяются в тестирующем методе класса Testing:
public void TestFun() { int[] ar1 = { 3, 5, 7, 9 }; double[] ar2 = { 3.5, 5.7, 7.9 }; string[] ar3 = { "Мама ", "мыла ", "Машу ", "мылом." }; float[] ar4 = { 5f, 7f, 9f, 11f }; Delegate d1 = new Delegate(); Delegate.Del del1; del1= this.max2; int max = d1.FunAr(ar1, ar1[0], del1); Console.WriteLine("max= {0}", max); Delegate d2 = new Delegate(); Delegate.Del del2; del2 = this.min2; double min = d2.FunAr(ar2, ar2[0], del2); Console.WriteLine("min= {0}", min); Delegate d3 = new Delegate(); Delegate.Del del3; del3 = this.sum2; string sum = d3.FunAr(ar3, "", del3); Console.WriteLine("concat= {0}", sum); Delegate d4 = new Delegate(); Delegate.Del del4; del4 = this.prod2; float prod = d4.FunAr(ar4, 1f, del4); Console.WriteLine("prod= {0}", prod); }



Обратите внимание на объявление экземпляра делегата:

Delegate.Del del1;

В момент объявления задается фактический тип, и сигнатура экземпляра становится конкретизированной. Теперь экземпляр можно создать и связать с конкретной функцией. В C# 2.0 это делается проще и естественнее, чем ранее, - непосредственным присваиванием:

del1= this.max2;

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

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

public delegate T FunTwoArg(T a, T b);

Добавим в наш тестовый пример код, демонстрирующий работу с этим делегатом:

FunTwoArg mydel; mydel = max2; max = mydel(17, 21); Console.WriteLine("max= {0}", max);

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

Рис. 22.7.  Результаты работы с универсальными делегатами

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

public void delegate EventHandler (object sender, T args) where T:EventArgs

Этот делегат может применяться и для событий с собственными аргументами, поскольку вместо параметра T может быть подставлен конкретный тип - потомок класса EventArgs, дополненный нужными аргументами.

Универсальные интерфейсы

Интерфейсы чаще всего следует делать универсальными, предоставляя большую гибкость для позднейших этапов создания системы. Возможно, вы заметили применение в наших примерах универсальных интерфейсов библиотеки FCL - IComparable и других. Введение универсальности, в первую очередь, сказалось на библиотеке FCL - внутренних классов, определяющих поведение системы. В частности, для большинства интерфейсов появились универсальные двойники с параметрами. Если бы в наших примерах мы использовали не универсальный интерфейс, а обычный, то потеряли бы в эффективности, поскольку сравнение объектов потребовало бы создание временных объектов типа object, выполнения операций boxing и unboxing.

Универсальные структуры

Так же, как и обычный класс, структура может иметь родовые параметры. Синтаксис объявления, ограниченная универсальность, другие детали универсальности естественным образом распространяются на структуры. Вот типичный пример:
public struct Point { T x, y;//координаты точки, тип которых задан параметром // другие свойства и методы структуры }

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

Часто, когда создается класс, желательно задать отношение порядка на его объектах. Такой класс следует объявить наследником интерфейса IComparable. Этот интерфейс имеет всего один метод CompareTo (object obj), возвращающий целочисленное значение, положительное, отрицательное или равное нулю, в зависимости от выполнения отношения "больше", "меньше" или "равно".
Как правило, в классе вначале определяют метод CompareTo, а после этого вводят перегруженные операции, чтобы выполнять сравнение объектов привычным образом с использованием знаков операций отношения.
Давайте введем отношение порядка на классе 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 для персон. Если аргумент метода не будет соответствовать нужному типу, то выбрасывается исключение со специальным уведомлением.
Конечно, сравнение персон может выполняться по разным критериям: возрасту, росту, зарплате. Общий подход к сравнению персон будет рассмотрен в следующей лекции 20.
Введем теперь в нашем классе Person перегрузку операций отношения:
public static bool operator <(Person p1, Person p2) { return (p1.CompareTo(p2) < 0); } public static bool operator >(Person p1, Person p2) { return (p1.CompareTo(p2) > 0); } public static bool operator <=(Person p1, Person p2) { return (p1.CompareTo(p2) <= 0); } public static bool operator >=(Person p1, Person p2) { return (p1.CompareTo(p2) >=0); } public static bool operator ==(Person p1, Person p2) { return (p1.CompareTo(p2) == 0); } public static bool operator !=(Person p1, Person p2) { return (p1.CompareTo(p2) != 0); }



Как обычно, приведу тестовый пример, проверяющий работу с введенными методами:

public void TestCompare() { Person poet1 = new Person("Пушкин"); Person poet2 = new Person("Лермонтов"); Person poet3 = new Person("Пастернак"); Person poet4 = new Person("Мандельштам"); Person poet5 = new Person("Ахматова"); Person poet6 = new Person("Цветаева"); Console.WriteLine("{0} > {1} = {2}", poet1.Fam, poet2.Fam, (poet1 > poet2)); Console.WriteLine("{0} >= {1} = {2}", poet3.Fam, poet4.Fam, (poet3 >= poet4)); Console.WriteLine("{0} != {1} = {2}", poet5.Fam, poet6.Fam, (poet5 != poet6)); }

Вот результаты работы этого теста.

Рис. 19.4.  Сравнение персон

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

Условное выражение

В C#, как и в C++, разрешены условные выражения. Конечно, без них можно обойтись, заменив их условным оператором. Вот простой пример их использования, поясняющий синтаксис их записи:
//Условное выражение int a = 7, b= 9, max; max= (a>b) ? a:b; Console.WriteLine("a = " + a + "; b= " + b + "; max(a,b) = " + max);
Условное выражение начинается с условия, заключенного в круглые скобки, после которого следует знак вопроса и пара выражений, разделенных двоеточием " : ". Условием является выражение типа bool. Если оно истинно, то из пары выражений выбирается первое, в противном случае результатом является значение второго выражения. В данном примере переменная max получит значение 9.

В этой заключительной лекции новый

Приведем код класса:
using System; using System.Drawing; namespace Shapes { ///

/// Figure - это абстрактный класс; прародитель семейства /// классов геометрических фигур. Все фигуры имеют: /// центр - center, масштаб - scale. статус /// перетаскивания - dragged center - объект встроенного /// класса (структуры) Point. Этот объект задает характерную /// точку фигуры - чаще всего ее центр (тяжести) /// scale задает масштаб фигуры, первоначально единичный. /// drugged = true, когда фигура следует за курсором мыши. /// над фигурами определены операции: параллельный /// перенос - Move(a,b) масштабирование - Scale(s) /// Показ фигуры - Show. Область захвата - Region_Capture /// возвращает прямоугольник, характерный для фигуры, /// перетаскивание фигуры возможно при установке курсора /// мыши в области захвата. ///

abstract public class Figure { ///

/// закрытые для клиентов атрибуты класса - center, scale ///

protected Point center; protected double scale ; protected bool dragged; protected Color color; //Доступ к свойствам public Point center_figure { get {return(center);} set {center = value;} } public double scale_figure { get {return(scale);} set {scale = value;} } public bool dragged_figure { get {return(dragged);} set {dragged = value;} } public Color color_figure { get {return(color);} set {color = value;} } ///

/// базовый конструктор фигур ///

/// координата X характерной точки ///фигуры /// Координата Y характерной точки ///фигуры public Figure(int x, int y) { center = new Point(x,y); scale = 1; dragged = false; color = Color.ForestGreen; } ///

/// отложенный метод /// Параллельный перенос фигуры на (a,b) /// require : true; /// ensure : для любой точки фигуры p(x,y): /// x = old(x) +a; y = old(y) + b; ///

/// a - перемещение по горизонтали ///вправо /// b - перемещение по вертикали ///вниз /// Замечание: Для того, чтобы фигура при рисовании была /// полностью видимой, координаты всех ее точек должны /// быть в пределах области рисования. public void Move (int a,int b) { center.X +=a; center.Y += b; } ///

/// изменяет масштаб фигуры ///

/// масштаб изменяется в s раз public void Scale(double s) { scale*=s; } ///

/// рисование фигуры в окне, передающем объекты g и pen ///

/// графический объект, методы которого /// рисуют фигуру /// перо рисования public abstract void Show(Graphics g, Pen pen, Brush brush); public abstract System.Drawing.Rectangle Region_Capture(); }
Абстрактный класс, относящийся к этапу проектирования системы, вместе с тем является важнейшим элементом заключительного семейства классов. В этом проявляется мощь объектно-ориентированного подхода к разработке программных систем. Заметьте, на данном уровне большая часть текста представляет документацию, являющуюся неотъемлемой частью программного проекта. Документация записана в тегах

, что позволяет автоматически ее извлечь и сохранить в виде XML-отчета.

Виды проектов

Как уже отмечалось, Visual Studio .Net для языков C#, Visual Basic и J# предлагает 12 возможных видов проектов. Среди них есть пустой проект, в котором изначально не содержится никакой функциональности; есть также проект, ориентированный на создание Web-служб. В этой книге, направленной, прежде всего, на изучение языка C#, основным видом используемых проектов будут обычные Windows-приложения. На начальных этапах, чтобы не усложнять задачу проблемами пользовательского интерфейса, будем рассматривать также консольные приложения.
Давайте разберемся, как создаются проекты и что они изначально собой представляют. Поговорим также о сопряженных понятиях: решение (solution), проект (project), пространство имен (namespace), сборка (assembly). Рассмотрим результаты работы компилятора Visual Studio с позиций программиста, работающего над проектом, и с позиций CLR, компилирующей PE-файл в исходный код процессора.
С точки зрения программиста, компилятор создает решение, с точки зрения CLR - сборку, содержащую PE-файл. Программист работает с решением, CLR - со сборкой.
Решение содержит один или несколько проектов, ресурсы, необходимые этим проектам, возможно, дополнительные файлы, не входящие в проекты. Один из проектов решения должен быть выделен и назначен стартовым проектом. Выполнение решения начинается со стартового проекта. Проекты одного решения могут быть зависимыми или независимыми. Например, все проекты одной лекции данной книги могут быть для удобства собраны в одном решении и иметь общие свойства . Изменяя стартовый проект, получаем возможность перехода к нужному примеру. Заметьте, стартовый проект должен иметь точку входа - класс, содержащий статическую процедуру с именем Main, которой автоматически передается управление в момент запуска решения на выполнение. В уже имеющееся решение можно добавлять как новые, так и существующие проекты. Один и тот же проект может входить в несколько решений.
Проект состоит из классов, собранных в одном или нескольких пространствах имен. Пространства имен позволяют структурировать проекты, содержащие большое число классов, объединяя в одну группу близкие классы. Если над проектом работает несколько исполнителей, то, как правило, каждый из них создает свое пространство имен. Помимо структуризации, это дает возможность присваивать классам имена, не задумываясь об их уникальности. В разных пространствах имен могут существовать одноименные классы. Проект - это основная единица, с которой работает программист. Он выбирает тип проекта , а Visual Studio создает скелет проекта в соответствии с выбранным типом.
Дальнейшие объяснения лучше сочетать с реальной работой над проектами. Поэтому во всей этой книге я буду вкратце описывать свои действия по реализации тех или иных проектов, надеясь, что их повторение читателем будет способствовать пониманию текста и сути изучаемых вопросов.

Виртуальная машина

Отделение каркаса от студии явилось естественным шагом. Каркас Framework .Net перестал быть частью студии, а стал надстройкой над операционной системой. Теперь компиляция и создание PE-модулей на IL отделено от выполнения, и эти процессы могут быть реализованы на разных платформах. В состав CLR входят трансляторы JIT (Just In Time Compiler), которые и выполняют трансляцию IL в командный код той машины, где установлена и функционирует исполнительная среда CLR. Конечно, в первую очередь Microsoft реализовала CLR и FCL для различных версий Windows, включая Windows 98/Me/NT 4/2000, 32 и 64-разрядные версии Windows XP и семейство .Net Server. Для операционных систем Windows CE и Palm разработана облегченная версия Framework .Net.
В 2001 году ECMA (Европейская ассоциация производителей компьютеров) приняла язык программирования C#, CLR и FCL в качестве стандарта, так что Framework .Net уже функционирует на многих платформах, отличных от Windows. Он становится свободно распространяемой виртуальной машиной. Это существенно расширяет сферу его применения. Производители различных компиляторов и сред разработки программных продуктов предпочитают теперь также транслировать свой код в IL, создавая модули в соответствии со спецификациями CLR. Это обеспечивает возможность выполнения их кода на разных платформах.
Microsoft использовала получивший широкое признание опыт виртуальной машины Java, улучшив процесс за счет того, что, в отличие от Java, промежуточный код не интерпретируется исполнительной средой, а компилируется с учетом всех особенностей текущей платформы. Благодаря этому создаются высокопроизводительные приложения.
Следует отметить, что CLR, работая с IL-кодом, выполняет достаточно эффективную оптимизацию и, что не менее важно, защиту кода. Зачастую нецелесообразно выполнять оптимизацию на уровне создания IL-кода - она иногда может не улучшить, а ухудшить ситуацию, не давая CLR провести оптимизацию на нижнем уровне, где можно учесть даже особенности процессора.

Visual Studio .Net - открытая среда разработки

Среда разработки Visual Studio .Net - это уже проверенный временем программный продукт, являющийся седьмой версией Студии. Но новинки этой версии, связанные с идеей .Net, позволяют считать ее принципиально новой разработкой, определяющей новый этап в создании программных продуктов. Выделю две важнейшие, на мой взгляд, идеи:

• открытость для языков программирования;
• принципиально новый подход к построению каркаса среды - Framework .Net.

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

Давайте рассмотрим такие важные характеристики переменных, как время их жизни и область видимости. Зададимся вопросом, как долго живут объявленные переменные и в какой области программы видимы их имена? Ответ зависит от того, где и как, в каком контексте объявлены переменные. В языке C# не так уж много возможностей для объявления переменных, пожалуй, меньше, чем в любом другом языке. Открою "страшную" тайну, - здесь вообще нет настоящих глобальных переменных. Их отсутствие не следует считать некоторым недостатком C#, это достоинство языка. Но обо всем по порядку.

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

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

Встроенные примитивные типы

Важной частью библиотеки FCL стали классы, задающие примитивные типы - те типы, которые считаются встроенными в язык программирования. Типы каркаса покрывают все множество встроенных типов, встречающихся в языках программирования. Типы языка программирования проецируются на соответствующие типы каркаса. Тип, называемый в языке Visual Basic - Integer, а в языке C# - int, проецируется на один и тот же тип каркаса System.Int32. В каждом языке программирования, наряду с "родными" для языка названиями типов, разрешается пользоваться именами типов, принятыми в каркасе. Поэтому, по сути, все языки среды разработки могут пользоваться единой системой встроенных типов, что, конечно, способствует облегчению взаимодействия компонентов, написанных на разных языках.

Встроенные структуры

Как уже говорилось, все значимые типы языка реализованы структурами. В библиотеке FCL имеются и другие встроенные структуры. Рассмотрим в качестве примера структуры Point, PointF, Size, SizeF и Rectangle, находящиеся в пространстве имен System.Drawing и активно используемые при работе с графическими объектами. Первые четыре структуры имеют два открытых поля X и Y (Height и Width), задающие для точек - структур Point и PointF - координаты, целочисленные или в форме с плавающей точкой. Для размеров - структур Size и SizeF - они задают высоту и ширину, целочисленными значениями или в форме с плавающей точкой. Структуры Point и Size позволяют задать прямоугольную область - структуру Rectangle. Конструктору прямоугольника можно передать в качестве аргументов две структуры - точку, задающую координаты левого верхнего угла прямоугольника, и размер - высоту и ширину прямоугольника.
Между четырьмя структурами определены взаимные преобразования: точки можно преобразовать в размеры и наоборот, сложение и вычитание определено над точками и размерами, но не над точками, плавающий тип которых разными способами можно привести к целому. Ряд операций над этими структурами продемонстрирован в следующем примере:
public void TestPointAndSize() { Point pt1 = new Point(3,5), pt2 = new Point(7,10), pt3; PointF pt4 = new PointF(4.55f,6.75f); Size sz1 = new Size(10,20), sz2; SizeF sz3 = new SizeF(10.3f, 20.7f); pt3 = Point.Round(pt4); sz2 = new Size(pt1); Console.WriteLine ("pt1: " + pt1); Console.WriteLine ("sz2 =new Size(pt1): " + sz2); Console.WriteLine ("pt4: " + pt4); Console.WriteLine ("pt3 =Point.Round(pt4): " + pt3); pt1.Offset(5,7); Console.WriteLine ("pt1.Offset(5,7): " + pt1); Console.WriteLine ("pt2: " + pt2); pt2 = pt2+ sz2; Console.WriteLine ("pt2= pt2+ sz2: " + pt2); }//TestPointAndSize
Результаты его выполнения показаны на рис. 17.1

Рис. 17.1.  Операции над точками и размерами
Отметим, что метод ToString, определенный для этих структур, выдает строку со значениями полей в приемлемой для восприятия форме.

Второй закон (закон для пользователя)

Не бывает некорректных систем. Каждая появляющаяся ошибка при эксплуатации системы - это следствие незнания спецификации системы.
Есть два объяснения справедливости второго закона. Несерьезное объяснение состоит в том, что любая система, что бы она ни делала, при любом постусловии корректна по отношению к предусловию False, поскольку невозможно подобрать ни один набор входных данных, удовлетворяющих этому предусловию. Так что все системы корректны, если задать False в качестве их предусловия. Если вам пришлось столкнуться с системой, предусловие которой близко к False, то лучшее, что можно сделать, это отложить ее в сторону и найти другую.
Более поучительна реальная ситуация, подтверждающая второй закон и рассказанная мне в былые годы Виталием Кауфманом - специалистом по тестированию трансляторов. В одной серьезной организации была разработана серьезная прикладная система, имеющая для них большое значение. К сожалению, при ее эксплуатации сплошь и рядом возникали ошибки, из-за которых организация вынуждена была отказаться от использования системы. Разработчики обратились к нему за помощью. Он, исследуя систему, не внес в нее ни строчки кода. Единственное, что он сделал, это описал точную спецификацию системы, благодаря чему стала возможной нормальная эксплуатация.
Обратите внимание на философию, характерную для этих законов: при возникновении ошибки разработчик и пользователь должны винить себя, а не кивать друг на друга. Так что часто встречающиеся фразы "Ох уж эта фирма Чейтософт - вечно у них ошибки!" характеризует, мягко говоря, непрофессионализм говорящего.

Выбрасывание исключений. Создание объектов Exception

В теле try-блока может возникнуть исключительная ситуация, приводящая к выбрасыванию исключений. Формально выбрасывание исключения происходит при выполнении оператора throw. Этот оператор, чаще всего, выполняется в недрах операционной системы, когда система команд или функция API не может сделать свою работу. Но этот оператор может быть частью программного текста try-блока и выполняться, когда в результате проведенного анализа становится понятным, что дальнейшая нормальная работа невозможна.
Синтаксически оператор throw имеет вид:
throw[выражение]
Выражение throw задает объект класса, являющегося наследником класса Exception. Обычно это выражение new, создающее новый объект. Если оно отсутствует, то повторно выбрасывается текущее исключение. Если исключение выбрасывается операционной системой, то она сама классифицирует исключение, создает объект соответствующего класса и автоматически заполняет его поля.
В рассматриваемой нами модели исключения являются объектами, класс которых представляет собой наследника класса Exception. Этот класс и многочисленные его наследники является частью библиотеки FCL, хотя и разбросаны по разным пространствам имен. Каждый класс задает определенный тип исключения в соответствии с классификацией, принятой в Framework .Net. Вот лишь некоторые классы исключений из пространства имен System: Argument Exception, ArgumentOutOfRangeException, ArithmeticException, BadImageFormatException, DivideByZeroException, OverflowException. В пространстве имен System.IO собраны классы исключений, связанных с проблемами ввода-вывода: DirectoryNotFoundException, FileNotFoundException и многие другие. Имена всех классов исключений заканчиваются словом Exception. Разрешается создавать собственные классы исключений, наследуя их от класса Exception.
При выполнении оператора throw создается объект te, класс TE которого характеризует текущее исключение, а поля содержат информацию о возникшей исключительной ситуации. Выполнение оператора throw приводит к тому, что нормальный процесс вычислений на этом прекращается. Если это происходит в охраняемом try-блоке, то начинается этап "захвата" исключения одним из обработчиков исключений.

Вычисление интеграла

Давайте более подробно рассмотрим ситуацию с функциями высшего порядка на примере задачи вычисления определенного интеграла с заданной точностью. С этой целью создадим класс, в котором будет описан делегат, определяющий контракт, коему должны удовлетворять подынтегральные функции. В этом же классе определим метод, вычисляющий интеграл. По сути самой задачи этот метод представляет собой функцию высшего порядка. Приведу программный код, описывающий класс:
public class HighOrderIntegral { //delegate public delegate double SubIntegralFun(double x); public double EvalIntegral(double a, double b, double eps,SubIntegralFun sif) { int n=4; double I0=0, I1 = I( a, b, n,sif); for( n=8; n < Math.Pow(2.0,15.0); n*=2) { I0 =I1; I1=I(a,b,n,sif); if(Math.Abs(I1-I0) Прокомментирую этот текст:

• Класс HighOrderIntegral предназначен для работы с функциями. В него вложено описание функционального класса - делегата SubIntegralFun, задающего класс функций с одним аргументом типа double и возвращающих значение этого же типа.
• Метод EvalIntegral - основной метод класса позволяет вычислять определенный интеграл. Этот метод есть функция высшего порядка, поскольку одним из его аргументов является подынтегральная функция, принадлежащая классу SubIntegralFun.
• Для вычисления интеграла применяется классическая схема. Интервал интегрирования разбивается на n частей, и вычисляется частичная сумма по методу трапеций, представляющая приближенное значение интеграла. Затем n удваивается, и вычисляется новая сумма. Если разность двух приближений по модулю меньше заданной точности eps, то вычисление интеграла заканчивается, иначе процесс повторяется в цикле. Цикл завершается либо по достижении заданной точности, либо когда n достигнет некоторого предельного значения (в нашем случае - 215).
• Вычисление частичной суммы интеграла по методу трапеций реализовано закрытой процедурой I.
• Впоследствии класс может быть расширен, и помимо вычисления интеграла он может вычислять и другие характеристики функций.

Чтобы продемонстрировать работу с классом HighOrderIntegral, приведу еще класс Functions, где описано несколько функций, удовлетворяющих контракту, который задан классом SubIntegralFun:

class functions { //подынтегральные функции static public double sif1(double x) { int k = 1; int b = 2; return (double)(k*x +b); } static public double sif2(double x) { double a = 1.0; double b = 2.0; double c= 3.0; return (double)(a*x*x +b*x +c); } }//class functions

А теперь рассмотрим метод класса клиента, выполняющий создание нужных объектов и тестирующий их работу:

public void TestEvalIntegrals() { double myint1=0.0; HighOrderIntegral.SubIntegralFun hoisif1 = new HighOrderIntegral.SubIntegralFun(functions.sif1); HighOrderIntegral hoi = new HighOrderIntegral(); myint1 = hoi.EvalIntegral(2,3,0.1e-5,hoisif1); Console.WriteLine("myintegral1 = {0}",myint1); HighOrderIntegral.SubIntegralFun hoisif2 = new HighOrderIntegral.SubIntegralFun(functions.sif2); myint1= hoi.EvalIntegral(2,3,0.1e-5,hoisif2); Console.WriteLine("myintegral2 = {0}",myint1); }//EvalIntegrals

Здесь создаются два экземпляра делегата и объект класса HighOrderIntegral, вызывающий метод вычисления интеграла. Результаты работы показаны на 20.2.

Рис. 20.2.  Вычисление интеграла с использованием функций высших порядков

Выполнение проекта по умолчанию после "большого взрыва"

Давайте посмотрим, что происходит в проектe, создаваемом по умолчанию, когда произошел "большой взрыв", вселенная создана и процедура Main начала работать. Процедура Main содержит всего одну строчку:
Application.Run(new Form1());
Прокомментируем этот квалифицированный вызов. Целью здесь является класс Application из пространства имен System.Windows.Forms. Класс вызывает статический метод Run, которому в качестве фактического аргумента передается объектное выражение new Form1(). При вычислении этого выражения создается первый объект - экземпляр класса Form1. Этот объект становится текущим. Для создания объекта вызывается конструктор класса. В процессе работы конструктора осуществляется неквалифицированный вызов метода InitializeComponent(). Целью этого вызова является текущий объект - уже созданный объект класса Form1. Ни в конструкторе, ни в вызванном методе новые объекты не создаются. По завершении работы конструктора объект класса Form1 передается методу Run в качестве аргумента.
Метод Run класса Application - это знаменитый метод. Во-первых, он открывает форму - видимый образ объекта класса Form1, с которой теперь может работать пользователь. Но главная его работа состоит в том, что он создает настоящее Windows-приложение, запуская цикл обработки сообщений о происходящих событиях. Поступающие сообщения обрабатываются операционной системой согласно очереди и приоритетам, вызывая обработчики соответствующих событий. Поскольку наша форма по умолчанию не заселена никакими элементами управления, то поступающих сообщений немного. Все, что может делать пользователь с формой, так это перетаскивать ее по экрану, свертывать и изменять размеры. Конечно, он может еще закрыть форму. Это приведет к завершению цикла обработки сообщений, к завершению работы метода Run, к завершению работы метода Main, к завершению работы приложения.

Выражения

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

• приоритет операций;
• для операций одного приоритета порядок применения - слева направо или справа налево;
• преобразование типов операндов и выбор реализации для перегруженных операций;
• тип и значение результата выполнения операции над заданными значениями операндов определенного типа.

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

Вызов метода. Семантика

Что происходит в момент вызова метода? Выполнение начинается с вычисления фактических аргументов, которые, как мы знаем, являются выражениями. Вычисление этих выражений может приводить, в свою очередь, к вызову других методов, так что этот первый этап может быть довольно сложным и требовать больших временных затрат. В чисто функциональном программировании все вычисление по программе сводится к вызову одной функции, фактическими аргументами которой являются вызовы функций и так далее и так далее.
Для простоты понимания семантики вызова можно полагать, что в точке вызова создается блок, соответствующий телу метода (в реальности все значительно эффективнее). В этом блоке происходит замена имен формальных аргументов фактическими аргументами. Для выходных аргументов, для которых фактические аргументы также являются именами, эта замена или передача аргументов осуществляется по ссылке, то есть заменяет формальный аргумент ссылкой на реально существующий объект, заданный фактическим аргументом. Чуть более сложную семантику имеет вызов по значению, применяемый к формальным аргументам, которые объявлены без ключевых слов ref и out. При вычислении выражений, заданных такими фактическими аргументами, их значения присваиваются специально создаваемым переменным, локализованным в теле исполняемого блока. Имена этих локализованных переменных и подставляются вместо имен формальных аргументов. Понятно, что тип локализованных переменных определяется типом соответствующего формального аргумента. Понятно также, что семантика замены формальных аргументов фактическими - это, по сути, семантика оператора присваивания.

Семантика присваивания рассматривалась в лекциях 3, 6 и 7.

Каково следствие семантики вызова по значению? Если вы забыли указать ключевое слово ref или out для аргумента, фактически являющегося выходным, то к нему будет применяться вызов по значению. Даже если в теле метода происходит изменение значения этого аргумента, то оно действует только на время выполнения тела метода. Как только метод заканчивает свою работу (завершается блок), все локальные переменные (в том числе, созданные для замены формальных аргументов) оканчивают свое существование, так что изменения не затронут фактических аргументов и они сохранят свои значения, бывшие у них до вызова. Отсюда вывод: все выходные аргументы, значения которых предполагается изменить в процессе работы, должны иметь ключевое слово ref или out. Еще один важный вывод: ключевым словом ref полезно иногда снабжать и входные аргументы. Если известно, что фактический аргумент будет всегда представлен именем, а не сложным выражением, то в целях экономии памяти разумно для таких аргументов применять семантику вызова по ссылке. В этом случае не будет создаваться копия аргумента - это экономит память и время, что может быть важно при работе со сложными структурами.
Говоря о семантике вызова по ссылке и по значению, следует сделать одно важное уточнение. В объектном программировании, каковым является и программирование на C#, основную роль играют ссылочные типы - мы работаем с классами и объектами. Когда методу передается объект ссылочного типа, то все поля этого объекта могут меняться в методе самым беззастенчивым образом. И это несмотря на то, что объект формально не является выходным, не имеет ключевых слов ref или out, использует семантику вызова по значению. Сама ссылка на объект, как и положено, остается неизменной, но состояние объекта, его поля могут полностью обновиться. Такая ситуация типична и представляет один из основных способов изменения состояния объектов. Именно поэтому ref или out не часто появляются при описании аргументов метода.

Вызов метода. Синтаксис

Как уже отмечалось, метод может вызываться в выражениях или быть вызван как оператор. В качестве оператора может использоваться любой метод - как процедура, так и функция. Конечно, функцию разумно вызывать как оператор, только если она обладает побочным эффектом. В последнем случае она вызывается ради своего побочного эффекта, а возвращаемое значение никак не используется. Подобную роль играет использование некоторых выражений с побочным эффектом в роли оператора, классическим примером является оператор x++;.
Если же попытаться вызвать процедуру в выражении, то это приведет к ошибке еще на этапе компиляции. Возвращаемое процедурой значение void несовместимо с выражениями. Так что в выражениях могут быть вызваны только функции.
Сам вызов метода, независимо от того, процедура это или функция, имеет один и тот же синтаксис:
имя_метода([список_фактических_аргументов])
Если это оператор, то вызов завершается точкой с запятой. Формальный аргумент, задаваемый при описании метода - это всегда имя аргумента (идентификатор). Фактический аргумент - это выражение, значительно более сложная синтаксическая конструкция. Вот точный синтаксис фактического аргумента:
[ref|out]выражение

Взаимодействие форм

Обычное Windows-приложение всегда содержит несколько форм. Одни открываются в процессе работы, другие закрываются. В каждый текущий момент на экране может быть открыта одна или несколько форм, пользователь может работать с одной формой или переключаться по ходу работы с одной на другую.
Следует четко различать процесс создания формы - соответствующего объекта, принадлежащего классу Form или наследнику этого класса, - и процесс показа формы на экране. Для показа формы служит метод Show этого класса, вызываемый соответствующим объектом; для скрытия формы используется метод Hide. Реально методы Show и Hide изменяют свойство Visible объекта, так что вместо вызова этих методов можно менять значение этого свойства, устанавливая его либо в true, либо в false.
Заметьте разницу между сокрытием и закрытием формы - между методами Hide и Close. Первый из них делает форму невидимой, но сам объект остается живым и невредимым. Метод Close отбирает у формы ее ресурсы, делая объект отныне недоступным; вызвать метод Show после вызова метода Close невозможно, если только не создать объект заново. Открытие и показ формы всегда означает одно и то же - вызов метода Show. У формы есть метод Close, но нет метода Open. Формы, как и все объекты, создаются при вызове конструктора формы при выполнении операции new.
Форма, открываемая в процедуре Main при вызове метода Run, называется главной формой проекта. Ее закрытие приводит к закрытию всех остальных форм и завершению Windows-приложения. Завершить приложение можно и программно, вызвав в нужный момент статический метод Exit класса Application. Закрытие других форм не приводит к завершению проекта. Зачастую главная форма проекта всегда открыта, в то время как остальные формы открываются и закрываются (скрываются). Если мы хотим, чтобы в каждый текущий момент была открыта только одна форма, то нужно принять определенные меры, чтобы при закрытии (скрытии) формы открывалась другая. Иначе возможна клинчевая ситуация - все формы закрыты, предпринять ничего нельзя, а приложение не завершено. Конечно, выход всегда есть - всегда можно нажать магическую тройку клавиш CTRL+ALT+DEL и завершить любое приложение.
Можно создавать формы как объекты класса Form. Однако такие объекты довольно редки. Чаще всего создается специальный класс FormX - наследник класса Form. Так, в частности, происходит в Windows-приложении, создаваемом по умолчанию, когда создается класс Form1 - наследник класса Form. Так происходит в режиме проектирования, когда в проект добавляется новая форма с использованием пункта меню Add Windows Form. Как правило, каждая форма в проекте - это объект собственного класса. Возможна ситуация, когда вновь создаваемая форма во многом должна быть похожей на уже существующую, и тогда класс новой формы может быть сделан наследником класса формы существующей. Наследование форм мы рассмотрим подробнее чуть позже.

Windows-проект

Проделаем аналогичную работу: построим Windows-проект, рассмотрим, как он выглядит по умолчанию, а затем дополним его до проектa "Приветствие". Повторяя уже описанные действия, в окне нового проектa (см. рис. 2.1) я выбрал тип проектa Windows Application, дав проектy имя WindowsHello.
Как и в консольном случае, по умолчанию строится решение, содержащее единственный проект, содержащий единственное пространство имен (все три конструкции имеют совпадающие имена). В пространство имен вложен единственный класс Form1, но это уже далеко не столь простой класс, как ранее. Вначале приведу его код, а потом уже дам необходимые пояснения:
using System; using System.Drawing; using System.Collections; using System.ComponentModel; using System.Windows.Forms; using System.Data; namespace WindowsHello { ///

/// Summary description for Form1. ///

public class Form1 : System.Windows.Forms.Form { ///

/// Required designer variable. ///

private System.ComponentModel.Container components = null; public Form1() { // Required for Windows Form Designer support InitializeComponent(); // TODO: Add any constructor code after // InitializeComponent call } ///

/// Clean up any resources being used. ///

protected override void Dispose( bool disposing ) { if( disposing ) { if (components != null) { components.Dispose(); } } base.Dispose( disposing ); } #region Windows Form Designer generated code ///

/// Required method for Designer support - do not modify /// the contents of this method with the code editor. ///

private void InitializeComponent() { this.components = new System.ComponentModel.Container(); this.Size = new System.Drawing.Size(300,300); this.Text = "Form1"; } #endregion ///

/// The main entry point for the application. ///

[STAThread] static void Main() { Application.Run(new Form1()); } } }
Начну с того, что теперь пространству имен предшествует 6 предложений using; это означает, что используются не менее 6-ти классов, находящихся в разных пространствах имен библиотеки FCL. Одним из таких используемых классов является класс Form из глубоко вложенного пространства имен System.Windows.Forms. Построенный по умолчанию класс Form1 является наследником класса Form и автоматически наследует его функциональность - свойства, методы, события. При создании объекта этого класса, характеризующего форму, одновременно Visual Studio создает визуальный образ объекта - окно, которое можно заселять элементами управления. В режиме проектирования эти операции можно выполнять вручную, при этом автоматически происходит изменение программного кода класса. Появление в проектe формы, открывающейся по умолчанию при запуске проектa, означает переход к визуальному, управляемому событиями программированию. Сегодня такой стиль является общепризнанным, а стиль консольного приложения следует считать анахронизмом, правда, весьма полезным при изучении свойств языка.
В класс Form1 встроено закрытое (private) свойство - объект components класса Container. В классе есть конструктор, вызывающий закрытый метод класса InitializeComponent. В классе есть деструктор, освобождающий занятые ресурсы, которые могут появляться при добавлении элементов в контейнер components. Наконец, в классе есть точка входа - процедура Main с непустым телом.

Захват исключения

Блок catch - обработчик исключения имеет следующий синтаксис:
catch (T e) {...}
Класс T, указанный в заголовке catch-блока, должен принадлежать классам исключений. Блок catch с формальным аргументом e класса T потенциально способен захватить текущее исключение te класса TE, если и только если объект te совместим по присваиванию c объектом e. Другими словами, потенциальная способность захвата означает допустимость присваивания e = te, что возможно, когда класс TE является потомком класса T. Обработчик, класс T которого является классом Exception, является универсальным обработчиком, потенциально он способен захватить любое исключение, поскольку все они являются его потомками.
Потенциальных захватчиков может быть много, исключение захватывает лишь один - тот из них, кто стоит первым в списке проверки. Каков порядок проверки? Он довольно естественный. Вначале проверяются обработчики в порядке следования их за try-блоком, и первый потенциальный захватчик становится активным, захватывая исключение и выполняя его обработку. Отсюда становится ясно, что порядок следования в списке catch-блоков крайне важен. Первыми идут наиболее специализированные обработчики, далее по мере возрастания универсальности. Так, вначале должен идти обработчик исключения DivideByZeroException, а уже за ним -ArithmeticException. Универсальный обработчик, если он есть, должен стоять последним. За этим наблюдает статический контроль типов. Если потенциальных захватчиков в списке catch-блоков нет (сам список может отсутствовать), то происходит переход к списку обработчиков охватывающего блока. Напомню, что try-блок может быть вложен в другой try-блок. Когда же будет исчерпаны списки вложенных блоков, а потенциальный захватчик не будет найден, то произойдет подъем по стеку вызовов. На рис. 23.5 показана цепочка вызовов, начинающаяся с точки "большого взрыва" - процедуры Main.

Рис. 23.5.  Цепочка вызовов, хранящаяся в стеке вызовов

О точке большого взрыва и цепочке вызовов мы говорили еще в лекции 2.

Исключение возникло в последнем вызванном методе цепочки - на рисунке метод r5. Если у этого метода не нашлось обработчиков события, способных обработать исключение, то это пытается сделать метод r4, вызвавший r5. Если вызов r5 находится в охраняемом блоке метода r4, то начнет проверяться список обработчиков в охраняемом блоке метода r4. Этот процесс подъема по списку вызовов будет продолжаться, пока не будет найден обработчик, способный захватить исключение, или не будет достигнута начальная точка - процедура Main. Если и в ней нет потенциального захватчика исключения, то сработает стандартный обработчик, прерывающий выполнение программы с выдачей соответствующего сообщения.

Закрытый метод НОД

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

/// Закрытый метод класса. /// Возвращает наибольший общий делитель чисел a,b ///

/// первое число /// второе число, положительное /// НОД(a,b) int nod(int m, int n) { int p=0; m=Math.Abs(m); n =Math.Abs(n); if(n>m){p=m; m=n; n=p;} do { p = m%n; m=n; n=p; }while (n!=0); return(m); }//nod

Жизненный цикл программной системы

Под "жизненным циклом" понимается период от замысла программного продукта до его "кончины". Обычно рассматриваются следующие фазы этого процесса:
Проектирование <-> Разработка <-> Развертывание и Сопровождение
Все это называется циклом, поскольку после каждой фазы возможен возврат к предыдущим этапам. В объектной технологии этот процесс является бесшовным, все этапы которого тесно переплетены. Не следует рассматривать его как однонаправленный - от проектирования к сопровождению. Чаще всего, ситуация обратная: уже существующая реализация системы, прошедшая сопровождение, и существующие библиотеки компонентов оказывают решающее влияние на то, какой будет новая система, каковы будут ее спецификации.
Вот некоторые типовые правила, характерные для процесса разработки ПО:

• Уделяйте этапу проектирования самое пристальное внимание. Успех дела во многом определяется первым этапом. Нет смысла торопиться с переходом на последующие этапы, пока не составлены ясные и четкие спецификации. Ошибки этого этапа - самые дорогие и трудно исправляемые.
• Помните о тех, для кого разрабатывается программный продукт. Идите "в люди", чтобы понять, что нужно делать. Вместе с тем, не следует полностью полагаться на пользователей - их опыт консервативен, новые идеи могут часто приходить от разработчиков, а не от пользователей.
• Разработка не начинается "с нуля". Только используя уже готовые компоненты, можно своевременно создать новую систему. Работая над проектом, думайте о будущем, создавайте компоненты, допускающие их повторное использование в других проектах.
• Создавайте как можно раньше прототип своей системы и передавайте его пользователям в опытную эксплуатацию. Это поможет устранить множество недостатков и ошибок в заключительной версии программного продукта.
• Какие бы хорошие спецификации не были написаны, какими бы хорошими технологиями и инструментами не пользовались разработчики, какими бы профессионалами они ни были - этого еще не достаточно для успеха дела. Необходимым условием является управление проектом, наличие специальных средств управления. Но и этого не достаточно. Третьим важным фактором является существование команды. Коллектив разработчиков должен представлять собой единый коллектив. Умение работать в команде так же важно, как и профессиональные навыки разработчика.

Знакомство с классами пространства RegularExpressions

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




---

---