Основы программирования на C#
         

Класс Array


Нельзя понять многие детали работы с массивами в C#, если не знать устройство класса Array из библиотеки FCL, потомками которого являются все классы-массивы. Рассмотрим следующие объявления:

//Класс Array int[] ar1 = new int[5]; double[] ar2 ={5.5, 6.6, 7.7}; int[,] ar3 = new Int32[3,4];

Зададимся естественным вопросом: к какому или к каким классам принадлежат объекты ar1, ar2 и ar3? Ответ прост: все они принадлежат к разным классам. Переменная ar1 принадлежит к классу int[] - одномерному массиву значений типа int, ar2 - double[] - одномерному массиву значений типа double, ar3 - двумерному массиву значений типа int. Следующий закономерный вопрос: а что общего есть у этих трех объектов? Прежде всего, все три класса этих объектов, как и другие классы, являются потомками класса Object, а потому имеют общие методы, наследованные от класса Object и доступные объектам этих классов.

У всех классов, являющихся массивами, много общего, поскольку все они являются потомками класса System.Array. Класс System.Array наследует ряд интерфейсов: ICloneable, IList, ICollection, IEnumerable, а, следовательно, обязан реализовать все их методы и свойства. Помимо наследования свойств и методов класса Object и вышеперечисленных интерфейсов, класс Array имеет довольно большое число собственных методов и свойств. Взгляните, как выглядит отношение наследования на семействе классов, определяющих массивы.


Рис. 12.1.  Отношение наследования на классах-массивах

Благодаря такому мощному родителю, над массивами определены самые разнообразные операции - копирование, поиск, обращение, сортировка, получение различных характеристик. Массивы можно рассматривать как коллекции и устраивать циклы For Each для перебора всех элементов. Важно и то, что когда у семейства классов есть общий родитель, то можно иметь общие процедуры обработки различных потомков этого родителя. Для общих процедур работы с массивами характерно, что один или несколько формальных аргументов имеют родительский тип Array. Естественно, внутри такой процедуры может понадобиться анализ - какой реальный тип массива передан в процедуру.

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

public static void PrintAr(string name, Array A) { Console.WriteLine(name); switch (A.Rank) { case 1: for(int i = 0; i<A.GetLength(0);i++) Console.Write("\t" + name + "[{0}]={1}", i, A.GetValue(i)); Console.WriteLine(); break; case 2: for(int i = 0; i<A.GetLength(0);i++) { for(int j = 0; j<A.GetLength(1);j++) Console.Write("\t" + name + "[{0},{1}]={2}", i,j, A.GetValue(i,j)); Console.WriteLine(); } break; default: break; } }//PrintAr




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

