Око и рококо"
Следующий образец в нашем примере позволяет прояснить некоторые особенности работы метода 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 { /// <summary> /// Класс Testing включает данные разных типов. Каждый его /// открытый метод описывает некоторый пример, /// демонстрирующий работу с типами. /// Открытые методы могут вызывать закрытые методы класса. /// </summary> public class Testing { /// <summary> /// набор скалярных данных разного типа. /// </summary> 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. Процедура выводит на консоль переданное ей имя аргумента, его тип и значение. Вот ее текст:
/// <summary> /// Метод выводит на консоль информацию о типе и /// значении фактического аргумента. Формальный /// аргумент имеет тип object. Фактический аргумент /// может иметь любой тип, поскольку всегда /// допустимо неявное преобразование в тип object. /// </summary> /// <param name="name"> - Имя второго аргумента</param> /// <param name="any"> - Допустим аргумент любого типа</param> void WhoIsWho(string name, object any) { Console.WriteLine("type {0} is {1} , value is {2}", name, any.GetType(), any.ToString()); }
Вот открытый (public) метод класса Testing, в котором многократно вызывается метод WhoIsWho с аргументами разного типа:
/// <summary> /// получаем информацию о типе и значении /// переданного аргумента - переменной или выражения /// </summary> 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
Примеры работы с регулярными выражениями
Полагаю, что примеры дополнят краткое описание возможностей регулярных выражений и позволят лучше понять, как с ними работать. Начну с функции 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
в лекции 14. Здесь они
Некоторые комментарии к этой процедуре.
Регулярные выражения задаются @-константами, описанными в лекции 14. Здесь они как нельзя кстати.
В первом образце используется последовательность символов \w+, обозначающая, как следует из таблицы 15.1, непустую последовательность латиницы и цифр. В совокупности образец задает подстроку, начинающуюся символом a, за которым следуют буквы или цифры (хотя бы одна). Этот образец применяется к двум различным строкам.
В следующем образце используется символ * для обозначения итерации. В целом регулярное выражение задает строки, начинающиеся с символа a и заканчивающиеся символом f, между которыми находится возможно пустая последовательность символов из b и d.
Последующие два образца демонстрируют использование диапазонов и escape-последовательностей для представления символов, заданных кодами (в Unicode и шестнадцатиричной кодировке).
Взгляните на результаты, полученные при работе этой процедуры.
Рис. 15.1. Регулярные выражения. Поиск по образцу
Приоритет и порядок выполнения операций
Большинство операций в языке 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# оно толкуется как операция, используемая в выражениях. Однако в большинстве случаев присваивание следует рассматривать и использовать как обычный оператор.
Возьмем полезный случай реального использования присваивания как операции. В ситуации, называемой множественным присваиванием, списку переменных присваивается одно и тоже значение. Вот пример:
/// <summary> /// анализ присваивания /// </summary> 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 /// <summary> /// Required method for Designer support - do not /// modify the contents of this method with the code /// editor. /// </summary> 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
Заметьте, в теге <summary> нас предупреждают, что этот метод требуется специальному инструментарию - Дизайнеру формы - и он не предназначен для редактирования пользователем; добавление и удаление кода этого метода производится автоматически. Обращаю внимание, что после заполнения свойств элементов управления заключительным шагом является их добавление в коллекцию 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, описывающего известный в математике тип данных - рациональные числа. По ходу проектирования будут вводиться новые детали, связанные с описанием класса. Начнем проектирование, как обычно, с задания тега <summary>, описывающего назначение класса, его свойства и поведение. Вот этот текст:
/// <summary> /// Класс Rational /// определяет новый тип данных - рациональные числа и /// основные операции над ними - сложение, умножение, /// вычитание и деление. Рациональное число задается парой /// целых чисел (m,n) и изображается обычно в виде дроби m/n. /// Число m называется числителем,n - знаменателем. Для /// каждого рационального числа существует множество его /// представлений, например, 1/2, 2/4, 3/6, 6/12 - задают /// одно и тоже рациональное число. Среди всех представлений /// можно выделить то, в котором числитель и знаменатель /// взаимно несократимы. Такой представитель будет храниться /// в полях класса. Операции над рациональными числами /// определяются естественным для математики образом /// </summary> public class Rational { // Описание тела класса Rational }//Rational
Пространство имен RegularExpression и классы регулярных выражений
Стандартный класс String позволяет выполнять над строками различные операции, в том числе поиск, замену, вставку и удаление подстрок. Существуют специальные операции, такие как Join, Split, которые облегчают разбор строки на элементы. Тем не менее, есть классы задач по обработке символьной информации, где стандартных возможностей явно не хватает. Чтобы облегчить решение подобных задач, в Net Framework встроен более мощный аппарат работы со строками, основанный на регулярных выражениях. Специальное пространство имен RegularExpression, содержит набор классов, обеспечивающих работу с регулярными выражениями. Все классы этого пространства доступны для C# и всех языков, использующих каркас Net Framework. В основе регулярных выражений лежит хорошая теория и хорошая практика их применения. Полное описание, как теоретических основ, так и практических особенностей применения этого аппарата в C#, требует отдельной книги. Придется ограничиться введением в эту интересную область работы со строками, не рассматривая подробно все классы, входящие в пространство имен RegularExpression.
Проверяемые преобразования
Уже упоминалось о том, что при выполнении явных преобразований могут возникать нежелательные явления, например, потеря точности. Я говорил, что вся ответственность за это ложится на программиста, и легче ему от этого не становится. А какую часть этого бремени может взять на себя язык программирования? Что можно предусмотреть для обнаружения ситуаций, когда такие явления все-таки возникают? В языке C# имеются необходимые для этого средства.
Язык C# позволяет создать проверяемый блок, в котором будет осуществляться проверка результата вычисления арифметических выражений. Если результат вычисления значения источника выходит за диапазон возможных значений целевой переменной, то возникнет исключение (говорят также: "будет выброшено исключение") соответствующего типа. Если предусмотрена обработка исключения, то дальнейшее зависит от обработчика исключения. В лучшем случае, программа сможет продолжить корректное выполнение. В худшем, - она остановится и выдаст информацию об ошибке. Заметьте, не произойдет самого опасного - продолжения работы программы с неверными данными.
Синтаксически проверяемый блок предваряется ключевым словом checked. В теле такого блока арифметические преобразования проверяются на допустимость. Естественно, подобная проверка требует дополнительных временных затрат. Если группа операторов в теле такого блока нам кажется безопасной, то их можно выделить в непроверяемый блок, используя ключевое слово unchecked. Замечу еще, что и в непроверяемом блоке при работе методов Convert все опасные преобразования проверяются и приводят к выбрасыванию исключений. Приведу пример, демонстрирующий все описанные ситуации:
/// <summary> /// Демонстрация проверяемых и непроверяемых преобразований. /// Опасные проверяемые преобразования приводят к исключениям. /// Опасные непроверяемые преобразования приводят к неверным /// результатам, что совсем плохо. /// </summary> 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. Рекурсивный вариант реализует описанную выше идею алгоритма:
/// <summary> /// Перенос count колец с tower1 на tower2, соблюдая /// правила и используя tower3. Свободные вершины /// башен - top1, top2, top3 /// </summary> 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<T>, введенному в начале этой лекции, и породим на его основе вполне конкретный класс IntStack, заменив формальный параметр T фактическим - int. Для этого достаточно задать следующее предложение using:
using IntStack = Generic.OneLinkStack<int>;
Вот тест, в котором создаются несколько объектов этого класса:
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# в последующих лекциях. Исполнительная среда, не ограничивая возможности языка и программистов, вводит определенную дисциплину в применении потенциально опасных средств языков программирования.
Семантика присваивания
Рассмотрим присваивание:
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, то фактический аргумент может быть выражением любого типа.
Семантика присваивания. Преобразования между ссылочными и значимыми типами
Рассматривая семантику присваивания и передачи аргументов, мы обошли молчанием один важный вопрос. Будем называть целью левую часть оператора присваивания, а также формальный аргумент при передаче аргументов в процедуру или функцию. Будем называть источником правую часть оператора присваивания, а также фактический аргумент при передаче аргументов в процедуру или функцию. Поскольку источник и цель могут быть как значимого, так и ссылочного типа, то возможны четыре различные комбинации. Рассмотрим их подробнее.
Цель и источник значимого типа. Здесь наличествует семантика значимого присваивания. В этом случае источник и цель имеют собственную память для хранения значений. Значения источника заменяют значения соответствующих полей цели. Источник и цель после этого продолжают жить независимо. У них своя память, хранящая после присваивания одинаковые значения.Цель и источник ссылочного типа. Здесь имеет место семантика ссылочного присваивания. В этом случае значениями источника и цели являются ссылки на объекты, хранящиеся в памяти ("куче"). При ссылочном присваивании цель разрывает связь с тем объектом, на который она ссылалась до присваивания, и становится ссылкой на объект, связанный с источником. Результат ссылочного присваивания двоякий. Объект, на который ссылалась цель, теряет одну из своих ссылок и может стать висячим, так что его дальнейшую судьбу определит сборщик мусора. С объектом в памяти, на который ссылался источник, теперь связываются, по меньшей мере, две ссылки, рассматриваемые как различные имена одного объекта. Ссылочное присваивание приводит к созданию псевдонимов - к появлению разных имен у одного объекта. Особо следует учитывать ситуацию, когда цель и/или источник имеет значение void. Если такое значение имеет источник, то в результате присваивания цель получает это значение и более не ссылается ни на какой объект. Если же цель имела значение void, а источник - нет, то в результате присваивания ранее "висячая" цель становится ссылкой на объект, связанный с источником.Цель ссылочного типа, источник значимого типа. В этом случае "на лету" значимый тип преобразуется в ссылочный. Как обеспечивается двойственность существования значимого и ссылочного типа - переменной и объекта? Ответ прост: за счет специальных, эффективно реализованных операций, преобразующих переменную значимого типа в объект и обратно. Операция "упаковать" (boxing) выполняется автоматически и неявно в тот момент, когда по контексту требуется объект, а не переменная. Например, при вызове процедуры WhoIsWho требуется, чтобы аргумент any был объектом. Если фактический аргумент является переменной значимого типа, то автоматически выполняется операция "упаковать". При ее выполнении создается настоящий объект, хранящий значение переменной. Можно считать, что происходит упаковка переменной в объект. Необходимость в упаковке возникает достаточно часто. Примером может служить и процедура консольного вывода WriteLine класса Console, которой требуются объекты, а передаются зачастую переменные значимого типа.Цель значимого типа, источник ссылочного типа. В этом случае "на лету" ссылочный тип преобразуется в значимый. Операция "распаковать" (unboxing) выполняет обратную операцию, - она "сдирает" объектную упаковку и извлекает хранимое значение. Заметьте, операция "распаковать" не является обратной к операции "упаковать" в строгом смысле этого слова. Оператор obj = x корректен, но выполняемый следом оператор x = obj приведет к ошибке. Недостаточно, чтобы хранимое значение в упакованном объекте точно совпадало по типу с переменной, которой присваивается объект. Необходимо явно заданное преобразование к нужному типу.
Сериализация объектов
При работе с программной системой зачастую возникает необходимость в сериализации объектов. Под сериализацией понимают процесс сохранения объектов в долговременной памяти (файлах) в период выполнения системы. Под десериализацией понимают обратный процесс - восстановление состояния объектов, хранимых в долговременной памяти. Механизмы сериализации 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<T1, T2> { } public class Base { public void M1() { } public void M2() { } } public class Child<T1,T2> :Father<T1,T2> where T1:Base,IEnumerable<T1>, new() where T2:struct,IComparable<T2> { }
Класс Child с ограниченной универсальностью к данным типа T1 имеет право применять методы M1 и M2 базового класса Base; так же, как и методы интерфейса IEnumerable<T1>, он может создавать объекты типа T1, используя конструктор по умолчанию. Фактический тип, подставляемый вместо формального типа T2, должен быть значимым, и объекты этого типа разрешается сравнивать между собой.
Синтаксис регулярных выражений
Регулярное выражение на C# задается строковой константой. Это может быть обычная или @-константа. Чаще всего, следует использовать именно @-константу. Дело в том, что символ "\" широко применяется в регулярных выражениях как для записи escape-последовательностей, так и в других ситуациях. Обычные константы в таких случаях будут выдавать синтаксическую ошибку, а @-константы не выдают ошибок и корректно интерпретируют запись регулярного выражения.
Синтаксис регулярного выражения простой формулой не описать, здесь используются набор разнообразных средств:
символы и escape-последовательности;символы операций и символы, обозначающие специальные классы множеств;имена групп и обратные ссылки;символы утверждений и другие средства.
Конечно, регулярное выражение может быть совсем простым, например, строка "abc" задает образец поиска, так что при вызове соответствующего метода будут разыскиваться одно или все вхождения подстроки "abc" в искомую строку. Но могут существовать и очень сложно устроенные регулярные выражения. Приведу таблицу, (15.1) в которой дается интерпретация символов в соответствии с их делением на группы. Таблица не полна, в ней отражаются не все группы, а описание группы не содержит всех символов. Она позволяет дать общее представление о синтаксисе, которое будет дополнено большим числом примеров. За деталями придется обращаться к справочной системе, которая, к сожалению, далеко не идеальна для данного раздела.
Повторяю, данная таблица не полна. В ней не отражены, например, такие категории, как подстановки, обратные ссылки, утверждения.
Для приведенных категорий также не дан полный список возможных символов.
| \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>) | При обнаружении соответствия выражению, заданному в круглых скобках, создается именованная группа, которой дается имя Name. Например, (?<tel> \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<T1, ... Tn> {...}
Как и всякие формальные параметры, Ti являются именами (идентификаторами). В теле класса эти имена могут задавать типы некоторых полей класса, типы аргументов и возвращаемых значений методов класса. В некоторый момент (об этом скажем чуть позже) формальные имена типов будут заменены фактическими параметрами, представляющими уже конкретные типы - имена встроенных классов, классов библиотеки FCL, классов, определенных пользователем.
В C# универсальными могут быть как классы, так и все их частные случаи - интерфейсы, структуры, делегаты, события.
Система типов
Давайте рассмотрим, как устроена система типов в языке C#, но вначале для сравнения приведу классификацию типов в стандарте языка C++.
Стандарт языка C++ включает следующий набор фундаментальных типов.
Логический тип (bool).Символьный тип (char).Целые типы. Целые типы могут быть одного из трех размеров - short, int, long, сопровождаемые описателем signed или unsigned, который указывает, как интерпретируется значение, - со знаком или без оного.Типы с плавающей точкой. Эти типы также могут быть одного из трех размеров - float, double, long double.
Кроме того, в языке есть
Тип void, используемый для указания на отсутствие информации.
Язык позволяет конструировать типы.
Указатели (например, int* - типизированный указатель на переменную типа int).Ссылки (например, double& - типизированная ссылка на переменную типа double).Массивы (например, char[] - массив элементов типа char).
Язык позволяет конструировать пользовательские типы
Перечислимые типы (enum) для представления значений из конкретного множества.Структуры (struct).Классы.
Первые три вида типов называются интегральными или счетными. Значения их перечислимы и упорядочены. Целые типы и типы с плавающей точкой относятся к арифметическому типу. Типы подразделяются также на встроенные и типы, определенные пользователем.
Эта схема типов сохранена и в языке C#. Однако здесь на верхнем уровне используется и другая классификация, носящая для C# принципиальный характер. Согласно этой классификации все типы можно разделить на четыре категории:
Типы-значения (value), или значимые типы.Ссылочные (reference).Указатели (pointer).Тип 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 | Прародитель всех встроенных и пользовательских типов | |
Событие 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 позволяют решать самые разнообразные задачи:
Copy - позволяет копировать весь массив или его часть в другой массив.IndexOf, LastIndexOf - определяют индексы первого и последнего вхождения образца в массив, возвращая -1, если такового вхождения не обнаружено.Reverse - выполняет обращение массива, переставляя элементы в обратном порядке.Sort - осуществляет сортировку массива.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
| 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 | Размерность массива |
| 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. Форма с меню и инструментальной панелью