public void TestCommonPrint() { //Класс Array int[] ar1 = new int[5]; double[] ar2 ={5.5, 6.6, 7.7}; int[,] ar3 = new Int32[3,4]; Arrs.CreateOneDimAr(ar1);Arrs.PrintAr("ar1", ar1); Arrs.PrintAr("ar2", ar2); Arrs.CreateTwoDimAr(ar3);Arrs.PrintAr("ar3", ar3); }//TestCommonPrint

Вот результаты вывода массивов ar1, ar2 и ar3.


Рис. 12.2.  Печать массивов. Результаты работы процедуры PrintAr

Приведу некоторые комментарии.

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

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

К элементам массива A, имеющего класс Array, нет возможности прямого доступа в обычной манере - A [<индексы>], но зато есть специальные методы GetValue (<индексы>) и SetValue (<индексы>).

Естественно, разбор случаев можно продолжить, придав процедуре большую функциональность.

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


Класс Brush


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

SolidBrush - для сплошной закраски области заданным цветом;TextureBrush - для закраски области заданной картинкой (image);HatchBrush - для закраски области предопределенным узором;LinearGradientBrush - для сплошной закраски с переходом от одного цвета к другому, где изменение оттенков задается линейным градиентом;PathGradientBrush - для сплошной закраски с переходом от одного цвета к другому, где изменение оттенков задается более сложным путем.

Первые два класса кистей находятся в пространстве имен System.Drawing, остальные - в System.Drawing.Drawing2D.

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



Класс char


В C# есть символьный класс Char, основанный на классе System.Char и использующий двухбайтную кодировку Unicode представления символов. Для этого типа в языке определены символьные константы - символьные литералы. Константу можно задавать:

символом, заключенным в одинарные кавычки;escape-последовательностью, задающей код символа;Unicode-последовательностью, задающей Unicode-код символа.

Вот несколько примеров объявления символьных переменных и работы с ними:

public void TestChar() { char ch1='A', ch2 ='\x5A', ch3='\u0058'; char ch = new Char(); int code; string s; ch = ch1; //преобразование символьного типа в тип int code = ch; ch1=(char) (code +1); //преобразование символьного типа в строку //s = ch; s = ch1.ToString()+ch2.ToString()+ch3.ToString(); Console.WriteLine("s= {0}, ch= {1}, code = {2}", s, ch, code); }//TestChar

Три символьные переменные инициализированы константами, значения которых заданы тремя разными способами. Переменная ch объявляется в объектном стиле, используя new и вызов конструктора класса. Тип char, как и все типы C#, является классом. Этот класс наследует свойства и методы класса Object и имеет большое число собственных методов.

Существуют ли преобразования между классом char и другими классами? Явные или неявные преобразования между классами char и string отсутствуют, но, благодаря методу ToString, переменные типа char стандартным образом преобразуются в тип string. Как отмечалось в лекции 3, существуют неявные преобразования типа char в целочисленные типы, начиная с типа ushort. Обратные преобразования целочисленных типов в тип char также существуют, но они уже явные.

В результате работы процедуры TestChar строка s, полученная сцеплением трех символов, преобразованных в строки, имеет значение BZX, переменная ch равна A, а ее код - переменная code - 65.

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

public int SayCode(char sym) { return (sym); }//SayCode




public char SaySym(object code) { return ((char)((int)code)); }// SaySym

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

Таблица 13.1. Статические методы и свойства класса CharМетодОписание
GetNumericValueВозвращает численное значение символа, если он является цифрой, и (-1) в противном случае
GetUnicodeCategoryВсе символы разделены на категории. Метод возвращает Unicode категорию символа. Ниже приведен пример
IsControlВозвращает true, если символ является управляющим
IsDigitВозвращает true, если символ является десятичной цифрой
IsLetterВозвращает true, если символ является буквой
IsLetterOrDigitВозвращает true, если символ является буквой или цифрой
IsLowerВозвращает true, если символ задан в нижнем регистре
IsNumberВозвращает true, если символ является числом (десятичной или шестнадцатиричной цифрой)
IsPunctuationВозвращает true, если символ является знаком препинания
IsSeparatorВозвращает true, если символ является разделителем
IsSurrogateНекоторые символы Unicode с кодом в интервале [0x1000, 0x10FFF] представляются двумя 16-битными "суррогатными" символами. Метод возвращает true, если символ является суррогатным
IsUpperВозвращает true, если символ задан в верхнем регистре
IsWhiteSpaceВозвращает true, если символ является "белым пробелом". К белым пробелам, помимо пробела, относятся и другие символы, например, символ конца строки и символ перевода каретки
ParseПреобразует строку в символ. Естественно, строка должна состоять из одного символа, иначе возникнет ошибка
ToLowerПриводит символ к нижнему регистру
ToUpperПриводит символ к верхнему регистру
MaxValue, MinValueСвойства, возвращающие символы с максимальным и минимальным кодом. Возвращаемые символы не имеют видимого образа




Класс Char, как и все классы в C#, наследует свойства и методы родительского класса Object. Но у него есть и собственные методы и свойства, и их немало. Сводка этих методов приведена в таблице 13.1.

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

public void TestCharMethods() { Console.WriteLine("Статические методы класса char:"); char ch='a', ch1='1', lim =';', chc='\xA'; double d1, d2; d1=char.GetNumericValue(ch); d2=char.GetNumericValue(ch1); Console.WriteLine("Метод GetNumericValue:"); Console.WriteLine("sym 'a' - value {0}", d1); Console.WriteLine("sym '1' - value {0}", d2); System.Globalization.UnicodeCategory cat1, cat2; cat1 =char.GetUnicodeCategory(ch1); cat2 =char.GetUnicodeCategory(lim); Console.WriteLine("Метод GetUnicodeCategory:"); Console.WriteLine("sym '1' - category {0}", cat1); Console.WriteLine("sym ';' - category {0}", cat2); Console.WriteLine("Метод IsControl:"); Console.WriteLine("sym '\xA' - IsControl - {0}", char.IsControl(chc)); Console.WriteLine("sym ';' - IsControl - {0}", char.IsControl(lim)); Console.WriteLine("Метод IsSeparator:"); Console.WriteLine("sym ' ' - IsSeparator - {0}", char.IsSeparator(' ')); Console.WriteLine("sym ';' - IsSeparator - {0}", char.IsSeparator(lim)); Console.WriteLine("Метод IsSurrogate:"); Console.WriteLine("sym '\u10FF' - IsSurrogate - {0}", char.IsSurrogate('\u10FF')); Console.WriteLine("sym '\\' - IsSurrogate - {0}", char.IsSurrogate('\\')); string str = "\U00010F00"; //Символы Unicode в интервале [0x10000,0x10FFF] //представляются двумя 16-битными суррогатными символами Console.WriteLine("str = {0}, str[0] = {1}", str, str[0]); Console.WriteLine("str[0] IsSurrogate - {0}", char.IsSurrogate(str, 0)); Console.WriteLine("Метод IsWhiteSpace:"); str ="пробелы, пробелы!" + "\xD" + "\xA" + "Всюду пробелы!"; Console.WriteLine("sym '\xD ' - IsWhiteSpace - {0}", char.IsWhiteSpace('\xD')); Console.WriteLine("str: {0}", str); Console.WriteLine("и ее пробелы - символ 8 {0},символ 17 {1}", char.IsWhiteSpace(str,8), char.IsWhiteSpace(str,17)); Console.WriteLine("Метод Parse:"); str="A"; ch = char.Parse(str); Console.WriteLine("str:{0} char: {1}",str, ch); Console.WriteLine("Минимальное и максимальное значение:{0}, {1}", char.MinValue.ToString(), char.MaxValue.ToString()); Console.WriteLine("Их коды: {0}, {1}", SayCode(char.MinValue), SayCode(char.MaxValue)); }//TestCharMethods



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


Рис. 13.1.  Вызовы статических методов класса char

Кроме статических методов, у класса Char есть и динамические. Большинство из них - это методы родительского класса Object, унаследованные и переопределенные в классе Char. Из собственных динамических методов стоит отметить метод CompareTo, позволяющий проводить сравнение символов. Он отличается от метода Equal тем, что для несовпадающих символов выдает "расстояние" между символами в соответствии с их упорядоченностью в кодировке Unicode. Приведу пример:

public void testCompareChars() { char ch1, ch2; int dif; Console.WriteLine("Метод CompareTo"); ch1='A'; ch2= 'Z'; dif = ch1.CompareTo(ch2); Console.WriteLine("Расстояние между символами {0}, {1} = {2}", ch1, ch2, dif); ch1='а'; ch2= 'А'; dif = ch1.CompareTo(ch2); Console.WriteLine("Расстояние между символами {0}, {1} = {2}", ch1, ch2, dif); ch1='Я'; ch2= 'А'; dif = ch1.CompareTo(ch2); Console.WriteLine("Расстояние между символами {0}, {1} = {2}", ch1, ch2, dif); ch1='A'; ch2= 'A'; dif = ch1.CompareTo(ch2); Console.WriteLine("Расстояние между символами {0}, {1} = {2}", ch1, ch2, dif); ch1='А'; ch2= 'A'; dif = ch1.CompareTo(ch2); Console.WriteLine("Расстояние между символами {0}, {1} = {2}", ch1, ch2, dif); ch1='Ё'; ch2= 'А'; dif = ch1.CompareTo(ch2); Console.WriteLine("Расстояние между символами {0}, {1} = {2}", ch1, ch2, dif); }//TestCompareChars

Результаты сравнения изображены на рис. 13.2.


Рис. 13.2.  Сравнение символов

Анализируя эти результаты, можно понять, что в кодировке Unicode как латиница, так и кириллица плотно упакованы. Исключение составляет буква Ё - заглавная и малая - они выпадают из плотной кодировки. Малые буквы в кодировке непосредственно следуют за заглавными буквами. Расстояние между алфавитами в кодировке довольно большое - русская буква А на 975 символов правее в кодировке, чем соответствующая буква в латинском алфавите.


Класс char[] - массив символов


В языке C# определен класс Char[], и его можно использовать для представления строк постоянной длины, как это делается в С++. Более того, поскольку массивы в C# динамические, то расширяется класс задач, в которых можно использовать массивы символов для представления строк. Так что имеет смысл разобраться, насколько хорошо C# поддерживает работу с таким представлением строк.

Прежде всего, ответим на вопрос, задает ли массив символов C# строку С, заканчивающуюся нулем? Ответ: нет, не задает. Массив char[] - это обычный массив. Более того, его нельзя инициализировать строкой символов, как это разрешается в С++. Константа, задающая строку символов, принадлежит классу String, а в C# не определены взаимные преобразования между классами String и Char[], даже явные. У класса String есть, правда, динамический метод ToCharArray, задающий подобное преобразование. Возможно также посимвольно передать содержимое переменной string в массив символов. Приведу пример:

public void TestCharArAndString() { //массивы символов //char[] strM1 = "Hello, World!"; //ошибка: нет преобразования класса string в класс char[] string hello = "Здравствуй, Мир!"; char[] strM1 = hello.ToCharArray(); PrintCharAr("strM1",strM1); //копирование подстроки char[] World = new char[3]; Array.Copy(strM1,12,World,0,3); PrintCharAr("World",World); Console.WriteLine(CharArrayToString(World)); }//TestCharArAndString

Закомментированные операторы в начале этой процедуры показывают, что прямое присваивание строки массиву символов недопустимо. Однако метод ToCharArray, которым обладают строки, позволяет легко преодолеть эту трудность. Еще одну возможность преобразования строки в массив символов предоставляет статический метод Copy класса Array.

В нашем примере часть строки strM1 копируется в массив World. По ходу дела в методе вызывается процедура PrintCharAr класса Testing, печатающая массив символов как строку. Вот ее текст:

void PrintCharAr(string name,char[] ar) { Console.WriteLine(name); for(int i=0; i < ar.Length; i++) Console.Write(ar[i]); Console.WriteLine(); }//PrintCharAr




Метод ToCharArray позволяет преобразовать строку в массив символов. К сожалению, обратная операция не определена, поскольку метод ToString, которым, конечно же, обладают все объекты класса Char[], печатает информацию о классе, а не содержимое массива. Ситуацию легко исправить, написав подходящую процедуру. Вот текст этой процедуры CharArrayToString, вызываемой в нашем тестирующем примере:

string CharArrayToString(char[] ar) { string result=""; for(int i = 0; i< ar.Length; i++) result += ar[i]; return(result); }//CharArrayToString

Класс Char[], как и всякий класс-массив в C#, является наследником не только класса Object, но и класса Array, и, следовательно, обладает всеми методами родительских классов, подробно рассмотренных в предыдущей главе. А есть ли у него специфические методы, которые позволяют выполнять операции над строками, представленными массивами символов? Таких специальных операций нет. Но некоторые перегруженные методы класса Array можно рассматривать как операции над строками. Например, метод Copy дает возможность выделять и заменять подстроку в теле строки. Методы IndexOf, LastIndexOf позволяют определить индексы первого и последнего вхождения в строку некоторого символа. К сожалению, их нельзя использовать для более интересной операции - нахождения индекса вхождения подстроки в строку. При необходимости такую процедуру можно написать самому. Вот как она выглядит:

int IndexOfStr( char[]s1, char[] s2) { //возвращает индекс первого вхождения подстроки s2 в //строку s1 int i =0, j=0, n=s1.Length-s2.Length; bool found = false; while( (i<=n) && !found) { j = Array.IndexOf(s1,s2[0],i); if (j <= n) { found=true; int k = 0; while ((k < s2.Length)&& found) { found =char.Equals(s1[k+j],s2[k]); k++; } } i=j+1; } if(found) return(j); else return(-1); }//IndexOfStr

В реализации используется метод IndexOf класса Array, позволяющий найти начало совпадения строк, после чего проверяется совпадение остальных символов. Реализованный здесь алгоритм является самым очевидным, но далеко не самым эффективным.

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

public void TestIndexSym() { char[] str1, str2; str1 = "рококо".ToCharArray(); //определение вхождения символа int find, lind; find= Array.IndexOf(str1,'о'); lind = Array.LastIndexOf(str1,'о'); Console.WriteLine("Индексы вхождения о в рококо:{0},{1}; ", find, lind); //определение вхождения подстроки str2 = "рок".ToCharArray(); find = IndexOfStr(str1,str2); Console.WriteLine("Индекс первого вхождения рок в рококо:{0}", find); str2 = "око".ToCharArray(); find = IndexOfStr(str1,str2); Console.WriteLine("Индекс первого вхождения око в рококо:{0}", find); }//TestIndexSym

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


Рис. 13.3.  Индексы вхождения подстроки в строку


Класс Circle


Этот класс является потомком класса Ellipse:

using System; using System.Drawing; namespace Shapes { /// <summary> /// Класс Circle - потомок класса Ellipse. /// </summary> public class Circle: Ellipse { public Circle( int radius,int x, int y):base(radius,radius,x,y) { //Круг - это эллипс с равными полуосями (радиусом круга) } } }

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



Класс Ellipse


Вот программный код этого класса:

using System; using System.Drawing; namespace Shapes { /// <summary> /// Класс Ellipse - потомок класса Figure. /// </summary> public class Ellipse: Figure { int axisA,axisB; Rectangle rect; public Ellipse(int A, int B, int x, int y ): base(x,y) { axisA = A; axisB = B; rect =Init(); } public override void Show(Graphics g, Pen pen, Brush brush) { rect = Init(); g.DrawEllipse(pen,rect); g.FillEllipse(brush, rect); } public override Rectangle Region_Capture() { rect = Init(); return rect; } Rectangle Init() { int a =Convert.ToInt32(axisA*scale); int b =Convert.ToInt32(axisB*scale); int leftupX = center.X - a; int leftupY = center.Y - b; return( new Rectangle(leftupX,leftupY,2*a,2*b)); } } }



Класс Exception


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

Основными свойствами класса являются:

Message - строка, задающая причину возникновения исключения. Значение этого свойства устанавливается при вызове конструктора класса, когда создается объект, задающий исключение;HelpLink - ссылка (URL) на файл, содержащий подробную справку о возможной причине возникновения исключительной ситуации и способах ее устранения;InnerException - ссылка на внутреннее исключение. Когда обработчик выбрасывает новое исключение для передачи обработки на следующий уровень, то текущее исключение становится внутренним для вновь создаваемого исключения;Source - имя приложения, ставшего причиной исключения;StackTrace - цепочка вызовов - методы, хранящиеся в стеке вызовов в момент возникновения исключения;TargetSite - метод, выбросивший исключение.

Из методов класса отметим метод GetBaseException. При подъеме по цепочке вызовов он позволяет получить исходное исключение -- первопричину возникновения последовательности выбрасываемых исключений.

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

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

throw(new MyException("Все попытки Pattern безуспешны", me));

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

static public void PrintProperties(Exception e) { Console.WriteLine("Свойства исключения:"); Console.WriteLine("TargetSite = {0}", e.TargetSite); Console.WriteLine("Source = {0}", e.Source); Console.WriteLine("Message = {0}",e.Message); if (e.InnerException == null) Console.WriteLine("InnerException = null"); else Console.WriteLine("InnerException = {0}", e.InnerException.Message); Console.WriteLine("StackTrace = {0}", e.StackTrace); Console.WriteLine("GetBaseException = {0}", e.GetBaseException()); }

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

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

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



Класс Graphics


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

Объекты этого класса зависят от контекста устройства, (графика не обязательно отображается на дисплее компьютера, она может выводиться на принтер, графопостроитель или другие устройства), поэтому создание объектов класса Graphics выполняется не традиционным способом - без вызова конструктора класса. Создаются объекты специальными методами разных классов. Например, метод CreateGraphics класса Control - наследника класса Form - возвращает объект, ассоциированный с выводом графики на форму.

При рисовании в формах можно объявить в форме поле, описывающее объект класса Graphics:

Graphics graph;

а в конструкторе формы произвести связывание с реальным объектом:

graph = CreateGraphics();

Затем всюду в программе, где нужно работать с графикой, используется глобальный для формы объект graph и его методы. Есть другой способ получения этого объекта - обработчики некоторых событий получают объект класса Graphics среди передаваемых им аргументов. Например, в обработчике события Paint, занимающегося перерисовкой, этот объект можно получить так:

protected override void OnPaint(System.Windows.Forms.PaintEventArgs e) { Graphics gr = e.Graphics; //перерисовка, использующая методы объекта gr }

Для получения этого объекта можно использовать и статические методы самого класса Graphics.



Класс LittleCircle


Этот класс, задающие маленькие кружочки фиксированного радиуса, в свою очередь, является наследником класса Circle. Устроен он также чрезвычайно просто:

using System; namespace Shapes { /// <summary> /// Класс LittleCircle - потомок класса Circle. /// </summary> public class LittleCircle:Circle { public LittleCircle(int x,int y): base(4,x,y) { // маленький круг радиуса 4 } } }



Класс Math и его функции


Кроме переменных и констант, первичным материалом для построения выражений являются функции. Большинство их в проекте будут созданы самим программистом, но не обойтись и без встроенных функций. Умение работать в среде Visual Studio .Net предполагает знание встроенных возможностей этой среды, знание возможностей каркаса Framework .Net, пространств имен, доступных при программировании на языке C#, а также соответствующих встроенных классов и функций этих классов. Продолжим знакомство с возможностями, предоставляемыми пространством имен System. Мы уже познакомились с классом Convert этого пространства и частично с классом Console. Давайте рассмотрим еще один класс - класс Math, содержащий стандартные математические функции, без которых трудно обойтись при построении многих выражений. Этот класс содержит два статических поля, задающих константы E и PI, а также 23 статических метода. Методы задают:

тригонометрические функции - Sin, Cos, Tan;обратные тригонометрические функции - ASin, ACos, ATan, ATan2 (sinx, cosx);гиперболические функции - Tanh, Sinh, Cosh;экспоненту и логарифмические функции - Exp, Log, Log10;модуль, корень, знак - Abs, Sqrt, Sign;функции округления - Ceiling, Floor, Round;минимум, максимум, степень, остаток - Min, Max, Pow, IEEERemainder.

В особых пояснениях эти функции не нуждаются. Приведу пример:

/// <summary> /// работа с функциями класса Math /// </summary> public void MathFunctions() { double a, b,t,t0,dt,y; string NameFunction; Console.WriteLine("Введите имя F(t)исследуемой функции a*F(b*t)" + " (sin, cos, tan, cotan)"); NameFunction = Console.ReadLine(); Console.WriteLine("Введите параметр a (double)"); a= double.Parse(Console.ReadLine()); Console.WriteLine("Введите параметр b (double)"); b= double.Parse(Console.ReadLine()); Console.WriteLine("Введите начальное время t0(double)"); t0= double.Parse(Console.ReadLine()); const int points = 10; dt = 0.2; for(int i = 1; i<=points; i++) { t = t0 + (i-1)* dt; switch (NameFunction) { case ("sin"): y = a*Math.Sin(b*t); break; case ("cos"): y = a*Math.Cos(b*t); break; case ("tan"): y = a*Math.Tan(b*t); break; case ("cotan"): y = a/Math.Tan(b*t); break; case ("ln"): y = a*Math.Log(b*t); break; case ("tanh"): y = a*Math.Tanh(b*t); break; default: y=1; break; }//switch Console.WriteLine ("t = " + t + "; " + a +"*" + NameFunction +"(" + b + "*t)= " + y + ";"); }//for double u = 2.5, v = 1.5, p,w; p= Math.Pow(u,v); w = Math.IEEERemainder(u,v); Console.WriteLine ("u = " + u + "; v= " + v + "; power(u,v)= " + p + "; reminder(u,v)= " + w); }//MathFunctions




Заметьте, в примерах программного кода я постепенно расширяю диапазон используемых средств. Часть из этих средств уже описана, а часть (например, оператор цикла for и оператор выбора switch) будут описаны позже. Те, у кого чтение примеров вызывает затруднение, смогут вернуться к ним при повторном чтении книги.

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

Функция, заданная пользователем, вычисляется в операторе switch. Здесь реализован выбор из 6 стандартных функций, входящих в джентльменский набор класса Math.

Вызов еще двух функций из класса Math содержится в двух последних строчках этой процедуры. На рис. 7.1 можно видеть результаты ее работы.


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


Класс Object и массивы


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

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

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

public static void PrintObj(object A) { Console.WriteLine("A.GetType()={0})", A.GetType()); if (A.GetType()==typeof(System.Int32[])) { int[] temp; temp = (int[])A; for(int i = 0; i<temp.GetLength(0);i++) Console.Write("\t temp[{0}]={1}", i,temp[i]); Console.WriteLine(); } else Console.WriteLine("Аргумент не является массивом целых"); }//PrintObject

Несколько замечаний к реализации.

Метод GetType, примененный к аргументу, возвращает не тип Object, а реальный тип фактического аргумента. Поэтому можно проанализировать, какому классу принадлежит объект, переданный в процедуру.

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

Заметьте, при присваивании значения переменной temp выполняется явное преобразование из класса Object в класс Int[].

При наличии переменной temp, выполнение нужных действий над массивом не представляет никаких трудностей.

Приведу два примера вызова этой процедуры:

//работа с процедурой PrintObject //Корректный и некорректный вызовы Arrs.PrintObj(col1); Arrs.PrintObj(col3);

Вот какой вывод порождается этим фрагментом кода:


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



Класс Pen


Методам группы Draw класса Graphics, рисующим контур фигуры, нужно передать перо - объект класса Pen. В конструкторе этого класса можно задать цвет пера и его толщину (чаще говорят "ширину пера"). Цвет задается объектом класса (структурой) Color. Для выбора подходящего цвета можно использовать упоминавшееся выше диалоговое окно Color либо одно из многочисленных статических свойств класса Color, возвращающее требуемый цвет. Возможно и непосредственное задание элементов структуры в виде комбинации RGB - трех цветов - красного, зеленого и голубого. Вместо создания нового пера с помощью конструктора можно использовать специальный класс предопределенных системных перьев.



Класс Person


Этот класс является прямым потомком класса Figure. Вместе с тем, класс является клиентом трех других классов семейства - Circle, Rect и LittleCircle, поскольку элементы фигуры, составляющие человечка, являются объектами этих классов%

namespace Shapes { /// <summary> /// Класс Person - потомок класса Figure, /// клиент классов Circle, Rect, LittleCircle. /// </summary> public class Person:Figure { int head_h; Circle head; Rect body; LittleCircle nose; public Person(int head_h, int x, int y): base(x,y) { //head_h - радиус головы, x,y - ее центр. //остальные размеры исчисляются относительно //размера головы. this.head_h = head_h; head = new Circle(head_h,x,y); int body_x = x; int body_y = y + 3*head_h; int body_w =2*head_h; int body_h = 4*head_h; body = new Rect(body_w, body_h, body_x,body_y); nose = new LittleCircle(x+head_h +2, y); } public override void Show(System.Drawing.Graphics g, System.Drawing.Pen pen, System.Drawing.Brush brush) { int h = Convert.ToInt32(head_h*scale); //head int top_x = center.X - h; int top_y = center.Y - h; g.DrawEllipse(pen, top_x,top_y, 2*h,2*h); g.FillEllipse(brush, top_x,top_y, 2*h,2*h); //body top_y += 2*h; g.DrawRectangle(pen, top_x,top_y, 2*h,4*h); g.FillRectangle(brush, top_x,top_y, 2*h,4*h); //nose top_y -=h; top_x += 2*h; g.DrawEllipse(pen, top_x,top_y, 8,8); g.FillEllipse(brush, top_x,top_y, 8,8); } public override System.Drawing.Rectangle Region_Capture() { int h = Convert.ToInt32(head_h*scale); int top_x = center.X - h; int top_y = center.Y - h; return new System.Drawing.Rectangle(top_x,top_y,2*h,2*h); } } }



Класс Random и его функции


Умение генерировать случайные числа требуется во многих приложениях. Класс Random содержит все необходимые для этого средства. Класс Random имеет конструктор класса: для того, чтобы вызывать методы класса, нужно вначале создавать экземпляр класса. Этим Random отличается от класса Math, у которого все поля и методы - статические, что позволяет обойтись без создания экземпляров класса Math.

Как и всякий "настоящий" класс, класс Random является наследником класса Object, а, следовательно, имеет в своем составе и методы родителя. Рассмотрим только оригинальные методы класса Random со статусом public, необходимые для генерирования последовательностей случайных чисел. Класс имеет защищенные методы, знание которых полезно при необходимости создания собственных потомков класса Random, но этим мы заниматься не будем.

Начнем рассмотрение с конструктора класса. Он перегружен и имеет две реализации. Одна из них позволяет генерировать неповторяющиеся при каждом запуске серии случайных чисел. Начальный элемент такой серии строится на основе текущей даты и времени, что гарантирует уникальность серии. Этот конструктор вызывается без параметров. Он описан как public Random(). Другой конструктор с параметром - public Random (int) обеспечивает важную возможность генерирования повторяющейся серии случайных чисел. Параметр конструктора используется для построения начального элемента серии, поэтому при задании одного и того же значения параметра серия будет повторяться.

Перегруженный метод public int Next() при каждом вызове возвращает положительное целое, равномерно распределенное в некотором диапазоне. Диапазон задается параметрами метода. Три реализации метода отличаются набором параметров:

public int Next () - метод без параметров выдает целые положительные числа во всем положительном диапазоне типа int;public int Next (int max) - выдает целые положительные числа в диапазоне [0,max];public int Next (int min, int max) - выдает целые положительные числа в диапазоне [min,max].




Метод public double NextDouble () имеет одну реализацию. При каждом вызове этого метода выдается новое случайное число, равномерно распределенное в интервале [0,1).

Еще один полезный метод класса Random позволяет при одном обращении получать целую серию случайных чисел. Метод имеет параметр - массив, который и будет заполнен случайными числами. Метод описан как public void NextBytes (byte[] buffer). Так как параметр buffer представляет массив байтов, то, естественно, генерированные случайные числа находятся в диапазоне [0, 255].

Приведу теперь пример работы со случайными числами. Как обычно, для проведения экспериментов по генерации случайных чисел я создал метод Rand в классе Testing. Вот программный код этого метода:

/// <summary> /// Эксперименты с классом Random /// </summary> public void Rand() { const int initRnd = 77; Random realRnd = new Random(); Random repeatRnd = new Random(initRnd); // случайные числа в диапазоне [0,1) Console.WriteLine("случайные числа в диапазоне[0,1)"); for(int i =1; i <= 5; i++) { Console.WriteLine("Число " + i + "= " + realRnd.NextDouble() ); } // случайные числа в диапазоне[min,max] int min = -100, max=-10; Console.WriteLine("случайные числа в диапазоне [" + min +"," + max + "]"); for(int i =1; i <= 5; i++) { Console.WriteLine("Число " + i + "= " + realRnd.Next(min,max) ); } // случайный массив байтов byte[] bar = new byte[10]; repeatRnd.NextBytes(bar); Console.WriteLine("Массив случайных чисел в диапазоне [0, 255]"); for(int i =0; i < 10; i++) { Console.WriteLine("Число " + i + "= " +bar[i]); } }//Rand

Приведу краткий комментарий к тексту программы. Вначале создаются два объекта класса Random. У этих объектов разные конструкторы. Объект с именем realRnd позволяет генерировать неповторяющиеся серии случайных чисел. Объект repeatRnd дает возможность повторить при необходимости серию. Метод NextDouble создает серию случайных чисел в диапазоне [0, 1). Вызываемый в цикле метод Next с двумя параметрами создает серию случайных отрицательных целых, равномерно распределенных в диапазоне [-100, -10]. Метод NextBytes объекта repeatRnd позволяет получить при одном вызове массив случайных чисел из диапазона [0, 255]. Результаты вывода можно увидеть на рис. 7.2.


Рис. 7.2.  Генерирование последовательностей случайных чисел в процедуре Rand

На этом заканчивается рассмотрение темы выражений языка C#.


Класс Rational или структура Rational


Вернемся к классу Rational, спроектированному в предыдущей лекции. Очевидно, что его вполне разумно представить в виде структуры. Наследование ему не нужно. Семантика присваивания развернутого типа больше подходит для рациональных чисел, чем ссылочная семантика, ведь рациональные числа - это еще один подкласс арифметического класса. В общем, класс Rational - прямой кандидат в структуры. Зададимся вопросом, насколько просто объявление класса превратить в объявление структуры? Достаточно ли заменить слово class словом struct? В данном случае одним словом не обойтись. Есть одно мешающее ограничение на структуры. В конструкторе класса Rational вызывается метод nod, а вызов методов в конструкторе запрещен. Нетрудно обойти это ограничение, изменив конструктор, то есть явно задав вычисление общего делителя в его теле. Приведу текст этого конструктора:

public struct Rational { public Rational(int a, int b) { if(b==0) {m=0; n=1;} else { //приведение знака if( b<0) {b=-b; a=-a;} //приведение к несократимой дроби int p = 1, m1=a, n1 =b; m1=Math.Abs(m1); n1 =Math.Abs(n1); if(n1>m1){p=m1; m1=n1; n1=p;} do { p = m1%n1; m1=n1; n1=p; }while (n1!=0); p=m1; m=a/p; n=b/p; } }//Конструктор //поля и методы класса }

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

public void TwoSemantics() { Rational r1 = new Rational(1,3), r2 = new Rational(3,5); Rational r3, r4; r3 = r1+r2; r4 = r3; if(r3 >1) r3 = r1+r3 + Rational.One; else r3 = r2+r3 - Rational.One; r3.PrintRational("r3"); r4.PrintRational("r4"); }

В этом примере используются константы, работает статический конструктор, закрытый конструктор, перегруженные операции сравнения, арифметические выражения над рациональными числами. В результате вычислений r3 получит значение 8/15, r4- 14/15. Заметьте, аналогичный пример для класса Rational даст те же результаты. Для класса Rational и структуры Rational нельзя обнаружить разницу между ссылочным и развернутым присваиванием. Это связано с особенностью класса Rational - он по построению относится к неизменяемым (immutable) классам, аналогично классу String. Операции этого класса не изменяют поля объекта, а каждый раз создают новый объект. В этом случае можно считать, что объекты класса обладают присваиванием развернутого типа.



Класс Rect


Этот класс является еще одним прямым потомком класса Figure:

using System; using System.Drawing; namespace Shapes { /// <summary> /// Класс Rect - потомок класса Figure. /// </summary> public class Rect:Figure { int sideA, sideB; Rectangle rect; public Rect(int sideA,int sideB, int x, int y): base(x,y) { this.sideA = sideA; this.sideB = sideB; rect =Init(); } public override void Show(Graphics g, Pen pen, Brush brush) { rect = Init(); g.DrawRectangle(pen,rect); g.FillRectangle(brush,rect); } public override Rectangle Region_Capture() { rect = Init(); return rect; } Rectangle Init() { int a =Convert.ToInt32(sideA*scale); int b =Convert.ToInt32(sideB*scale); int leftupX = center.X - a/2; int leftupY = center.Y - b/2; return( new Rectangle(leftupX,leftupY,a,b)); } } }



Класс Regex


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

Рассмотрим четыре основных метода класса Regex.

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

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

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

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



Класс RegexCompilationInfo


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



Класс с атрибутом сериализации


Класс, объекты которого предполагается сериализовать стандартным образом, должен при объявлении сопровождаться атрибутом [Serializable]. Стандартная сериализация предполагает два способа сохранения объекта: в виде бинарного потока символов и в виде xml-документа. В бинарном потоке сохраняются все поля объекта, как открытые, так и закрытые. Процессом этим можно управлять, помечая некоторые поля класса атрибутом [NonSerialized] - эти поля сохраняться не будут:

[Serializable] public class Test { public string name; [NonSerialized] int id; int age; //другие поля и методы класса }

В класс Test встроен стандартный механизм сериализации его объектов. При сериализации поля name и age будут сохраняться, поле id - нет.

Для запуска механизма необходимо создать объект, называемый форматером и выполняющий сериализацию и десериализацию данных с подходящим их форматированием. Библиотека FCL предоставляет два класса форматеров. Бинарный форматер, направляющий данные в бинарный поток, принадлежит классу BinaryFormatter. Этот класс находится в пространстве имен библиотеки FCL:

System.Runtime.Serialization.Formatters.Binary

Давайте разберемся, как устроен этот класс. Он является наследником двух интерфейсов: IFormatter и IRemotingFormatter. Интерфейс IFormatter имеет два открытых метода: Serialize и Deserialize, позволяющих сохранять и восстанавливать всю совокупность связанных объектов с заданным объектом в качестве корня. Интерфейс IRemotingFormatter имеет те же открытые методы: Serialize и Deserialize, позволяющие выполнять глубокую сериализацию, но в режиме удаленного вызова. Поскольку сигнатуры одноименных методов интерфейсов отличаются, то конфликта имен при наследовании не происходит - в классе BinaryFormatter методы Serialize и Deserialize перегружены. Для удаленного вызова задается дополнительный параметр, что и позволяет различать, локально или удаленно выполняются процессы обмена данными.

В пространстве имен библиотеки FCL:

System.Runtime.Serialization.Formatters.Soap

находится класс SoapFormatter. Он является наследником тех же интерфейсов IFormatter и IRemotingFormatter и реализует их методы Serialize и Deserialize, позволяющие выполнять глубокую сериализацию и десериализацию при сохранении данных в формате xml. Помимо методов класса SoapFormatter, xml-сериализацию можно выполнять средствами другого класса -- XmlSerializer.

Из новых средств, еще не рассматривавшихся в наших лекциях, для организации сериализации понадобятся файлы. Пространство имен IO библиотеки FCL предоставляет классы, поддерживающие ввод-вывод данных. В частности, в этом пространстве есть абстрактный класс Stream для работы с потоками данных. С одним из его потомков - классом FileStream - мы и будем работать в нашем примере.

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

[Serializable] public class Personage { public Personage(string name, int age) { this.name = name; this.age = age; } //поля класса static int wishes; public string name, status, wealth; int age; public Personage couple; //методы класса }




Герои сказки - объекты этого класса обладают свойствами, задающими имя, возраст, статус, имущество и супруга. Имя и возраст задаются в конструкторе класса, а остальные свойства задаются в следующем методе:

public void marry (Personage couple) { this.couple = couple; couple.couple = this; this.status ="крестьянин"; this.wealth ="рыбацкая сеть"; this.couple.status = "крестьянка"; this.couple.wealth = "корыто"; SaveState(); }

Предусловие метода предполагает, что метод вызывается один раз главным героем (рыбаком). В методе устанавливаются взаимные ссылки между героями сказки, их начальное состояние. Завершается метод сохранением состояния объектов, выполняемого при вызове метода SaveState:

void SaveState() { BinaryFormatter bf = new BinaryFormatter(); FileStream fs = new FileStream ("State.bin",FileMode.Create, FileAccess.Write); bf.Serialize(fs,this); fs.Close(); }

Здесь и выполняется сериализация графа объектов. Как видите, все просто. Вначале создается форматер - объект bf класса BinaryFormatter. Затем определяется файл, в котором будет сохраняться состояние объектов, - объект fs класса FileStream. Заметьте, в конструкторе файла, кроме имени файла, указываются его характеристики: статус, режим доступа. На деталях введения файлов я останавливаться не буду. Теперь, когда основные объекты определены, остается вызвать метод Serialize объекта bf, которому в качестве аргументов передается объект fs и текущий объект, представляющий корневой объект графа объектов, которые подлежат сериализации. Глубокая сериализация, реализуемая в данном случае, не потребовала от нас никаких усилий.

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

public Personage AskGoldFish() { Personage fisher = this; if (fisher.name == "рыбак") { wishes++; switch (wishes) { case 1: ChangeStateOne();break; case 2: ChangeStateTwo();break; case 3: ChangeStateThree();break; default: BackState(ref fisher);break; } } return(fisher); }//AskGoldFish



Метод реализует анализ желаний героини сказки. Первые три желания исполняются, и состояние героев меняется:

void ChangeStateOne() { this.status = "муж дворянки"; this.couple.status = "дворянка"; this.couple.wealth = "имение"; } void ChangeStateTwo() { this.status = "муж боярыни"; this.couple.status = "боярыня"; this.couple.wealth = "много поместий"; } void ChangeStateThree() { this.status = "муж государыни"; this.couple.status = "государыня"; this.couple.wealth = "страна"; }

Начиная с четвертого желания, все возвращается в начальное состояние - выполняется десериализация графа объектов:

void BackState(ref Personage fisher) { BinaryFormatter bf = new BinaryFormatter(); FileStream fs = new FileStream ("State.bin",FileMode.Open, FileAccess.Read); fisher = (Personage)bf.Deserialize(fs); fs.Close(); }

Обратите внимание, что у метода есть аргумент, передаваемый по ссылке. Этот аргумент получает значение - ссылается на объект, создаваемый методом Deserialize. Без аргумента метода не обойтись, поскольку возвращаемый методом объект нельзя присвоить текущему объекту this. Важно также отметить, что метод Deserialize восстанавливает весь граф объектов, возвращая в качестве результата корень графа.

В классе определен еще один метод, сообщающий о текущем состоянии объектов:

public void About() { Console.WriteLine("имя = {0}, возраст = {1},"+ "статус = {2}, состояние ={3}",name,age,status, wealth); Console.WriteLine("имя = {0}, возраст = {1}," + "статус = {2}, состояние ={3}", this.couple.name, this.couple.age,this.couple.status, this.couple.wealth); }

Для завершения сказки нам нужно в клиентском классе создать ее героев:

public void TestGoldFish() { Personage fisher = new Personage("рыбак", 70); Personage wife = new Personage("старуха", 70); fisher.marry(wife); Console.WriteLine("До золотой рыбки"); fisher.About(); fisher = fisher.AskGoldFish(); Console.WriteLine("Первое желание"); fisher.About(); fisher = fisher.AskGoldFish(); Console.WriteLine("Второе желание"); fisher.About(); fisher = fisher.AskGoldFish(); Console.WriteLine("Третье желание"); fisher.About(); fisher = fisher.AskGoldFish(); Console.WriteLine("Еще хочу"); fisher.About(); fisher = fisher.AskGoldFish(); Console.WriteLine("Хочу, но уже поздно"); fisher.About(); }



На рис. 19.6 показаны результаты исполнения сказки.


Рис. 19.6.  Сказка о рыбаке и рыбке

Что изменится, если перейти к сохранению данных в xml-формате? немногое. Нужно лишь заменить объявление форматера:

void SaveStateXML() { SoapFormatter sf = new SoapFormatter(); FileStream fs = new FileStream ("State.xml",FileMode.Create, FileAccess.Write); sf.Serialize(fs,this); fs.Close(); } void BackStateXML(ref Personage fisher) { SoapFormatter sf = new SoapFormatter(); FileStream fs = new FileStream ("State.xml",FileMode.Open, FileAccess.Read); fisher = (Personage)sf.Deserialize(fs); fs.Close(); }

Клиент, работающий с объектами класса, этих изменений и не почувствует. Результаты вычислений останутся теми же, что и в предыдущем случае. Правда, файл, сохраняющий данные, теперь выглядит совсем по-другому. Это обычный xml-документ, который мог быть создан в любом из приложений. Вот как выглядит этот документ, открытый в браузере Internet Explorer.


Рис. 19.7.  XML-документ, сохраняющий состояние объектов


Класс с универсальными методами


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

class Change { static public void Swap<T>(ref T x1, ref T x2) { T temp; temp = x1; x1 = x2; x2 = temp; } }

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

Рассмотрим тестирующую процедуру из традиционного для наших примеров класса Testing, в которой интенсивно используется вызов метода swap для различных типов переменных:

public void TestSwap() { int x1 = 5, x2 = 7; Console.WriteLine("до обмена: x1={0}, x2={1}",x1, x2); Change.Swap<int>(ref x1, ref x2); Console.WriteLine("после обмена: x1={0}, x2={1}", x1, x2); string s1 = "Савл", s2 = "Павел"; Console.WriteLine("до обмена: s1={0}, s2={1}", s1, s2); Change.Swap<string>(ref s1, ref s2); Console.WriteLine("после обмена: s1={0}, s2={1}", s1, s2); Person pers1 = new Person("Савлов", 25, 1500); Person pers2 = new Person("Павлов", 35, 2100); Console.WriteLine("до обмена: "); pers1.PrintPerson(); pers2.PrintPerson(); Change.Swap<Person>(ref pers1, ref pers2); Console.WriteLine("после обмена:"); pers1.PrintPerson(); pers2.PrintPerson(); }

Обратите внимание на строки, осуществляющие вызов метода:

Change.Swap<int>(ref x1, ref x2); Change.Swap<string>(ref s1, ref s2); Change.Swap<Person>(ref pers1, ref pers2);




В момент вызова метода передаются фактические аргументы и фактические типы. В данном примере в качестве фактических типов использовались встроенные типы int и string и тип Person, определенный пользователем. Общая ситуация такова: если в классе объявлен универсальный метод со списком параметров M<T1, ...Tn> (...), то метод вызывается следующим образом: M<TYPE1, ... TYPEn>(...), где TYPEi - это конкретные типы.

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


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

В этом примере использовался класс Person, и поскольку он появится и в следующих примерах, то приведу его текст:

class Person { public Person(string name, int age, double salary) { this.name = name; this.age = age; this.salary = salary; } public string name; public int age; public double salary; public void PrintPerson() { Console.WriteLine("name= {0}, age = {1}, salary ={2}", name, age, salary); } }


Класс sender


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

// Класс, создающий событие. Потомок класса ArrayList. public class ListWithChangedEvent: ArrayList { //Свойства класса: событие и его аргументы //Событие Changed, зажигаемое при всех изменениях //элементов списка. public event ChangedEventHandler Changed; //Аргументы события private ChangedEventArgs evargs = new ChangedEventArgs();

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

Хороший стиль требует задания в классе процедуры On, включающей событие. Так и поступим:

//Методы класса: процедура On и переопределяемые методы. //Процедура On, включающая событие protected virtual void OnChanged(ChangedEventArgs args) { if (Changed != null) Changed(this, args); }

Процедура OnChanged полностью соответствует ранее описанному образцу, поэтому не требует дополнительных комментариев.

Наш класс, являясь наследником класса ArrayList, наследует все его методы. Переопределим методы, изменяющие элементы:

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

Обратите внимание на схему включения события, например, в процедуре Add. Вначале задаются входные аргументы, в данном случае Item. Затем вызывается процедура включения OnChanged. При зажигании выполнение процедуры Add прерывается. Запускаются обработчики, присоединенные к событию. Процедура Add продолжит работу только после окончания их работы. Анализ выходной переменной Permit позволяет установить, получено ли разрешение на изменение значения; при истинности значения этой переменной вызывается родительский метод Add, осуществляющий изменение значения. Это достаточно типичная схема работы с событиями.



Класс sender. Как объявляются события?


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

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



Класс Square


Квадрат - это частный случай прямоугольника. Соответствующий класс является потомком класса Rect:

using System; namespace Shapes { /// <summary> /// Класс Square - потомок класса Rect. /// </summary> public class Square:Rect { public Square(int side, int x, int y): base(side,side,x,y) { //квадрат - это прямоугольник с равными сторонами } } }



Класс String


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



Класс StringBuilder - построитель строк


Класс string не разрешает изменять существующие объекты. Строковый класс StringBuilder позволяет компенсировать этот недостаток. Этот класс принадлежит к изменяемым классам и его можно найти в пространстве имен System.Text. Рассмотрим класс StringBuilder подробнее.



Классы без потомков


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



Классы Capture и CaptureCollection


Коллекция CaptureCollection возвращается при вызове свойства Captures объектов класса Group и Match. Класс Match наследует это свойство у своего родителя - класса Group. Каждый объект Capture, входящий в коллекцию, характеризует соответствие, захваченное в процессе поиска, - соответствующую подстроку. Но поскольку свойства объекта Capture передаются по наследству его потомкам, то можно избежать непосредственной работы с объектами Capture. По крайней мере, в моих примерах не встретится работа с этим объектом, хотя "за кулисами" он непременно присутствует.



Классы Debug и Trace


Атрибут условной компиляции Conditional характеризует метод, но не отдельный оператор. Иногда хотелось бы иметь условный оператор печати, не создавая специального метода, как это было сделано в предыдущем примере. Такую возможность и многие другие полезные свойства предоставляют классы Debug и Trace.

Классы Debug и Trace - это классы-двойники. Оба они находятся в пространстве имен Diagnostics, имеют идентичный набор статических свойств и методов с идентичной семантикой. В чем же разница? Методы класса Debug имеют атрибут условной компиляции с константой DEBUG, действуют только в Debug-конфигурации проекта и игнорируются в Release-конфигурации. Методы класса Trace включают два атрибута Conditional с константами DEBUG и TRACE и действуют в обеих конфигурациях.

Одна из основных групп методов этих классов - методы печати данных: Write, WriteIf, WriteLine, WriteLineIf. Методы перегружены, в простейшем случае позволяют выводить некоторое сообщение. Методы со словом If могут сделать печать условной, задавая условие печати в качестве первого аргумента метода, что иногда крайне полезно. Методы со словом Line дают возможность дополнять сообщение символом перехода на новую строку.

По умолчанию методы обоих классов направляют вывод в окно Output. Однако это не всегда целесообразно, особенно для Release-конфигурации. Замечательным свойством методов классов Debug и Trace является то, что они могут иметь много "слушателей", направляя вывод каждому из них. Свойство Listeners этих классов возвращает разделяемую обоими классами коллекцию слушателей - TraceListenerCollection. Как и всякая коллекция, она имеет ряд методов для добавления новых слушателей: Add, AddRange, Insert - и возможность удаления слушателей: Clear, Remove, RemoveAt и другие методы. Объекты этой коллекции в качестве предка имеют абстрактный класс TraceListener. Библиотека FCL включает три неабстрактных потомка этого класса:

DefaultTraceListener - слушатель этого класса, добавляется в коллекцию по умолчанию, направляет вывод, поступающий при вызове методов классов Debug и Trace, в окно Output;EventLogTraceListener - посылает сообщения в журнал событий Windows;TextWriterTraceListener - направляет сообщения объектам класса TextWriter или Stream; обычно один из объектов этого класса направляет вывод на консоль, другой - в файл.




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

Помимо свойства Listeners и методов печати, классы Debug и Trace имеют и другие важные методы и свойства:

Assert и Fail, проверяющие корректность хода вычислений - о них мы поговорим особо;Flush - метод, отправляющий содержание буфера слушателю (в файл, на консоль и так далее). Следует помнить, что данные буферизуются, поэтому применение метода Flush зачастую необходимо, иначе метод может завершиться, а данные останутся в буфере;AutoFlush - булево свойство, указывающее, следует ли после каждой операции записи данные из буфера направлять в соответствующий канал. По умолчанию свойство выключено, и происходит только буферизация данных;Close - метод, опустошающий буфера и закрывающий всех слушателей, после чего им нельзя направлять сообщения.

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

Рассмотрим пример работы, в котором отладочная информация направляется в разные каналы - окно вывода, консоль, файл:

public void Optima() { double x, y=1; x= y - 2*Math.Sin(y); FileStream f = new FileStream("Debuginfo.txt", FileMode.Create, FileAccess.Write); TextWriterTraceListener writer1 = new TextWriterTraceListener(f); TextWriterTraceListener writer2 = new TextWriterTraceListener(System.Console.Out); Trace.Listeners.Add( writer1); Debug.Listeners.Add( writer2); Debug.WriteLine("Число слушателей:" + Debug.Listeners.Count); Debug.WriteLine("автоматический вывод из буфера:"+ Trace.AutoFlush); Trace.WriteLineIf(x<0, "Trace: " + "x= " + x.ToString() + " y = " + y); Debug.WriteLine("Debug: " + "x= " + x.ToString() + " y = " + y); Trace.Flush(); f.Close(); }

В коллекцию слушателей вывода к слушателю по умолчанию добавляются еще два слушателя класса TextWriterTraceListener. Заметьте, что хотя они добавляются методами разных классов Debug и Trace, попадают они в одну коллекцию. Как и обещано, один из этих слушателей направляет вывод в файл, другой на консоль. На рис. 23.2 на фоне окна кода показаны три канала вывода - окно Output, консоль, файл - содержащие одну и ту же информацию.


Рис. 23.2.  Три канала вывода


Классы Group и GroupCollection


Коллекция GroupCollection возвращается при вызове свойства Group объекта Match. Имея эту коллекцию, можно добраться до каждого объекта Group, в нее входящего. Класс Group является наследником класса Capture и, одновременно, родителем класса Match. От своего родителя он наследует свойства Index, Length и Value, которые и передает своему потомку.

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

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

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



Классы и ООП


Объектно-ориентированное программирование и проектирование построено на классах. Любую программную систему, выстроенную в объектном стиле, можно рассматривать как совокупность классов, возможно, объединенных в проекты, пространства имен, решения, как это делается при программировании в Visual Studio .Net.



Классы и структуры


Структура - это частный случай класса. Исторически структуры используются в языках программирования раньше классов. В языках PL/1, C и Pascal они представляли собой только совокупность данных (полей класса), но не включали ни методов, ни событий. В языке С++ возможности структур были существенно расширены и они стали настоящими классами, хотя и c некоторыми ограничениями. В языке C# - наследнике С++ - сохранен именно такой подход к структурам.

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

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

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



Классы элементов списка


Рассмотрим классы, описывающие элементы списков - элементы с одним и с двумя указателями:

using System; namespace Shapes { /// <summary> /// Класс Linkable(T)задает элементы списка,включающие: /// информационное поле типа T - item /// ссылку на элемент типа Linkable - next /// Функции: /// конструктор new: -> Linkable /// запросы: /// Get_Item: Linkable -> T /// Get_Next: Linkable -> Linkable /// процедуры: /// Set_Item: Linkable*T -> Linkable /// Set_Next: Linkable*Linkable -> Linkable /// Роль типа T играет Figure /// </summary> public class Linkable { public Linkable() { item =null; next = null; } /// <summary> /// закрытые атрибуты класса /// </summary> Figure item; Linkable next; /// <summary> /// процедуры свойства для доступа к полям класса /// </summary> public Figure Item{ get{ return(item); } set{ item = value; } } public Linkable Next{ get{ return(next); } set{ next = value; } } }//class Linkable /// <summary> /// Класс TwoLinkable задает элементы с двумя ссылками /// </summary> public class TwoLinkable {

public TwoLinkable() { prev = next = null; } /// <summary> /// закрытые атрибуты класса /// </summary> TwoLinkable prev, next; Figure item; /// <summary> /// процедуры свойства для доступа к полям класса /// </summary> public Figure Item { get { return(item); } set { item = value; } } public TwoLinkable Next { get { return(next); } set { next = value; } } public TwoLinkable Prev { get { return(prev); } set { prev = value; } } }//class TwoLinkable }



Классы Match и MatchCollection


Как уже говорилось, объекты этих классов создаются автоматически при вызове методов Match и Matches. Коллекция MatchCollection, как и все коллекции, позволяет получить доступ к каждому ее элементу - объекту Match. Можно, конечно, организовать цикл for each для последовательного доступа ко всем элементам коллекции.

Класс Match является непосредственным наследником класса Group, который, в свою очередь, является наследником класса Capture. При работе с объектами класса Match наибольший интерес представляют не столько методы класса, сколько его свойства, большая часть которых унаследована от родительских классов. Рассмотрим основные свойства:

свойства Index, Length и Value наследованы от прародителя Capture. Они описывают найденную подстроку- индекс начала подстроки в искомой строке, длину подстроки и ее значение;свойство Groups класса Match возвращает коллекцию групп - объект GroupCollection, который позволяет работать с группами, созданными в процессе поиска соответствия;свойство Captures, наследованное от объекта Group, возвращает коллекцию CaptureCollection. Как видите, при работе с регулярными выражениями реально приходится создавать один объект класса Regex, объекты других классов автоматически появляются в процессе работы с объектами Regex.



Классы меню


Все, что можно делать руками, можно делать программно. Рассмотрим классы, используемые при работе с меню. Основным родительским классом является абстрактный класс Menu, задающий базовую функциональность трех своих потомков - классов MainMenu, ContextMenu и MenuItem. Класс MenuItem задает элемент меню, который, напомню, сам может являться меню (подменю). Свойство MenuItems, которым обладают все классы меню, возвращает коллекцию MenuItems из элементов меню класса MenuItem. С коллекцией можно работать обычным образом. Создание меню означает создание объектов контейнерных классов MainMenu и ContextMenu и множества объектов класса MenuItem. Последние добавляются в коллекцию либо контейнерных классов, либо в коллекцию соответствующих элементов MenuItem. Созданные объекты классов MainMenu и ContextMenu связываются со свойствами формы - Menu и ConextMenu. Проанализируем код, созданный в процессе проектирования Дизайнером Меню и Дизайнером Формы для нашего примера.

Вот какие поля формы, задающие объекты меню, были сформированы:

private System.Windows.Forms.MainMenu mainMenu1; private System.Windows.Forms.MenuItem menuItem1; //другие элементы меню private System.Windows.Forms.MenuItem menuItem10;

Основной код, создаваемый дизайнерами, помещается в метод InitializeComponent. Приведу лишь фрагменты этого кода:

this.mainMenu1 = new System.Windows.Forms.MainMenu(); this.menuItem1 = new System.Windows.Forms.MenuItem(); ... // mainMenu1 this.mainMenu1.MenuItems.AddRange(new System.Windows.Forms.MenuItem[] {this.menuItem1,this.menuItem2,this.menuItem3}); // menuItem1 this.menuItem1.Index = 0; this.menuItem1.MenuItems.AddRange(new System.Windows.Forms.MenuItem[] {this.menuItem4,this.menuItem10}); this.menuItem1.Text = "File"; ... // menuItem4 this.menuItem4.Index = 0; this.menuItem4.Text = "Open"; this.menuItem4.Click += new System.EventHandler(this.menuItem4_Click); ... // Form1 ... this.Controls.AddRange(new System.Windows.Forms.Control[] { this.textBox1}); this.Menu = this.mainMenu1; this.Name = "Form1"; this.Text = "Form1";

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



Классы receiver


Мы построим два класса, объекты которых способны получать и обрабатывать событие Changed. Получать они будут одно и то же сообщение, а обрабатывать его будут по-разному. В нашей модельной задаче различие обработчиков сведется к выдаче разных сообщений. Поэтому достаточно разобраться с устройством одного класса, названного EventReceiver1. Вот его код:

class EventReceiver1 { private ListWithChangedEvent List; public EventReceiver1(ListWithChangedEvent list) { List = list; // Присоединяет обработчик к событию. OnConnect(); } //Обработчик события - выдает сообщение. //Разрешает добавление элементов, меньших 10. private void ListChanged(object sender, ChangedEventArgs args) { Console.WriteLine("EventReceiver1: Сообщаю об изменениях:" + "Item ={0}", args.Item); args.Permit = ((int)args.Item < 10); } public void OnConnect() { //Присоединяет обработчик к событию List.Changed += new ChangedEventHandler(ListChanged); } public void OffConnect() { //Отсоединяет обработчик от события и удаляет список List.Changed -= new ChangedEventHandler(ListChanged); List = null; } }//class EventReceiver1

Дам краткие комментарии.

Среди закрытых свойств класса есть ссылка List на объект, создающий события.Конструктору класса передается фактический объект, который и будет присоединен к List. В конструкторе же происходит присоединение обработчика события к событию. Для этого, как положено, используется созданный в классе метод OnConnect.Класс содержит метод OffConnect, позволяющий при необходимости отключить обработчик от события.Обработчик события, анализируя переданный ему входной аргумент события Item, разрешает или не разрешает изменение элемента, формируя значение выходного аргумента Permit. Параллельно обработчик выводит на консоль сообщение о своей работе.

Класс Receiver2 устроен аналогично. Приведу его текст уже без всяких комментариев:

class Receiver2 { private ListWithChangedEvent List; public Receiver2(ListWithChangedEvent list) { List = list; // Присоединяет обработчик к событию. OnConnect(); } // Обработчик события - выдает сообщение. //Разрешает добавление элементов, меньших 20. private void ListChanged(object sender, ChangedEventArgs args) { Console.WriteLine("Receiver2: Сообщаю об изменениях:" + " Объект класса {0} : " + "Item ={1}", sender.GetType(), args.Item); args.Permit = ((int)args.Item < 20); } public void OnConnect() { //Присоединяет обработчик к событию List.Changed += new ChangedEventHandler(ListChanged); //Заметьте, допустимо только присоединение (+=), //но не замена (=) //List.Changed = new ChangedEventHandler(ListChanged); } public void OffConnect() { //Отсоединяет обработчик от события и удаляет список List.Changed -= new ChangedEventHandler(ListChanged); List = null; } }//class Receiver2




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

public void TestChangeList() { //Создаются два объекта, вырабатывающие события ListWithChangedEvent list = new ListWithChangedEvent(); ListWithChangedEvent list1 = new ListWithChangedEvent(); //Создаются три объекта двух классов EventReceiver1 и //Receiver2, способные обрабатывать события класса //ListWithChangedEvent EventReceiver1 Receiver1 = new EventReceiver1(list); Receiver2 Receiver21 = new Receiver2 (list); Receiver2 Receiver22 = new Receiver2(list1); Random rnd = new Random(); //Работа с объектами, приводящая к появлению событий list.Add(rnd.Next(20)); list.Add(rnd.Next(20)); list[1] =17; int val = (int)list[0] + (int)list[1];list.Add(val); list.Clear(); list1.Add(10); list1[0] = 25; list1.Clear(); //Отсоединение обработчика событий Receiver1.OffConnect(); list.Add(21); list.Clear(); }

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


Рис. 21.2.  События в мире объектов


Классы receiver. Как обрабатываются события


Объекты класса Sender создают события и уведомляют о них объекты, возможно, разных классов, названных нами классами Receiver, или клиентами. Давайте разберемся, как должны быть устроены классы Receiver, чтобы вся эта схема заработала.

Понятно, что класс receiver должен:

иметь обработчик события - процедуру, согласованную по сигнатуре с функциональным типом делегата, который задает событие;иметь ссылку на объект, создающий событие, чтобы получить доступ к этому событию - event-объекту;уметь присоединить обработчик события к event-объекту. Это можно реализовать по-разному, но технологично это делать непосредственно в конструкторе класса, так что когда создается объект, получающий сообщение, он изначально готов принимать и обрабатывать сообщения о событиях. Вот пример, демонстрирующий возможное решение проблем:public class FireMen { private TownWithEvents MyNativeTown; public FireMen(TownWithEvents TWE) { this.MyNativeTown=TWE; MyNativeTown.FireEvent += new FireEventHandler(FireHandler); } private void FireHandler(object Sender, int time, int build) { Console.WriteLine("Fire at day {0}, in build {1}!", time, build); } public void GoOut() { MyNativeTown.FireEvent -= new FireEventHandler(FireHandler); } }//FireMan

В классе Fireman есть ссылка на объект класса TownWithEvents, создающий события. Сам объект передается в конструкторе класса. Здесь же происходит присоединение обработчика события к event-объекту. Обработчик события FireHandler выводит сообщение на консоль.



Классы с большим числом событий


Как было сказано, каждое событие класса представляется полем этого класса. Если у класса много объявленных событий, а реально возникает лишь малая часть из них, то предпочтительнее динамический подход, когда память отводится только фактически возникшим событиям. Это несколько замедляет время выполнения, но экономит память. Решение зависит от того, что в данном контексте важнее - память или время. Для реализации динамического подхода в языке предусмотрена возможность задания пользовательских методов Add и Remove в момент объявления события. Это и есть другая форма объявления события, упоминавшаяся ранее. Вот ее примерный синтаксис:

public event <Имя Делегата> <Имя события> { add {...} remove {...} }

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

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

class ManyEvents { //хэш таблица для хранения делегатов Hashtable DStore = new Hashtable(); public event EventHandler Ev1 { add { DStore["Ev1"]= (EventHandler)DStore["Ev1"]+ value; } remove { DStore["Ev1"]= (EventHandler)DStore["Ev1"]- value; } } public event EventHandler Ev2 { add { DStore["Ev2"]= (EventHandler)DStore["Ev2"]+ value; } remove { DStore["Ev2"]= (EventHandler)DStore["Ev2"]- value; } } public event EventHandler Ev3 { add { DStore["Ev3"]= (EventHandler)DStore["Ev3"]+ value; } remove { DStore["Ev3"]= (EventHandler)DStore["Ev3"]- value; } } public event EventHandler Ev4 { add { DStore["Ev4"]= (EventHandler)DStore["Ev4"]+ value; } remove { DStore["Ev4"]= (EventHandler)DStore["Ev4"]- value; } } public void SimulateEvs() { EventHandler ev = (EventHandler) DStore["Ev1"]; if(ev != null) ev(this, null); ev = (EventHandler) DStore["Ev3"]; if(ev != null) ev(this, null); } }//class ManyEvents




В нашем классе созданы четыре события и хэш-таблица DStore для их хранения. Все события принадлежат встроенному классу EventHandler. Когда к событию будет присоединяться обработчик, автоматически будет вызван метод add, который динамически создаст элемент хэш-таблиц. Ключом элемента является, в данном случае, строка с именем события. При отсоединении обработчика будет исполняться метод remove, выполняющий аналогичную операцию над соответствующим элементом хэш-таблицы. В классе определен также метод SimulateEvs, при вызове которого зажигаются два из четырех событий - Ev1 и Ev3.

Рассмотрим теперь класс ReceiverEvs, слушающий события. Этот класс построен по описанным ранее правилам. В нем есть ссылка на класс, создающий события; конструктор с параметром, которому передается реальный объект такого класса; четыре обработчика события - по одному на каждое, и метод OnConnect, связывающий обработчиков с событиями. Вот код класса:

class ReceiverEvs { private ManyEvents manyEvs; public ReceiverEvs( ManyEvents manyEvs) { this.manyEvs = manyEvs; OnConnect(); } public void OnConnect() { manyEvs.Ev1 += new EventHandler(H1); manyEvs.Ev2 += new EventHandler(H2); manyEvs.Ev3 += new EventHandler(H3); manyEvs.Ev4 += new EventHandler(H4); } public void H1(object s, EventArgs e) { Console.WriteLine("Событие Ev1"); } public void H2(object s, EventArgs e) { Console.WriteLine("Событие Ev2"); } public void H3(object s, EventArgs e) { Console.WriteLine("Событие Ev3"); } public void H4(object s, EventArgs e) { Console.WriteLine("Событие Ev4"); } }//class ReceiverEvs

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

public void TestManyEvents() { ManyEvents me = new ManyEvents(); ReceiverEvs revs = new ReceiverEvs(me); me.SimulateEvs(); }

Все работает предусмотренным образом.


Классы с событиями


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

Есть еще один механизм, позволяющий объектам вести себя по-разному в одних и тех же обстоятельствах. Это механизм событий, рассмотрением которого мы сейчас и займемся. Класс, помимо свойств и методов, может иметь события. Содержательно, событием является некоторое специальное состояние, в котором может оказаться объект класса. Так, для объектов класса "человек" событием может быть рождение или смерть, свадьба или развод. О событиях в мире программных объектов чаще всего говорят в связи с интерфейсными объектами, у которых события возникают по причине действий пользователя. Так, командная кнопка может быть нажата - событие Click, документ может быть закрыт - событие Close, в список может быть добавлен новый элемент - событие Changed.

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

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

Заметьте, что, зажигая событие, класс посылает сообщение получателям события - объектам некоторых других классов. Будем называть класс, зажигающий событие, классом - отправителем сообщения (sender). Класс, чьи объекты получают сообщения, будем называть классом - получателем сообщения (receiver). Класс-отправитель сообщения, в принципе, не знает своих получателей. Он отправляет сообщение в межмодульное пространство. Одно и то же сообщение может быть получено и по-разному обработано произвольным числом объектов разных классов. Взгляните на схему, демонстрирующую взаимодействие объектов при посылке и получении сообщения.


Рис. 21.1.  Взаимодействие объектов. Посылка и получение сообщения о событии



Классы с событиями, допустимые в каркасе .Net Framework


Если создавать повторно используемые компоненты с событиями, работающие не только в проекте C#, то необходимо удовлетворять некоторым ограничениям. Эти требования предъявляются к делегату; они носят, скорее, синтаксический характер, не ограничивая существа дела.

Перечислю эти ограничения:

делегат, задающий тип события, должен иметь фиксированную сигнатуру из двух аргументов: delegate <Имя_делегата> (object sender, <Тип_аргументов> args);первый аргумент задает объект sender, создающий сообщение. Второй аргумент args задает остальные аргументы - входные и выходные, - передаваемые обработчику. Тип этого аргумента должен задаваться классом, производным от встроенного в .Net Framework класса EventArgs. Если обработчику никаких дополнительных аргументов не передается, то следует просто указать класс EventArgs, передавая null в качестве фактического аргумента при включении события;рекомендуемое имя делегата - составное, начинающееся именем события, после которого следует слово EventHandler, например, FireEventHandler. Если никаких дополнительных аргументов обработчику не передается, то тогда можно вообще делегата не объявлять, а пользоваться стандартным делегатом с именем EventHandler.



Классы семейства геометрических фигур


Приведем теперь программные коды классов, являющихся потомками класса Figure.



Классы StackTrace и BooleanSwitch


В библиотеке FCL имеются и другие классы, полезные при отладке. Класс StackTrace позволяет получить программный доступ к стеку вызовов. Класс BooleanSwitch предоставляет механизм, аналогичный константам условной компиляции. Он разрешает определять константы, используемые позже в методе условной печати WriteIf классов Debug и Trace. Мощь этого механизма в том, что константы можно менять в файле конфигурации проекта, не изменяя код проекта и не требуя его перекомпиляции.



Клонирование и интерфейс ICloneable


Клонированием называется процесс создания копии объекта, а копия объекта называется его клоном. Различают два типа клонирования: поверхностное (shallow) и глубокое (deep). При поверхностном клонировании копируется сам объект. Все значимые поля клона получают значения, совпадающие со значениями полей объекта; все ссылочные поля клона являются ссылками на те же объекты, на которые ссылается и сам объект. При глубоком клонировании копируется вся совокупность объектов, связанных взаимными ссылками. Представьте себе мир объектов, описывающих людей. У этих объектов могут быть ссылки на детей и родителей, учителей и учеников, друзей и родственников. В текущий момент может существовать большое число таких объектов, связанных ссылками. Достаточно выбрать один из них в качестве корня, и при его клонировании воссоздастся копия существующей структуры объектов.

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

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

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

public Person StandartClone() { Person p = (Person)this.MemberwiseClone(); return(p); }

Теперь клиенты класса могут легко создавать поверхностные клоны. Вот пример:

public void TestStandartClone() { Person mother = new Person("Петрова Анна"); Person daughter = new Person("Петрова Ольга"); Person son = new Person("Петров Игорь"); mother[0] = daughter; mother[1] = son; Person mother_clone = mother.StandartClone(); Console.WriteLine("Дети матери: {0}",mother.Fam); Console.WriteLine (mother[0].Fam); Console.WriteLine (mother[1].Fam); Console.WriteLine("Дети клона: {0}",mother_clone.Fam); Console.WriteLine (mother_clone[0].Fam); Console.WriteLine (mother_clone[1].Fam); }




При создании клона будет создана копия только одного объекта mother. Обратите внимание: при работе с полем children, задающим детей, используется индексатор класса Person, выполняющий индексацию по этому полю. Вот как выглядят результаты работы теста.


Рис. 19.5.  Поверхностное клонирование

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

Давайте расширим наш класс, придав ему родительский интерфейс ICloneable. Реализация метода Clone будет отличаться от стандартной реализации тем, что к имени объекта - полю Fam - будет приписываться слово "clone". Вот как выглядит этот метод:

public object Clone() { Person p = new Person(this.fam + "_clone"); //копирование полей p.age = this.age; p.children = this.children; p.count_children = this.count_children; p.health = this.health; p.salary = this.salary; p.status = this.status; return (p); }

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

Person mother_clone2 = (Person)mother.Clone(); Console.WriteLine("Дети клона_2: {0}",mother_clone2.Fam); Console.WriteLine (mother_clone2[0].Fam); Console.WriteLine (mother_clone2[1].Fam);

Все работает должным образом.


Коллизия имен


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

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

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

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

public interface IProps { void Prop1(string s); void Prop2 (string name, int val); void Prop3(); } public interface IPropsOne { void Prop1(string s); void Prop2 (int val); void Prop3(); }




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

public class ClainTwo:IProps,IPropsOne { /// <summary> /// склеивание методов двух интерфейсов /// </summary> /// <param name="s"></param> public void Prop1 (string s) { Console.WriteLine(s); } /// <summary> /// перегрузка методов двух интерфейсов /// </summary> /// <param name="s"></param> /// <param name="x"></param> public void Prop2(string s, int x) { Console.WriteLine(s + "; " + x); } public void Prop2 (int x) { Console.WriteLine(x); } /// <summary> /// переименование методов двух интерфейсов /// </summary> void IProps.Prop3() { Console.WriteLine("Свойство 3 интерфейса 1"); } void IPropsOne.Prop3() { Console.WriteLine("Свойство 3 интерфейса 2"); } public void Prop3FromInterface1() { ((IProps)this).Prop3(); } public void Prop3FromInterface2() { ((IPropsOne)this).Prop3(); } }

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

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

public void TestCliTwoInterfaces() { Console.WriteLine("Объект ClainTwo вызывает методы двух интерфейсов!"); Cli.ClainTwo claintwo = new Cli.ClainTwo(); claintwo.Prop1("Склейка свойства двух интерфейсов"); claintwo.Prop2("перегрузка ::: ",99); claintwo.Prop2(9999); claintwo.Prop3FromInterface1(); claintwo.Prop3FromInterface2(); Console.WriteLine("Интерфейсный объект вызывает методы 1-го интерфейса!"); Cli.IProps ip1 = (Cli.IProps)claintwo; ip1.Prop1("интерфейс IProps: свойство 1"); ip1.Prop2("интерфейс 1 ", 88); ip1.Prop3(); Console.WriteLine("Интерфейсный объект вызывает методы 2-го интерфейса!"); Cli.IPropsOne ip2 = (Cli.IPropsOne)claintwo; ip2.Prop1("интерфейс IPropsOne: свойство1"); ip2.Prop2(7777); ip2.Prop3(); }

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


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


Консольный проект


У себя на компьютере я открыл установленную лицензионную версию Visual Studio .Net 2003, выбрал из предложенного меню - создание нового проекта на C#, установил вид проекта - консольное приложение, дал имя проекту - ConsoleHello, указал, где будет храниться проект. Как выглядит задание этих установок, показано на рис. 2.1.


Рис. 2.1.  Окно создания нового проекта

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


Рис. 2.2.  Среда разработки и консольное приложение, построенное по умолчанию

Интегрированная среда разработки IDE (Integrated Development Envirionment) Visual Studio является многооконной, настраиваемой, обладает большим набором возможностей. Внешний вид ее достаточно традиционен, хотя здесь есть новые возможности; я не буду заниматься ее описанием, полагаясь на опыт читателя и справочную систему. Обращаю внимание лишь на три окна, из тех, что показаны на рис. 2.2. В окне Solution Explorer представлена структура построенного решения. В окне Properties можно увидеть свойства выбранного элемента решения. В окне документов отображается выбранный документ, в данном случае, программный код класса проекта - ConsoleHello.Class1. Заметьте, в этом окне можно отображать и другие документы, список которых показан в верхней части окна.

Построенное решение содержит, естественно, единственный заданный нами проект - ConsoleHello. Наш проект, как показано на рис. 2.2, включает в себя папку со ссылками на системные пространства имен из библиотеки FCL, файл со значком приложения и два файла с уточнением cs. Файл AssemblyInfo содержит информацию, используемую в сборке, а файл со стандартным именем Class1 является построенным по умолчанию классом, который задает точку входа - процедуру Main, содержащую для данного типа проекта только комментарий.

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

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

Пространству имен может предшествовать одно или несколько предложений using, где после ключевого слова следует название пространства имен - из библиотеки FCL или из проектов, связанных с текущим проектом. В данном случае задается пространство имен System - основное пространство имен библиотеки FCL. Предложение using NameA облегчает запись при использовании классов, входящих в пространство NameA, поскольку в этом случае не требуется каждый раз задавать полное имя класса с указанием имени пространства, содержащего этот класс. Чуть позже мы увидим это на примере работы с классом Console пространства System. Заметьте, полное имя может потребоваться, если в нескольких используемых пространствах имен имеются классы с одинаковыми именами.

Все языки допускают комментарии. В C#, как и в С++, допускаются однострочные и многострочные комментарии. Первые начинаются с двух символов косой черты. Весь текст до конца строки, следующий за этой парой символов, (например, "//любой текст") воспринимается как комментарий, не влияющий на выполнение программного кода. Началом многострочного комментария является пара символов /*, а концом - */. Заметьте, тело процедуры Main содержит три однострочных комментария.

Здесь же, в проекте, построенном по умолчанию, мы встречаемся с еще одной весьма важной новинкой C# - XML-тегами, формально являющимися частью комментария. Отметим, что описанию класса Class1 и описанию метода Main предшествует заданный в строчном комментарии XML-тег <summary>. Этот тэг распознается специальным инструментарием, строящим XML-отчет проекта. Идея самодокументируемых программных проектов, у которых документация является неотъемлемой частью, является важной составляющей стиля компонентного надежного программирования на C#. Мы рассмотрим реализацию этой идеи в свое время более подробно, но уже с первых шагов будем использовать теги документирования и строить XML-отчеты. Заметьте, кроме тега <summary> возможны и другие тэги, включаемые в отчеты. Некоторые теги добавляются почти автоматически. Если в нужном месте (перед объявлением класса, метода) набрать подряд три символа косой черты, то автоматически вставится тэг документирования, так что останется только дополнить его соответствующей информацией.

Еще одна новинка C#, встречающаяся в начальном проекте, это атрибут [STAThread], который предшествует описанию процедуры Main. Так же, как и тэги документирования, атрибуты распознаются специальным инструментарием и становятся частью метаданных. Атрибуты могут быть как стандартными, так и заданными пользователем. Стандартные атрибуты используются CLR и влияют на то, как она будет выполнять проект. В данном случае атрибут [STAThread] (Single Thread Apartment) задает однопоточную модель выполнения. Об атрибутах и метаданных мы еще будем говорить подробно. Заметьте, если вы нечетко представляете, каков смысл однопоточной модели, и не хотите, чтобы в вашем тексте присутствовали непонятные для вас указания, то этот атрибут можно удалить из текста, что не отразится на выполнении.

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

Таков консольный проект, построенный по умолчанию. Функциональности у него немного. Его можно скомпилировать, выбрав соответствующий пункт из меню build. Если компиляция прошла без ошибок, то в результате будет произведена сборка и появится PE-файл в соответствующей папке Debug нашего проектa. Приложение можно запустить нажатием соответствующих клавиш (например, CTRL+F5) или выбором соответствующего пункта из меню Debug. Приложение будет выполнено под управлением CLR. В результате выполнения появится консольное окно с предложением нажать любую клавишу для закрытия окна.

Слегка изменим проект, построенный по умолчанию, добавим в него свой код и превратим его в классический проект приветствия. Нам понадобятся средства для работы с консолью - чтения с консоли (клавиатуры) и вывода на консоль (дисплей) строки текста. Библиотека FCL предоставляет для этих целей класс Console, среди многочисленных методов которого есть методы ReadLine и WriteLine с очевидной семантикой. Вот код проектa, полученный в результате моих корректировок:




using System; namespace ConsoleHello { /// <summary> /// Первый консольный проект - Приветствие /// </summary> class Class1 { /// <summary> /// Точка входа. Запрашивает имя и выдает приветствие /// </summary> static void Main() { Console.WriteLine("Введите Ваше имя"); string name; name = Console.ReadLine(); if (name=="") Console.WriteLine ("Здравствуй, мир!"); else Console.WriteLine("Здравствуй, " + name + "!"); } } }

Я изменил текст в тегах <summary>, удалил атрибут и аргументы процедуры Main, добавил в ее тело операторы ввода-вывода. Благодаря предложению using, мне не требуется при вызове методов класса Console каждый раз писать System.Console. Надеюсь, что программный текст понятен без дальнейших пояснений.

В завершение первого проектa построим его XML-отчет. Для этого в свойствах проектa необходимо указать имя файла, в котором будет храниться отчет. Установка этого свойства проектa, так же как и других свойств, делается в окне Property Pages, открыть которое можно по-разному. Я обычно делаю это так: в окне Solution Explorer выделяю строку с именем проектa, а затем в окне Properties нажимаю имеющуюся там кнопку Property Pages. Затем в открывшемся окне свойств, показанном на рис. 2.3, устанавливается нужное свойство. В данном случае я задал имя файла отчета hello.xml.


Рис. 2.3.  Окно Property Pages проекта и задание имени XML-отчета

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

<?xml version="1.0"?> <doc> <assembly> <name>ConsoleHello</name> </assembly> <members> <member name="T:ConsoleHello.Class1"> <summary> Первый консольный проект - Приветствие </summary> </member> <member name="M:ConsoleHello.Class1.Main"> <summary> Точка входа. Запрашивает имя и_выдает приветствие </summary> </member> </members> </doc>

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


Константы


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

y = 7.7f;

Значение константы "7.7f" является одновременно ее именем, оно же позволяет однозначно определить тип константы. Заметьте, иногда, как в данном случае, приходится добавлять к значению специальные символы для точного указания типа. Я не буду останавливаться на этих подробностях. Если возникает необходимость уточнить, как записываются литералы, то достаточно получить справку по этой теме. Делается все так же, как и в языке C++.

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

/// <summary> /// Константы /// </summary> public void Constants() { const int SmallSize = 38, LargeSize =58; const int MidSize = (SmallSize + LargeSize)/2; const double pi = 3.141593; //LargeSize = 60; //Значение константы нельзя изменить. Console.WriteLine("MidSize= {0}; pi={1}", MidSize, pi); }//Constants



Константы


В классе могут быть объявлены константы. Синтаксис объявления приводился в лекции 5. Константы фактически являются статическими полями, доступными только для чтения, значения которых задаются при инициализации. Однако задавать модификатор static для констант не только не нужно, но и запрещено. В нашем классе Person была задана константа Child_Max, характеризующая максимальное число детей у персоны.

Никаких проблем не возникает, когда речь идет о константах встроенных типов, таких, как Child_Max. Однако совсем не просто определить в языке C# константы собственного класса. Этот вопрос будет подробно рассматриваться чуть позже, когда речь пойдет о проектировании класса Rational.



Константы класса Rational


Рассмотрим важную проблему определения констант в собственном классе. Определим две константы 0 и 1 класса Rational. Кажется, что сделать это невозможно из-за ограничений, накладываемых на объявление констант. Напомню, константы должны быть инициализированы в момент объявления, и их значения должны быть заданы константными выражениями, известными в момент компиляции. Но в момент компиляции у класса Rational нет никаких известных константных выражений. Как же быть? Справиться с проблемой поможет статический конструктор, созданный для решения подобных задач. Роль констант класса будут играть статические поля, объявленные с атрибутом readonly, то есть доступные только для чтения. Нам также будет полезен закрытый конструктор класса. Еще укажем, что введение констант класса требует использования экзотических средств языка C#. Вначале определим закрытый конструктор:

private Rational(int a, int b, string t) { m = a; n = b; }

Не забудем, что при перегрузке методов (в данном случае конструкторов) сигнатуры должны различаться, и поэтому пришлось ввести дополнительный аргумент t для избежания конфликтов. Поскольку конструктор закрытый, то гарантируется корректное задание аргументов при его вызове. Определим теперь константы класса, которые, как я уже говорил, задаются статическими полями с атрибутом readonly:

//Константы класса 0 и 1 - Zero и One public static readonly Rational Zero, One;

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

static Rational() { Console.WriteLine("static constructor Rational"); Zero = new Rational(0, 1, "private"); One = new Rational (1, 1, "private"); }//Статический конструктор

Как это все работает? Статический конструктор вызывается автоматически один раз до начала работы с объектами класса. Он и задаст значения статических полей Zero, One, представляющих рациональные числа с заданным значением. Поскольку эти поля имеют атрибут static и readonly, то они доступны для всех объектов класса и не изменяются в ходе вычислений, являясь настоящими константами класса. Прежде чем привести пример работы с константами, давайте добавим в наш класс важные булевы операции над рациональными числами - равенство и неравенство, больше и меньше. При этом две последние операции сделаем перегруженными, позволяя сравнивать рациональные числа с числами типа double:

public static bool operator ==(Rational r1, Rational r2) { return((r1.m ==r2.m)&& (r1.n ==r2.n)); } public static bool operator !=(Rational r1, Rational r2) { return((r1.m !=r2.m) (r1.n !=r2.n)); } public static bool operator <(Rational r1, Rational r2) { return(r1.m * r2.n < r2.m* r1.n); } public static bool operator >(Rational r1, Rational r2) { return(r1.m * r2.n > r2.m* r1.n); } public static bool operator <(Rational r1, double r2) { return((double)r1.m / (double)r1.n < r2); } public static bool operator >(Rational r1, double r2) { return((double)r1.m / (double)r1.n > r2); }




Наш последний пример демонстрирует работу с константами, булевыми и арифметическими выражениями над рациональными числами:

public void TestRationalConst() { Rational r1 = new Rational(2,8), r2 =new Rational(2,5); Rational r3 = new Rational(4, 10), r4 = new Rational(3,7); Rational r5 = Rational.Zero, r6 = Rational.Zero; if ((r1 != Rational.Zero) && (r2 == r3))r5 = (r3+Rational.One)*r4; r6 = Rational.One + Rational.One; r1.PrintRational("r1: (2,8)"); r2.PrintRational ("r2: (2,5)"); r3.PrintRational("r3: (4,10)"); r4.PrintRational("r4: (3,7)"); r5.PrintRational("r5: ((r3 +1)*r4)"); r6.PrintRational("r6: (1+1)"); }

Результаты работы этого примера показаны на рис. 16.6.


Рис. 16.6.  Константы и выражения типа Rational


Конструкторы класса


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

Как и когда происходит создание объектов? Чаще всего, при объявлении сущности в момент ее инициализации. Давайте обратимся к нашему последнему примеру и рассмотрим создание трех объектов класса Person:

Person pers1 = new Person(), pers2 = new Person(); Person pers3= new Person("Петрова");

Сущности pers1, pers2 и pers3 класса Person объявляются с инициализацией, задаваемой унарной операцией new, которой в качестве аргумента передается конструктор класса Person. У класса может быть несколько конструкторов - это типичная практика, - отличающихся сигнатурой. В данном примере в первой строке вызывается конструктор без аргументов, во второй строке для сущности pers3 вызывается конструктор с одним аргументом типа string. Разберем в деталях процесс создания:

первым делом для сущности pers создается ссылка, пока висячая, со значением null;затем в динамической памяти создается объект - структура данных с полями, определяемыми классом Person. Поля объекта инициализируются значениями по умолчанию: ссылочные поля - значением null, арифметические - нулями, строковые - пустой строкой. Эту работу выполняет конструктор по умолчанию, который, можно считать, всегда вызывается в начале процесса создания. Заметьте, если инициализируется переменная значимого типа, то все происходит аналогичным образом, за исключением того, что объект создается в стеке;если поля класса проинициализированы, как в нашем примере, то выполняется инициализация полей заданными значениями;если вызван конструктор с аргументами, то начинает выполняться тело этого конструктора. Как правило, при этом происходит инициализация отдельных полей класса значениями, переданными конструктору. Так, поле fam объекта pers3 получает значение "Петрова";На заключительном этапе ссылка связывается с созданным объектом.




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

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

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

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

static Person() { Console.WriteLine("Выполняется статический конструктор!"); }

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

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


Конструкторы класса Rational


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

/// <summary> /// Конструктор класса. Создает рациональное число /// m/n, эквивалентное a/b, но со взаимно несократимыми /// числителем и знаменателем. Если b=0, то результатом /// является рациональное число 0 -пара (0,1). /// </summary> /// <param name="a">числитель</param> /// <param name="b">знаменатель</param> public Rational(int a, int b) { if(b==0) {m=0; n=1;} else { //приведение знака if( b<0) {b=-b; a=-a;} //приведение к несократимой дроби int d = nod(a,b); m=a/d; n=b/d; } }

Как видите, конструктор класса может быть довольно сложным.

В нем, как в нашем случае, может проверяться корректность задаваемых аргументов. Для рациональных чисел мы полагаем, что задание нулевого знаменателя означает задание рационального числа 0, и это эквивалентно заданию пары (0, 1). В остальных случаях выполняется приведение заданной пары чисел к эквивалентному рациональному числу с несократимыми числителем и знаменателем. По ходу дела вызывается закрытый метод класса, вычисляющий значение НОД(a,b) - наибольшего общего делителя чисел a и b.



Конструкторы родителей и потомков


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

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

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

public Derived() {} public Derived(string name, int cred, int deb):base (name,cred) { debet = deb; }

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

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



Корректность и устойчивость программных систем


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

В лекции 9 введено строгое понятие корректности метода по отношению к его спецификациям, заданным в виде предусловия и постусловия метода.

Корректность - это способность программной системы работать в строгом соответствии со своей спецификацией. Отладка - процесс, направленный на достижение корректности.

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

Почему так трудно создавать корректные и устойчивые программные системы? Все дело в сложности разрабатываемых систем. Когда в 60-х годах прошлого века фирмой IBM создавалась операционная система OS-360, то на ее создание потребовалось 5000 человеко-лет, и проект по сложности сравнивался с проектом высадки первого человека на Луну. Сложность нынешних сетевых операционных систем, систем управления хранилищами данных, прикладных систем программирования на порядки превосходит сложность OS-360, так что, несмотря на прогресс, достигнутый в области технологии программирования, проблемы, стоящие перед разработчиками, не стали проще.



Корректность методов


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

Спецификации можно задавать по-разному. Мы определим их здесь через понятия предусловий и постусловий метода, используя символику триад Xoара, введенных Чарльзом Энтони Хоаром - выдающимся программистом и ученым, одну из знаменитых программ которого приведем чуть позже в этой лекции.

Пусть P(x,z) - программа P с входными аргументами x и выходными z. Пусть Q(y) - некоторое логическое условие (предикат) над переменными программы y. Язык для записи предикатов Q(y) формализовать не будем. Отметим только, что он может быть шире языка, на котором записываются условия в программах, и включать, например, кванторы. Предусловием программы P(x,z) будем называть предикат Pre(x), заданный на входах программы. Постусловием программы P(x,z) будем называть предикат Post(x,z), связывающий входы и выходы программы. Для простоты будем полагать, что программа P не изменяет своих входов x в процессе своей работы. Теперь несколько определений:

Определение 1 (частичной корректности): Программа P(x,z) корректна (частично, или условно) по отношению к предусловию Pre(x) и постусловию Post(x,z), если из истинности предиката Pre(x) следует, что для программы P(x,z), запущенной на входе x, гарантируется выполнение предиката Post(x,z) при условии завершения программы.

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

[Pre(x)]P(x,z)[Post(x,z)]

Определение 2 (полной корректности): Программа P(x,z) корректна (полностью, или тотально) по отношению к предусловию Pre(x) и постусловию Post(x,z), если из истинности предиката Pre(x) следует, что для программы P(x,z), запущенной на входе x, гарантируется ее завершение и выполнение предиката Post(x,z).

Условие полной корректности записывается в виде триады Хоара, связывающей программу с ее предусловием и постусловием:

{Pre(x)}P(x,z){Post(x,z)}




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

Корректная программа говорит своим клиентам: если вы хотите вызвать меня и ждете гарантии выполнения постусловия после моего завершения, то будьте добры гарантировать выполнение предусловия на входе. Задание предусловий и постусловий методов - это такая же важная часть работы программиста, как и написание самого метода. На языке C# пред- и постусловия обычно задаются в теге <summary>, предшествующем методу, и являются частью XML-отчета. К сожалению, технология работы в Visual Studio не предусматривает возможности автоматической проверки предусловия перед вызовом метода и проверки постусловия после его завершения с выбрасыванием исключений в случае их невыполнения. Программисты, для которых требование корректности является важнейшим условием качества их работы, сами встраивают такую проверку в свои программы. Как правило, подобная проверка обязательна на этапе отладки и может быть отключена в готовой системе, в корректности которой программист уже уверен. А вот проверку предусловий важно оставлять и в готовой системе, поскольку истинность предусловий должен гарантировать не разработчик метода, а клиент, вызывающий метод. Клиентам же свойственно ошибаться и вызывать метод в неподходящих условиях.

Формальное доказательство корректности метода - задача ничуть не проще, чем написание корректной программы. Но вот парадокс. Чем сложнее метод, его алгоритм, а следовательно, и само доказательство, тем важнее использовать понятия предусловий и постусловий, понятия инвариантов циклов в процессе разработки метода. Рассмотрение этих понятий параллельно с разработкой метода может существенно облегчить построение корректного метода. Этот подход будет продемонстрирован в нашей лекции при рассмотрении метода QuickSort - быстрой сортировки массива.


Логические операции


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

int k1 = 7; if (k1) Console.WriteLine("ok!");

незаконна в программах на C#. На этапе трансляции возникнет ошибка, поскольку вычисляемое условие имеет тип int, а неявное преобразование этого типа к типу bool отсутствует.

В языке C# более строгие правила действуют и для логических операций. Так, запись

if(k1 && (x>y)),

корректная в языке C++, приводит к ошибке в программах на C#, поскольку операция && определена только для операндов типа bool, а в данном выражении один из операндов имеет тип int. В языке C# в данных ситуациях следует использовать записи:

if(k1>0) if((k1>0) && (x>y))

После этого важного предупреждения перейду к более систематическому изложению некоторых особенностей выполнения логических операций. Так же, как и в языке C++, логические операции делятся на две категории: одни выполняются над логическими значениями операндов, другие осуществляют выполнение логической операции над битами операндов. По этой причине в C# существуют две унарные операции отрицания - логическое отрицание, заданное операцией "!", и побитовое отрицание, заданное операцией "~". Первая из них определена над операндом типа bool, вторая - над операндом целочисленного типа, начиная с типа int и выше (int, uint, long, ulong). Результатом операции во втором случае является операнд, в котором каждый бит заменен его дополнением. Приведу пример:

/// <summary> /// Логические выражения /// </summary> public void Logic() { //операции отрицания ~,! bool b1,b2; b1 = 2*2==4; b2 =!b1; //b2= ~b1; uint j1 =7, j2; j2= ~j1; //j2 = !j1; int j4 = 7, j5; j5 = ~j4; Console.WriteLine("uint j2 = " + j2 +" int j5 = " + j5); }//Logic




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

uint j2 = 4294967288 int j5 = -8

Бинарные логические операции "&& - условное И" и " - условное ИЛИ" определены только над данными типа bool. Операции называются условными или краткими, поскольку, будет ли вычисляться второй операнд, зависит от уже вычисленного значения первого операнда. В операции "&&", если первый операнд равен значению false, то второй операнд не вычисляется и результат операции равен false. Аналогично, в операции "", если первый операнд равен значению true, то второй операнд не вычисляется и результат операции равен true. Ценность условных логических операций заключается не в их эффективности по времени выполнения. Часто они позволяют вычислить логическое выражение, имеющее смысл, но в котором второй операнд не определен. Приведу в качестве примера классическую задачу поиска по образцу в массиве, когда разыскивается элемент с заданным значением (образец). Такой элемент в массиве может быть, а может и не быть. Вот типичное решение этой задачи в виде упрощенном, но передающем суть дела:

//Условное And - && int[] ar= {1,2,3}; int search = 7; int i=0; while ((i < ar.Length) && (ar[i]!= search)) i++; if(i<ar.Length) Console.WriteLine("Образец найден"); else Console.WriteLine("Образец не найден");

Если значение переменной search (образца) не совпадает ни с одним из значений элементов массива ar, то последняя проверка условия цикла while будет выполняться при значении i, равном ar.Length. В этом случае первый операнд получит значение false, и, хотя второй операнд при этом не определен, цикл нормально завершит свою работу. Второй операнд не определен в последней проверке, поскольку индекс элемента массива выходит за допустимые пределы (в C# индексация элементов начинается с нуля). Заметьте, что "нормальная" конъюнкция требует вычисления обеих операндов, поэтому ее применение в данной программе приводило бы к выбросу исключения в случае, когда образца нет в массиве.

Три бинарные побитовые операции - "& - AND " , "| - OR ", "^ - XOR" используются двояко. Они определены как над целыми типами выше int, так и над булевыми типами. В первом случае они используются как побитовые операции, во втором - как обычные логические операции. Иногда необходимо, чтобы оба операнда вычислялись в любом случае, тогда без этих операций не обойтись. Вот пример первого их использования:

//Логические побитовые операции And, Or, XOR (&,|,^) int k2 = 7, k3 = 5, k4, k5, k6; k4 = k2 & k3; k5 = k2| k3; k6 = k2^k3; Console.WriteLine("k4 = " + k4 + " k5 = " + k5 + " k6 = " + k6);

Приведу результаты вывода:

k4 = 5 k5 = 7 k6 =2

Приведу пример поиска по образцу с использованием логического AND:

i=0; search = ar[ar.Length - 1]; while ((i < ar.Length) & (ar[i]!= search)) i++; if(i<ar.Length) Console.WriteLine("Образец найден"); else Console.WriteLine("Образец не найден");

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


Локальные переменные


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

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

На самом деле, ситуация с процедурным блоком в C# не так проста. Процедурный блок имеет сложную структуру; в него могут быть вложены другие блоки, связанные с операторами выбора, цикла и так далее. В каждом таком блоке, в свою очередь, допустимы вложения блоков. В каждом внутреннем блоке допустимы объявления переменных. Переменные, объявленные во внутренних блоках, локализованы именно в этих блоках, их область видимости и время жизни определяются этими блоками. Локальные переменные начинают существовать при достижении вычислений в блоке точки объявления и перестают существовать, когда процесс вычисления завершает выполнение операторов блока. Можно полагать, что для каждого такого блока выполняется так называемый пролог и эпилог. В прологе локальным переменным отводится память, в эпилоге память освобождается. Фактически ситуация сложнее, поскольку выделение памяти, а следовательно, и начало жизни переменной, объявленной в блоке, происходит не в момент входа в блок, а лишь тогда, когда достигается точка объявления локальной переменной.

Давайте обратимся к примеру. В класс Testing добавлен метод с именем ScopeVar, вызываемый в процедуре Main. Вот код этого метода:

/// <summary> /// Анализ области видимости переменных /// </summary> /// <param name="x"></param> public void ScopeVar(int x) { //int x=0; int y =77; string s = name; if (s=="Точка1") { int u = 5; int v = u+y; x +=1; Console.WriteLine("y= {0}; u={1}; v={2}; x={3}", y,u,v,x); } else { int u= 7; int v= u+y; Console.WriteLine("y= {0}; u={1}; v={2}", y,u,v); } //Console.WriteLine("y= {0}; u={1}; v={2}",y,u,v); //Локальные переменные не могут быть статическими. //static int Count = 1; //Ошибка: использование sum до объявления //Console.WriteLine("x= {0}; sum ={1}", x,sum); int i;long sum =0; for(i=1; i<x; i++) { //ошибка: коллизия имен: y //float y = 7.7f; sum +=i; } Console.WriteLine("x= {0}; sum ={1}", x,sum); }//ScopeVar




Заметьте, в теле метода встречаются имена полей, аргументов и локальных переменных. Эти имена могут совпадать. Например, имя x имеет поле класса и формальный аргумент метода. Это допустимая ситуация. В языке C# разрешено иметь локальные переменные с именами, совпадающими с именами полей класса, - в нашем примере таким является имя y; однако, запрещено иметь локальные переменные, имена которых совпадают с именами формальных аргументов. Этот запрет распространяется не только на внешний уровень процедурного блока, что вполне естественно, но и на все внутренние блоки.

В процедурный блок вложены два блока, порожденные оператором if. В каждом из них объявлены переменные с одинаковыми именами u и v. Это корректные объявления, поскольку время существования и области видимости этих переменных не пересекаются. Итак, для невложенных блоков разрешено объявление локальных переменных с одинаковыми именами. Заметьте также, что переменные u и v перестают существовать после выхода из блока, так что операторы печати, расположенные внутри блока, работают корректно, а оператор печати вне блока приводит к ошибке, - u и v здесь не видимы, кончилось время их жизни. По этой причине оператор закомментирован.

Выражение, проверяемое в операторе if, зависит от значения поля name. Значение поля глобально для метода и доступно всюду, если только не перекрывается именем аргумента (как в случае с полем x) или локальной переменной (как в случае с полем y).

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


Массивы как коллекции


В ряде задач массивы C# целесообразно рассматривать как коллекции, не используя систему индексов для поиска элементов. Это, например, задачи, требующие однократного или многократного прохода по всему массиву - нахождение суммы элементов, нахождение максимального элемента, печать элементов. В таких задачах вместо циклов типа For по каждому измерению достаточно рассмотреть единый цикл For Each по всей коллекции. Эта возможность обеспечивается тем, что класс Array наследует интерфейс IEnumerable. Обратите внимание, этот интерфейс обеспечивает только возможность чтения элементов коллекции (массива), не допуская их изменения. Применим эту стратегию и построим еще одну версию процедуры печати. Эта версия будет самой короткой и самой универсальной, поскольку подходит для печати массива, независимо от его размерности и типа элементов. Вот ее код:

public static void PrintCollection(string name,Array A) { Console.WriteLine(name); foreach (object item in A ) Console.Write("\t {0}", item); Console.WriteLine(); }//PrintCollection

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

К сожалению, ситуация с чтением и записью элементов массива не симметрична. Приведу вариант процедуры CreateCollection:

public static void CreateCollection(Array A) { int i=0; foreach (object item in A ) //item = rnd.Next(1,10); //item read only A.SetValue(rnd.Next(1,10), i++); }//CreateCollection

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



Массивы массивов


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

В каких ситуациях может возникать необходимость в таких структурах данных? Эти массивы могут применяться для представления деревьев, у которых узлы могут иметь произвольное число потомков. Таковым может быть, например, генеалогическое дерево. Вершины первого уровня - Fathers, представляющие отцов, могут задаваться одномерным массивом, так что Fathers[i] - это i-й отец. Вершины второго уровня представляются массивом массивов - Children, так что Children[i] - это массив детей i-го отца, а Children[i][j] - это j-й ребенок i-го отца. Для представления внуков понадобится третий уровень, так что GrandChildren [i][j][k] будет представлять к-го внука j-го ребенка i-го отца.

Есть некоторые особенности в объявлении и инициализации таких массивов. Если при объявлении типа многомерных массивов для указания размерности использовались запятые, то для изрезанных массивов применяется более ясная символика - совокупности пар квадратных скобок; например, int[][] задает массив, элементы которого - одномерные массивы элементов типа int.

Сложнее с созданием самих массивов и их инициализацией. Здесь нельзя вызвать конструктор new int[3][5], поскольку он не задает изрезанный массив. Фактически нужно вызывать конструктор для каждого массива на самом нижнем уровне. В этом и состоит сложность объявления таких массивов. Начну с формального примера:

//массив массивов - формальный пример //объявление и инициализация int[][] jagger = new int[3][] { new int[] {5,7,9,11}, new int[] {2,8}, new int[] {6,12,4} };

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

int[][] jagger1 = new int[3][] { new int[4], new int[2], new int[3] };




В этом случае элементы массива получат при инициализации нулевые значения. Реальную инициализацию нужно будет выполнять программным путем. Стоит заметить, что в конструкторе верхнего уровня константу 3 можно опустить и писать просто new int[][]. Самое забавное, что вызов этого конструктора можно вообще опустить - он будет подразумеваться:

int[][] jagger2 = { new int[4], new int[2], new int[3] };

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

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

//массив массивов -"Отцы и дети" int Fcount =3; string[] Fathers = new string[Fcount]; Fathers[0] ="Николай"; Fathers[1] = "Сергей"; Fathers[2] = "Петр"; string[][] Children = new string[Fcount][]; Children[0] = new string[] {"Ольга", "Федор"}; Children[1] = new string[] {"Сергей","Валентина","Ира","Дмитрий"}; Children[2] = new string[]{"Мария","Ирина","Надежда"}; myar.PrintAr3(Fathers,Children);

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

Я не буду демонстрировать работу с генеалогическим деревом, ограничусь лишь печатью этого массива. Здесь есть несколько поучительных моментов. В классе Arrs для печати массива создан специальный метод PrintAr3, которому в качестве аргументов передаются массивы Fathers и Children. Вот текст данной процедуры:

public void PrintAr3(string [] Fathers, string[][] Children) { for(int i = 0; i < Fathers.Length; i++) { Console.WriteLine("Отец : {0}; Его дети:", Fathers[i]); for(int j = 0; j < Children[i].Length; j++) Console.Write( Children[i][j] + " "); Console.WriteLine(); } }//PrintAr3

Приведу некоторые комментарии к этой процедуре:

Внешний цикл по i организован по числу элементов массива Fathers. Заметьте, здесь используется свойство Length, в отличие от ранее применяемого метода GetLength.В этом цикле с тем же успехом можно было бы использовать и имя массива Children. Свойство Length для него возвращает число элементов верхнего уровня, совпадающее, как уже говорилось, с числом элементов массива Fathers.Во внутреннем цикле свойство Length вызывается для каждого элемента Children[i], который является массивом.Остальные детали, надеюсь, понятны.

Приведу вывод, полученный в результате работы процедуры PrintAr3.


Рис. 11.3.  Дерево "Отцы и дети"