Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
c# создатель Mind Map: c#

1. 2020 г лекции

1.1. 24.04.2020 Лекция 25: Финальный проект

1.1.1. Абстрактный класс Figure

1.1.1.1. Приведем код класса:

1.1.1.1.1. using System; using System.Drawing; namespace Shapes { /// <summary> /// Figure - это абстрактный класс; прародитель семейства /// классов геометрических фигур. Все фигуры имеют: /// центр - center, масштаб - scale. статус /// перетаскивания - dragged center - объект встроенного /// класса (структуры) Point. Этот объект задает характерную /// точку фигуры - чаще всего ее центр (тяжести) /// scale задает масштаб фигуры, первоначально единичный. /// drugged = true, когда фигура следует за курсором мыши. /// над фигурами определены операции: параллельный /// перенос - Move(a,b) масштабирование - Scale(s) /// Показ фигуры - Show. Область захвата - Region_Capture /// возвращает прямоугольник, характерный для фигуры, /// перетаскивание фигуры возможно при установке курсора /// мыши в области захвата. /// </summary> abstract public class Figure { /// <summary> /// закрытые для клиентов атрибуты класса - center, scale /// </summary> protected Point center; protected double scale ; protected bool dragged; protected Color color; //Доступ к свойствам public Point center_figure { get {return(center);} set {center = value;} } public double scale_figure { get {return(scale);} set {scale = value;} } public bool dragged_figure { get {return(dragged);} set {dragged = value;} } public Color color_figure { get {return(color);} set {color = value;} } /// <summary> /// базовый конструктор фигур /// </summary> /// <param name="x">координата X характерной точки ///фигуры</param> /// <param name="y">Координата Y характерной точки ///фигуры</param> public Figure(int x, int y) { center = new Point(x,y); scale = 1; dragged = false; color = Color.ForestGreen; } /// <summary> /// отложенный метод /// Параллельный перенос фигуры на (a,b) /// require : true; /// ensure : для любой точки фигуры p(x,y): /// x = old(x) +a; y = old(y) + b; /// </summary> /// <param name="a">a - перемещение по горизонтали ///вправо </param> /// <param name="b">b - перемещение по вертикали ///вниз</param> /// Замечание: Для того, чтобы фигура при рисовании была /// полностью видимой, координаты всех ее точек должны /// быть в пределах области рисования. public void Move (int a,int b) { center.X +=a; center.Y += b; } /// <summary> /// изменяет масштаб фигуры /// </summary> /// <param name="s">масштаб изменяется в s раз</param> public void Scale(double s) { scale*=s; } /// <summary> /// рисование фигуры в окне, передающем объекты g и pen /// </summary> /// <param name="g"> графический объект, методы которого /// рисуют фигуру</param> /// <param name="pen">перо рисования</param> public abstract void Show(Graphics g, Pen pen, Brush brush); public abstract System.Drawing.Rectangle Region_Capture(); }

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

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

1.1.2.1.1. Класс Ellipse

1.1.2.1.2. Класс Circle

1.1.2.1.3. Класс LittleCircle

1.1.2.1.4. Класс Rect

1.1.2.1.5. Класс Square

1.1.2.1.6. Класс Person

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

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

1.1.3.1.1. using System; namespace Shapes { /// <summary> /// Класс TwoWayList(G) описывает двусвязный список с /// курсором. Элементами списка являются объекты /// TwoLinkable, хранящие, помимо указателей на двух /// преемников, объекты типа G.Курсор будет определять /// текущий (активный) элемент списка. Класс будет /// определять симметричные операции по отношению к /// курсору. /// Конструкторы: /// Конструктор без параметров будет создавать пустой /// список /// Запросы: /// empty: require: true; возвращает true для пустого списка /// item: require: not empty(); возвращает активный элемент типа G; /// require: true; возвращает число элементов списка; /// count: count in[0,n] (count == 0) eqviv empty(); /// index: require: not empty(); возвращает индекс активного элемента. /// search_res: require: true; возвращает true, если последний поиск был успешным. /// Команды: /// put_left(elem): require: true; /// ensure: добавить новый элемент (elem) слева от курсора; /// put_right(elem): require: true; /// ensure: добавить новый элемент (elem) справа от курсора; /// remove: require: not empty(); /// ensure: удалить активный элемент; /// особо обрабатывается удаление последнего и единственного элементов /// операции с курсором: /// start: require: true; /// ensure: сделать активным первый элемент; /// finish: require: true; /// ensure: сделать активным последний элемент; /// go_prev: require: not (index = 1); /// ensure: сделать активным предыдущий элемент; /// go_next: require: not (index = count); /// ensure: сделать активным последующий элемент; /// go_i(i): require: (i in [1, count]); /// ensure: сделать активным элемент с индексом i; /// операции поиска: /// search_prev(elem): require: not (index = 1); /// ensure: сделать активным первый элемент elem слева от курсора; /// Успех или неуспех поиска сохранять в булевской /// переменной search_res /// search_next: require: not (index = count); /// ensure: сделать активным первый элемент elem справа от курсора; /// успех или неуспех поиска сохранять в булевской переменной search_res /// </summary> public class TwoWayList { public TwoWayList() { first = cursor = last = null; count = index = 0; search_res = false; }//конструктор /// <summary> /// first, cursor, last - ссылки на первый, /// активный и последний элементы списка /// Запросы count, index search_res также /// реализуются атрибутами. /// Запросы empty, item реализуются функциями /// </summary> protected TwoLinkable first, cursor, last; protected int count, index; protected bool search_res; //доступ на чтение к закрытым свойствам; public int Count { get { return(count); } } public int Index { get { return(index); } } public bool Search_res { get { return(search_res); } } /// <summary> /// require: true; возвращает true для непустого списка /// </summary> /// <returns></returns> public bool empty() { return(first == null); }//empty /// <summary> /// require: not empty(); возвращает активный /// элемент типа G; /// </summary> /// <returns></returns> public Figure item() { return(cursor.Item); }//item /// <summary> /// require: true; /// ensure: добавить новый элемент (elem) слева /// от курсора; /// </summary> /// <param name="elem">Тип Figure играет роль /// родового типа G /// хранимого элемента elem</param> public void put_left(Figure elem) { TwoLinkable newitem = new TwoLinkable(); newitem.Item = elem; newitem.Next = cursor; if (empty()) //список пуст { first = cursor = last = newitem; index =1; count = 1; } else { if (index == 1) first =newitem; else cursor.Prev.Next = newitem; newitem.Prev = cursor.Prev; cursor.Prev = newitem; count++; index++; } }//put_right /// <summary> /// require: true; /// ensure: добавить новый элемент (elem) справа /// от курсора; /// </summary> /// <param name="elem">Тип Figure играет роль /// родового типа G /// хранимого элемента elem</param> public void put_right(Figure elem) { TwoLinkable newitem = new TwoLinkable(); newitem.Item = elem; newitem.Prev = cursor; if (empty()) //список пуст { first = cursor = last = newitem; index =1; count = 1; } else { if (index == count) last =newitem; else cursor.Next.Prev = newitem; newitem.Next = cursor.Next; cursor.Next = newitem; count++; } }//put_right public void remove() { if(count == 1) { first = last = cursor = null; index=0; } else if(index==1) { first = cursor.Next; cursor.Prev = null; cursor = cursor.Next; } else if(index == count) { last = cursor.Prev; cursor.Next = null; cursor = cursor.Prev; index--; } else { cursor.Prev.Next = cursor.Next; cursor.Next.Prev = cursor.Prev; cursor = cursor.Next; } count--; }//remove /// операции с курсором: /// <summary> /// start: require: true; /// ensure: сделать активным первый элемент; /// </summary> public void start() { cursor = first; index = 1; }//start /// <summary> /// finish: require: true; /// ensure: сделать активным последний элемент; /// </summary> public void finish() { cursor = last; index = count; }//finish /// <summary> /// go_prev: require: not (index = 1); /// ensure: сделать активным предыдущий элемент; /// </summary> public void go_prev() { cursor = cursor.Prev; index--; }// go_prev /// <summary> /// go_next: require: not (index = count); /// ensure: сделать активным последующий элемент; /// </summary> public void go_next() { cursor = cursor.Next; index++; }// go_next /// <summary> /// go_i(i): require: (i in [1, count]); /// ensure: сделать активным элемент с индексом i; /// </summary> /// <param name="i"></param> public void go_i(int i) { if(i >index) while (i>index) { cursor = cursor.Next; index++; } else if(i<index) while (i<index) { cursor = cursor.Prev; index--; } }// go_i /// операции поиска: /// <summary> /// search_prev(elem): require: not (index = 1); /// ensure: сделать активным первый элемент elem /// слева от курсора; /// </summary> /// <param name="elem">искомый элемент</param> public virtual void search_prev(Figure elem) { bool found = false; while (!found && (index !=1)) { cursor = cursor.Prev; index--; found = (elem == item()); } search_res = found; }// search_prev /// <summary> /// успех или неуспех поиска сохранять в булевской /// переменной search_res /// search_next: require: not (index = count); /// ensure: сделать активным первый элемент elem /// справа от курсора; /// успех или неуспех поиска сохранять в булевской /// переменной search_res /// </summary> /// <param name="elem"></param> public virtual void search_next(Figure elem) { bool found = false; while (!found && (index !=count)) { cursor = cursor.Next; index++; found = (elem == item()); } search_res = found; }//search_next } }

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

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

1.1.4.1.1. 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 }

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

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

1.1.5.1.1. using System; using System.Drawing; using System.Collections; using System.ComponentModel; using System.Windows.Forms; using System.Data; using Shapes; namespace Final { /// <summary> /// Эта форма обеспечивает интерфейс для создания, /// рисования, показа, перемещения, сохранения в списке /// и выполнения других операций над объектами семейства /// геометрических фигур. Форма имеет меню и /// инструментальные панели. /// </summary> public class Form1 : System.Windows.Forms.Form { //fields Graphics graphic; Brush brush, clearBrush; Pen pen, clearPen; Color color; Figure current; TwoWayList listFigure; private System.Windows.Forms.MainMenu mainMenu1; private System.Windows.Forms.ImageList imageList1; private System.Windows.Forms.ToolBar toolBar1; private System.Windows.Forms.MenuItem menuItem1; // аналогичные определения для других элементов меню private System.Windows.Forms.MenuItem menuItem35; private System.Windows.Forms.ToolBarButton toolBarButton1; // аналогичные определения для других командных кнопок private System.Windows.Forms.ToolBarButton toolBarButton18; private System.ComponentModel.IContainer components; public Form1() { InitializeComponent(); InitFields(); } void InitFields() { graphic = CreateGraphics(); color = SystemColors.ControlText; brush = new SolidBrush(color); clearBrush = new SolidBrush(SystemColors.Control); pen = new Pen(color); clearPen = new Pen(SystemColors.Control); listFigure = new TwoWayList(); current = new Person(20, 50, 50); } /// <summary> /// Clean up any resources being used. /// </summary> protected override void Dispose( bool disposing ) { if( disposing ) { if (components != null) { components.Dispose(); } } base.Dispose( disposing ); } #region Windows Form Designer generated code /// <summary> /// Required method for Designer support - do not modify /// the contents of this method with the code editor. /// </summary> private void InitializeComponent() { // Код, инициализирующий компоненты и построенный // дизайнером, опущен } #endregion /// <summary> /// Точка входа в приложение - процедура Main, /// запускающая форму /// </summary> [STAThread] static void Main() { Application.Run(new Form1()); } private void menuItem7_Click(object sender, System.EventArgs e) { createEllipse(); } void createEllipse() { //clear old figure if (current != null) current.Show(graphic, clearPen, clearBrush); //create ellipse current = new Ellipse(50, 30, 180,180); } private void menuItem8_Click(object sender, System.EventArgs e) { createCircle(); } void createCircle() { //clear old figure if (current != null) current.Show(graphic, clearPen, clearBrush); //create circle current = new Circle(30, 180,180); } private void menuItem9_Click(object sender, System.EventArgs e) { createLittleCircle(); } void createLittleCircle() { //clear old figure if (current != null) current.Show(graphic, clearPen, clearBrush); //create littlecircle current = new LittleCircle(180,180); } private void menuItem10_Click(object sender, System.EventArgs e) { createRectangle(); } void createRectangle() { //clear old figure if (current != null) current.Show(graphic, clearPen, clearBrush); //create rectangle current = new Rect(50, 30, 180,180); } private void menuItem11_Click(object sender, System.EventArgs e) { createSquare(); } void createSquare() { //clear old figure if (current != null) current.Show(graphic, clearPen, clearBrush); //create square current = new Square(30, 180,180); } private void menuItem12_Click(object sender, System.EventArgs e) { createPerson(); } void createPerson() { //clear old figure if (current != null) current.Show(graphic, clearPen, clearBrush); //create person current = new Person(20, 180,180); } private void menuItem13_Click(object sender, System.EventArgs e) { showCurrent(); } void showCurrent() { //Show current current.Show(graphic, pen, brush); } private void menuItem14_Click(object sender, System.EventArgs e) { clearCurrent(); } void clearCurrent() { //Clear current current.Show(graphic, clearPen, clearBrush); } private void menuItem17_Click(object sender, System.EventArgs e) { incScale(); } void incScale() { //Increase scale current.Show(graphic, clearPen, clearBrush); current.Scale(1.5); current.Show(graphic, pen, brush); } private void menuItem18_Click(object sender, System.EventArgs e) { decScale(); } void decScale() { //Decrease scale current.Show(graphic, clearPen, clearBrush); current.Scale(2.0/3); current.Show(graphic, pen, brush); } private void menuItem19_Click(object sender, System.EventArgs e) { moveLeft(); } void moveLeft() { //Move left current.Show(graphic, clearPen, clearBrush); current.Move(-20,0); current.Show(graphic, pen, brush); } private void menuItem20_Click(object sender, System.EventArgs e) { moveRight(); } void moveRight() { //Move right current.Show(graphic, clearPen, clearBrush); current.Move(20,0); current.Show(graphic, pen, brush); } private void menuItem21_Click(object sender, System.EventArgs e) { moveTop(); } void moveTop() { //Move top current.Show(graphic, clearPen, clearBrush); current.Move(0,-20); current.Show(graphic, pen, brush); } private void menuItem22_Click(object sender, System.EventArgs e) { moveDown(); } void moveDown() { //Move down current.Show(graphic, clearPen, clearBrush); current.Move(0, 20); current.Show(graphic, pen, brush); } private void menuItem23_Click(object sender, System.EventArgs e) { //choose color ColorDialog dialog = new ColorDialog(); if (dialog.ShowDialog() ==DialogResult.OK) color =dialog.Color; pen = new Pen(color); brush = new SolidBrush(color); } private void menuItem24_Click(object sender, System.EventArgs e) { //Red color color =Color.Red; pen = new Pen(color); brush = new SolidBrush(color); } private void menuItem25_Click(object sender, System.EventArgs e) { //Green color color =Color.Green; pen = new Pen(color); brush = new SolidBrush(color); } private void menuItem26_Click(object sender, System.EventArgs e) { //Blue color color =Color.Blue; pen = new Pen(color); brush = new SolidBrush(color); } private void menuItem27_Click(object sender, System.EventArgs e) { //Black color color =Color.Black; pen = new Pen(color); brush = new SolidBrush(color); } private void menuItem28_Click(object sender, System.EventArgs e) { //Gold color color =Color.Gold; pen = new Pen(color); brush = new SolidBrush(color); } private void menuItem29_Click(object sender, System.EventArgs e) { //put_left: добавление фигуры в список listFigure.put_left(current); } private void menuItem30_Click(object sender, System.EventArgs e) { //put_right: добавление фигуры в список listFigure.put_right(current); } private void menuItem31_Click(object sender, System.EventArgs e) { //remove: удаление фигуры из списка if(!listFigure.empty()) listFigure.remove(); } private void menuItem32_Click(object sender, System.EventArgs e) { goPrev(); } void goPrev() { //go_prev: передвинуть курсор влево if(!(listFigure.Index == 1)) { listFigure.go_prev(); current = listFigure.item(); } } private void menuItem33_Click(object sender, System.EventArgs e) { goNext(); } void goNext() { //go_next: передвинуть курсор вправо if( !(listFigure.Index == listFigure.Count)) { listFigure.go_next(); current = listFigure.item(); } } private void menuItem34_Click(object sender, System.EventArgs e) { //go_first listFigure.start(); if(!listFigure.empty()) current = listFigure.item(); } private void menuItem35_Click(object sender, System.EventArgs e) { //go_last listFigure.finish(); if(!listFigure.empty()) current = listFigure.item(); } private void menuItem15_Click(object sender, System.EventArgs e) { showList(); } void showList() { //Show List listFigure.start(); while(listFigure.Index <= listFigure.Count) { current = listFigure.item(); current.Show(graphic,pen,brush); listFigure.go_next(); } listFigure.finish(); } private void menuItem16_Click(object sender, System.EventArgs e) { clearList(); } void clearList() { //Clear List listFigure.start(); while(!listFigure.empty()) { current = listFigure.item(); current.Show(graphic,clearPen,clearBrush); listFigure.remove(); } } private void Form1_MouseMove(object sender, System.Windows.Forms.MouseEventArgs e) { if((current != null) && current.dragged_figure) { current.Show(graphic,clearPen,clearBrush); Point pt = new Point(e.X, e.Y); current.center_figure = pt; current.Show(graphic,pen,brush); } } private void Form1_MouseUp(object sender, System.Windows.Forms.MouseEventArgs e) { current.dragged_figure = false; } private void Form1_MouseDown(object sender, System.Windows.Forms.MouseEventArgs e) { Point mousePoint = new Point (e.X, e.Y); Rectangle figureRect = current.Region_Capture(); if ((current != null) && (figureRect.Contains(mousePoint))) current.dragged_figure = true; } protected override void OnPaint(System.Windows.Forms.PaintEventArgs e) { //show current figure current.Show(graphic, pen, brush); } private void toolBar1_ButtonClick(object sender, System.Windows.Forms.ToolBarButtonClickEventArgs e) { int buttonNumber = toolBar1.Buttons.IndexOf(e.Button); switch (buttonNumber) { case 0: createEllipse(); break; case 1: createCircle(); break; case 2: createLittleCircle(); break; case 3: createRectangle(); break; case 4: createSquare(); break; case 5: createPerson(); break; case 6: showCurrent(); break; case 7: clearCurrent(); break; case 8: showList(); break; case 9: clearList(); break; case 10: incScale(); break; case 11: decScale(); break; case 12: moveLeft(); break; case 13: moveRight(); break; case 14: moveTop(); break; case 15: moveDown(); break; case 16: goNext(); break; case 17: goPrev(); break; } } } }

1.2. 23.04.2020 Лекция 24: Организация интерфейса и рисование в формах

1.2.1. Форма и элементы управления

1.2.1.1. Как населить форму элементами управления? Чаще всего, это делается вручную в режиме проектирования. Доступные элементы управления, отображаемые на специальной панели (Toolbox), перетаскиваются на форму. Этот процесс поддерживается особым инструментарием - дизайнером форм (Designer Form). Как только на этапе проектирования вы сажаете на форму элемент управления, немедленно в тексте класса появляются соответствующие строки кода (в лекции 2 об этом подробно рассказано). Конечно, все можно делать и программно - появление соответствующих строк кода приводит к появлению элементов управления на форме. Нужно понимать, что форма - это видимый образ класса Form, а элементы управления, размещенные на форме - это видимые образы клиентских объектов соответствующих классов, наследников класса Control. Так что форма с ее элементами управления есть прямое отражение программного кода.

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

1.2.1.2.1. Естественно, все эти классы являются потомками прародителя - класса Object. Заметьте, класс Control в иерархии классов занимает довольно высокое положение, хотя и у него есть два важных родительских класса - класс Component, определяющий возможность элементам управления быть компонентами, и класс MarshalByRefObject, задающий возможность передачи элементов управления по сети. Класс Control задает важные свойства, методы и события, наследуемые всеми его потомками. Все классы элементов управления являются наследниками класса Control. Чаще всего, это прямые наследники, но иногда они имеют и непосредственного родителя, которым может быть абстрактный класс - это верно для кнопок, списков, текстовых элементов управления. Может показаться удивительным, но класс Form является одним из потомков класса Control, так что форма - это элемент управления со специальными свойствами. Будучи наследником классов ScrollableControl и ContainerControl, форма допускает прокрутку и размещение элементов управления.

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

1.2.2.1. Следует четко различать процесс создания формы - соответствующего объекта, принадлежащего классу Form или наследнику этого класса, - и процесс показа формы на экране. Для показа формы служит метод Show этого класса, вызываемый соответствующим объектом; для скрытия формы используется метод Hide. Реально методы Show и Hide изменяют свойство Visible объекта, так что вместо вызова этих методов можно менять значение этого свойства, устанавливая его либо в true, либо в false.

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

1.2.3. Модальные и немодальные формы

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

1.2.3.2. Форма называется модальной или немодальной в зависимости от того, каково ее окно.

1.2.3.2.1. Метод Show открывает форму как немодальную, а метод ShowDialog - как модальную.

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

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

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

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

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

1.2.4.3.1. public Books myBooks;

1.2.4.4. В конструкторе главной формы такой объект создается:

1.2.4.4.1. myBooks = new Books(max_books);

1.2.4.5. При создании объекта form2 его конструктору передается ссылка на главную форму:

1.2.4.5.1. form2 = new NewBook(this);

1.2.5. Образцы форм

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

1.2.5.2. Главная кнопочная форма

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

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

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

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

1.2.7. Наследование форм

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

1.2.7.1.1. public class NewForm : InterfacesAndDrawing.TwoLists

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

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

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

1.2.9. Класс Graphics

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

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

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

1.2.10. Класс Pen

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

1.2.11. Класс Brush

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

1.2.11.1.1. SolidBrush - для сплошной закраски области заданным цветом;

1.2.11.1.2. TextureBrush - для закраски области заданной картинкой (image);

1.2.11.1.3. HatchBrush - для закраски области предопределенным узором;

1.2.11.1.4. LinearGradientBrush - для сплошной закраски с переходом от одного цвета к другому, где изменение оттенков задается линейным градиентом;

1.2.11.1.5. PathGradientBrush - для сплошной закраски с переходом от одного цвета к другому, где изменение оттенков задается более сложным путем.

1.3. 22.04.2020 Лекция 23: Отладка и обработка исключительных ситуаций

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

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

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

1.3.1.3. Устойчивость - это способность программной системы должным образом реагировать на исключительные ситуации.

1.3.1.4. Обработка исключительных ситуаций - процесс, направленный на достижение устойчивости.

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

1.3.2.1. Под " жизненным циклом " понимается период от замысла программного продукта до его "кончины". Обычно рассматриваются следующие фазы этого процесса:

1.3.2.1.1. Проектирование <-> Разработка <-> Развертывание и Сопровождение

1.3.3. Три закона программотехники

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

1.3.3.1.1. Корректность системы - недостижима. Каждая последняя найденная ошибка является предпоследней.

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

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

1.3.3.2.1. Не бывает некорректных систем. Каждая появляющаяся ошибка при эксплуатации системы - это следствие незнания спецификации системы.

1.3.3.2.2. Есть два объяснения справедливости второго закона. Несерьезное объяснение состоит в том, что любая система, что бы она ни делала, при любом постусловии корректна по отношению к предусловию False, поскольку невозможно подобрать ни один набор входных данных, удовлетворяющих этому предусловию. Так что все системы корректны, если задать False в качестве их предусловия. Если вам пришлось столкнуться с системой, предусловие которой близко к False, то лучшее, что можно сделать, это отложить ее в сторону и найти другую.

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

1.3.3.2.4. Обратите внимание на философию, характерную для этих законов: при возникновении ошибки разработчик и пользователь должны винить себя, а не кивать друг на друга. Так что часто встречающиеся фразы "Ох уж эта фирма Чейтософт - вечно у них ошибки!" характеризует, мягко говоря, непрофессионализм говорящего.

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

1.3.3.3.1. Если спецификацию можно нарушить, - она будет нарушена. Новичок (чечако) способен "подвесить" любую систему.

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

1.3.3.3.3. Отладка

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

1.3.4. Классы Debug и Trace

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

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

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

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

1.3.4.3.2. EventLogTraceListener - посылает сообщения в журнал событий Windows;

1.3.4.3.3. TextWriterTraceListener - направляет сообщения объектам класса TextWriter или Stream ; обычно один из объектов этого класса направляет вывод на консоль, другой - в файл.

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

1.3.5. Метод Флойда и утверждения Assert

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

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

1.3.5.3. Схема Флойда используется на практике, по крайней мере, программистами, имеющими вкус к строгим методам доказательства. Утверждения становятся частью программного текста. Само доказательство может и не проводиться: чаще всего у программиста есть уверенность в справедливости расставленных утверждений и убежденность, что при желании он мог бы провести и строгое доказательство. В C# эта схема поддерживается тем, что классы Debug и Trace имеют метод Assert, аргументом которого является утверждение. Что происходит, когда вычисление достигает соответствующей точки и вызывается метод Assert? Если истинно булево выражение в Assert, то вычисления продолжаются, не оказывая никакого влияния на нормальный ход вычислений. Если оно ложно, то корректность вычислений под сомнением, их выполнение приостанавливается и появляется окно с уведомлением о произошедшем событии

1.3.5.3.1. В этой ситуации у программиста есть несколько возможностей:

1.3.6. Классы StackTrace и BooleanSwitch

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

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

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

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

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

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

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

1.3.9. Обработка исключений в языках C/C++

1.3.9.1. Для стиля программирования на языке C характерно описание методов класса как булевых функций, возвращающих true в случае нормального завершения метода и false - при возникновении исключительной ситуации. Вызов метода встраивался в If -оператор, обрабатывающий ошибку в случае неуспеха завершения метода:

1.3.9.1.1. bool MyMethod(...){...} if !MyMethod(){// обработка ошибки} {//нормальное выполнение}

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

1.3.10.1. Язык C# наследовал схему исключений языка С++, внеся в нее свои коррективы. Рассмотрим схему подробнее и начнем с синтаксиса конструкции try-catch-finally:

1.3.10.1.1. try {...} catch (T1 e1) {...} ... catch(Tk ek) {...} finally {...}

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

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

1.3.11.1. В теле try-блока может возникнуть исключительная ситуация, приводящая к выбрасыванию исключений. Формально выбрасывание исключения происходит при выполнении оператора throw. Этот оператор, чаще всего, выполняется в недрах операционной системы, когда система команд или функция API не может сделать свою работу. Но этот оператор может быть частью программного текста try-блока и выполняться, когда в результате проведенного анализа становится понятным, что дальнейшая нормальная работа невозможна.

1.3.11.2. Синтаксически оператор throw имеет вид:

1.3.11.2.1. throw[выражение]

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

1.3.11.3.1. Блок catch - обработчик исключения имеет следующий синтаксис:

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

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

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

1.3.12.3. Блок finally

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

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

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

1.3.13. Класс Exception

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

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

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

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

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

1.4. 16.04.2020 Лекция 22: Универсальность. Классы с родовыми параметрами

1.4.1. Наследование и универсальность

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

1.4.1.1.1. public void Swap(ref T x1, ref T x2) { T temp; temp = x1; x1 = x2; x2 = temp; }

1.4.1.2. Если тип T - это вполне определенный тип, например int, string или Person, то никаких проблем не существует, все совершенно прозрачно. Но как быть, если возникает необходимость обмена данными разного типа? Неужели нужно писать копии этой процедуры для каждого типа? Проблема легко решается в языках, где нет контроля типов - там достаточно иметь единственный экземпляр такой процедуры, прекрасно работающий, но лишь до тех пор, пока передаются аргументы одного типа. Когда же процедуре будут переданы фактические аргументы разного типа, то немедленно возникнет ошибка периода выполнения, и это слишком дорогая плата за универсальность.

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

1.4.1.3.1. До недавнего времени Framework .Net и соответственно язык C# не поддерживали универсальность. Так что те, кто работает с языком C#, входящим в состав Visual Studio 2003 и ранних версий, должны смириться с отсутствием универсальных классов. Но в новой версии Visual Studio 2005, носящей кодовое имя Whidbey, проблема решена, и программисты получили наконец долгожданный механизм универсальности. Я использую в примерах этой лекции бета-версию Whidbey.

1.4.1.3.2. Замечу, что хотя меня прежде всего интересовала реализация универсальности, но и общее впечатление от Whidbey самое благоприятное.

1.4.1.3.3. Для достижения универсальности процедуры Swap следует рассматривать тип T как ее параметр, такой же, как и сами аргументы x1 и x2. Суть универсальности в том, чтобы в момент вызова процедуры передавать ей не только фактические аргументы, но и их фактический тип.

1.4.1.3.4. Под универсальностью (genericity) понимается способность класса объявлять используемые им типы как параметры. Класс с параметрами, задающими типы, называется универсальным классом (generic class). Терминология не устоялась и синонимами термина " универсальный класс " являются термины: родовой класс, параметризованный класс, класс с родовыми параметрами. В языке С++ универсальные классы называются шаблонами (template).

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

1.4.2.1. Объявить класс C# универсальным просто: для этого достаточно указать в объявлении класса, какие из используемых им типов являются параметрами. Список типовых параметров класса, заключенный в угловые скобки, добавляется к имени класса:

1.4.2.1.1. class MyClass<T1, ... Tn> {...}

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

1.4.2.3. В C# универсальными могут быть как классы, так и все их частные случаи - интерфейсы, структуры, делегаты, события.

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

1.4.3. Два основных механизма объектной технологии

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

1.4.3.2. Эти механизмы взаимно дополняют друг друга. Универсальность можно ограничить (об этом подробнее будет сказано ниже), указав, что тип, задаваемый родовым параметром, обязан быть наследником некоторого класса и/или ряда интерфейсов. С другой стороны, когда формальный тип T заменяется фактическим типом TFact, то там, где разрешено появляться объектам типа TFact, разрешены и объекты, принадлежащие классам-потомкам TFact.

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

1.4.3.3.1. Abstract class S <T1,...Tk >

1.4.3.3.2. {

1.4.3.3.3. T1 p1;...Tk pk;

1.4.3.3.4. public T1 M1 (T1 x,..Tk z);

1.4.3.3.5. void Mr (T1 x,..Tk z);

1.4.3.3.6. }

1.4.3.3.7. Этап проектирования: абстрактный класс с абстрактными типами

1.4.3.4. Наследование: уточняется представление данных; задается или уточняется реализация методов родителя

1.4.3.4.1. S <T1,...Tk >

1.4.3.4.2. Родовое порождение: уточняются типы данных; порождается класс путем подстановки конкретных типов

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

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

1.4.3.6.1. public class ArrayUpStack<T> : GenStack<T> { int SizeOfStack; T[] stack; int top; /// <summary> /// конструктор /// </summary> /// <param name="size">размер стека</param> public ArrayUpStack(int size) { SizeOfStack = size; stack = new T[SizeOfStack]; top = 0; } /// <summary> /// require: (top < SizeOfStack) /// </summary> /// <param name="x"> элемент, помещаемый в стек</param> public override void put(T x) { stack[top] = x; top++; } public override void remove() { top--; } public override T item() { return (stack[top-1]); } public override bool empty() { return (top == 0); } }//class ArrayUpStack

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

1.4.4. Ограниченная универсальность

1.4.4.1. Хорошо, когда есть свобода. Еще лучше, когда свобода ограничена. Аналогичная ситуация имеет место и с универсальностью. Универсальность следует ограничивать. На типы универсального класса, являющиеся его параметрами, следует накладывать ограничения. Звучит парадоксально, но, наложив ограничения на типы, программист получает гораздо большую свободу в работе с объектами этих типов.

1.4.4.1.1. Если немного подумать, то это совершенно естественная ситуация. Когда имеет место неограниченная универсальность, над объектами типов можно выполнять только те операции, которые допускают все типы, - в C# это эквивалентно операциям, разрешенным над объектами типа object, прародителя всех типов. В нашем предыдущем примере, где речь шла о свопинге, над объектами выполнялась единственная операция присваивания. Поскольку присваивание внутри одного типа разрешено для всех типов, то неограниченная универсальность приемлема в такой ситуации. Но что произойдет, если попытаться выполнить сложение элементов, сравнение их или даже простую проверку элементов на равенство? Немедленно возникнет ошибка еще на этапе компиляции. Эти операции не разрешены для всех типов, поэтому в случае компиляции такого проекта ошибка могла бы возникнуть на этапе выполнения, когда вместо формального типа появился бы тип конкретный, не допускающий подобную операцию. Нельзя ради универсальности пожертвовать одним из важнейших механизмов C# и Framework .Net - безопасностью типов, поддерживаемой статическим контролем типов. Именно поэтому неограниченная универсальность существенно ограничена. Ее ограничивает статический контроль типов. Бывают, разумеется, ситуации, когда необходимо на типы наложить ограничения, позволяющие ослабить границы статического контроля. На практике универсальность почти всегда ограничивается, что, повторяю, дает большую свободу программисту.

1.4.4.2. В языке C# допускаются три вида ограничений, накладываемых на родовые параметры.

1.4.4.2.1. Ограничение наследования. Это основной вид ограничений, указывающий, что тип T является наследником некоторого класса и ряда интерфейсов. Следовательно, над объектами типа T можно выполнять все операции, заданные базовым классом и интерфейсами. Эти операции статический контроль типов будет разрешать и обеспечивать для них интеллектуальную поддержку, показывая список разрешенных операций. Ограничение наследования позволяет выполнять над объектами больше операций, чем в случае неограниченной универсальности. Синтаксически ограничение выглядит так: where T: BaseClass, I1, ...Ik.

1.4.4.2.2. Ограничение конструктора. Это ограничение указывает, что тип T имеет конструктор без аргументов и, следовательно, позволяет создавать объекты типа T. Синтаксически ограничение выглядит так: where T: new().

1.4.4.2.3. Ограничение value/reference. Это ограничение указывает, к значимым или к ссылочным типам относится тип T. Для указания значимого типа задается слово struct, для ссылочных - class. Так что синтаксически этот тип ограничений выглядит так: where T: struct.

1.4.4.2.4. Возникает законный вопрос: насколько полна предлагаемая система ограничений? Конечно, речь идет о практической полноте, а не о математически строгих определениях. С позиций практики систему хотелось бы дополнить, в первую очередь, введением ограничений операций, указывающим допустимые знаки операций в выражениях над объектами соответствующего типа. Хотелось бы, например, указать, что к объектам типа T применима операция сложения + или операция сравнения <. Позже я покажу, как можно справиться с этой проблемой, но предлагаемое решение довольно сложно. Наличие ограничения операций намного элегантнее решало бы эту проблему.

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

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

1.4.5.1.1. public class Father<T1, T2> { } public class Base { public void M1() { } public void M2() { } } public class Child<T1,T2> :Father<T1,T2> where T1:Base,IEnumerable<T1>, new() where T2:struct,IComparable<T2> { }

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

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

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

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

1.4.7. Как справиться с арифметикой

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

1.4.7.2. Как уже говорилось, наличие ограничения операции, где можно было бы указать, что над элементами определена операция +, решало бы проблему. Но такого типа ограничений нет. Хуже того, нет и интерфейса INumeric, аналогичного IComparable, определяющего метод сложения Add. Так что нам не может помочь и ограничение наследования.

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

1.4.7.3.1. public abstract class Calc<T> { public abstract T Add(T a, T b); public abstract T Sub(T a, T b); public abstract T Mult(T a, T b); public abstract T Div(T a, T b); }

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

1.4.8.1. До сих пор рассматривалась ситуация родового порождения экземпляров универсального класса. Фактические типы задавались в момент создания экземпляра. Это наглядно показывает преимущества применяемой технологии, поскольку очевидно, что не создается дублирующий код для каждого класса, порожденного универсальным классом. И все-таки остается естественный вопрос: можно ли породить класс из универсального класса путем подстановки фактических параметров, а потом спокойно использовать этот класс обычным образом? Такая вещь возможна. Это можно сделать не совсем обычным путем - не в программном коде, а в предложении using, назначение которого и состоит в выполнении подобных подстановок.

1.4.8.2. Давайте вернемся к универсальному классу OneLinkStack<T>, введенному в начале этой лекции, и породим на его основе вполне конкретный класс IntStack, заменив формальный параметр T фактическим - int. Для этого достаточно задать следующее предложение using:

1.4.8.2.1. using IntStack = Generic.OneLinkStack<int>;

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

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

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

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

1.4.10.1.1. public struct Point<T> { T x, y;//координаты точки, тип которых задан параметром // другие свойства и методы структуры }

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

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

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

1.4.12.1. Делегаты также могут иметь родовые параметры. Чаще встречается ситуация, когда делегат объявляется в универсальном классе и использует в своем объявлении параметры универсального класса. Давайте рассмотрим ситуацию с делегатами более подробно. Вот объявление универсального класса, не очень удачно названного Delegate, в котором объявляется функциональный тип - delegate:

1.4.12.1.1. class Delegate<T> { public delegate T Del(T a, T b); }

1.4.13. Framework .Net и универсальность

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

1.4.13.2. Решение этих задач потребовало введения универсальности не только в язык C#, но и поддержки на уровне каркаса Framework .Net и языка IL, включающем теперь параметризованные типы. Универсальный класс C# не является шаблоном, на основе которого строится конкретизированный класс, компилируемый далее в класс (тип) IL. Компилятору языка C# нет необходимости создавать классы для каждой конкретизации типов универсального класса. Вместо этого происходит компиляция универсального класса C# в параметризованный тип IL. Когда же CLR занимается исполнением управляемого кода, то вся необходимая информация о конкретных типах извлекается из метаданных, сопровождающих объекты.

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

1.4.13.4. Естественно, что универсальность потребовала введения в библиотеку FCL соответствующих классов, интерфейсов, делегатов и методов классов, обладающих этим свойством.

1.4.13.5. Так, например, в класс System.Array добавлен ряд универсальных статических методов. Вот один из них:

1.4.13.6. public static int BinarySearch<T>(T[] array, T value);

1.4.13.7. В таблице 22.1 показаны некоторые универсальные классы и интерфейсы библиотеки FCL 2.0 из пространства имен System.Collections.Generic и их аналоги из пространства System.Collections.

1.4.14. Таблица 22.1. Соответствие между универсальными классами и их обычными двойниками

1.4.14.1. Универсальный класс Обычный класс Универсальный интерфейс Обычный интерфейс Comparer<T> Comparer ICollection<T> ICollection Dictionary<K,T> HashTable IComparable<T> IComparable LinkedList<T> ---- IDictionary<K,T> IDictionary List<T> ArrayList IEnumerable<T> IEnumerable Queue<T> Queue IEnumerator<T> IEnumerator SortedDictionary<K,T> SortedList IList<T> IList Stack<T> Stack

1.5. 15.04.2020 Лекция 21: События

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

1.5.1.1. Каждый объект является экземпляром некоторого класса.

1.5.1.2. Класс задает свойства и поведение своих экземпляров.

1.5.1.3. Методы класса определяют поведение объектов, свойства - их состояние.

1.5.1.4. Все объекты обладают одними и теми же методами и, следовательно, ведут себя одинаково.

1.5.1.5. Можно полагать, что методы задают врожденное поведение объектов. Этого нельзя сказать о свойствах - значения свойств объектов различны, так что экземпляры одного класса находятся в разных состояниях.

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

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

1.5.1.7.1. Класс, помимо свойств и методов, может иметь события.

1.5.2. Как зажигаются события

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

1.5.2.1.1. protected virtual void OnFire(int time, int build) { if (FireEvent!=null) FireEvent(this,time, build); }

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

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

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

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

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

1.5.3.3. Пример "Списки с событиями"

1.5.3.3.1. В этом примере строится класс ListWithChangedEvent, являющийся потомком встроенного класса ArrayList, который позволяет работать со списками. В класс добавляется событие Changed, сигнализирующее обо всех изменениях элементов списка. Строятся два класса - Receiver1 и Receiver2, получающие сообщения. В примере рассматривается взаимодействие нескольких объектов: два объекта посылают сообщения, три - принимают.

1.5.4. Класс sender

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

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

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

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

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

1.5.5. Классы receiver

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

1.5.5.1.1. 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

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

1.5.5.2.1. 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

1.5.6. Две проблемы с обработчиками событий

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

1.5.6.1.1. Игнорирование коллег

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

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

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

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

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

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

1.5.7.3.1. 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

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

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

1.5.7.5.1. 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

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

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

1.5.8.1.1. public class NewTown { //свойства private int build, BuildingNumber; //дом и число домов в городе private int day, days; //Текущий день года //городские службы private Police policeman ; private Ambulance ambulanceman ; private FireDetect fireman ; //события в городе public event FireEventHandler Fire; //моделирование случайных событий private Random rnd = new Random(); //вероятность пожара в доме в текущий день: p= m/n private int m = 3, n= 10000;

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

1.5.8.2.1. //конструктор класса public NewTown(int TownSize, int Days) { BuildingNumber = rnd.Next(TownSize); days = Days; policeman = new Police(this); ambulanceman= new Ambulance(this); fireman= new FireDetect(this); policeman.On(); ambulanceman.On(); fireman.On(); }

1.5.8.3. При создании объектов этого класса задается размер города - число его домов и период времени, в течение которого будет моделироваться жизнь города. При создании объекта создаются его службы - объекты соответствующих классов Police, Ambulance, FireDetect, которым передается ссылка на сам объект "город". При создании служб вызываются методы On, подключающие обработчики события Fire каждой из этих служб к событию.

1.5.8.3.1. В соответствии с ранее описанной технологией определим метод OnFire, включающий событие:

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

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

1.6. 14.04.2020 Лекция 20: Функциональный тип в C#. Делегаты

1.6.1. Как определяется функциональный тип и как появляются его экземпляры

1.6.1.1. Слово делегат (delegate) используется в C# для обозначения хорошо известного понятия. Делегат задает определение функционального типа (класса) данных

1.6.1.2. Экземплярами класса являются функции.

1.6.1.3. Описание делегата в языке C# представляет собой описание еще одного частного случая класса.

1.6.1.4. Каждый делегат описывает множество функций с заданной сигнатурой.

1.6.1.5. Каждая функция (метод), сигнатура которого совпадает с сигнатурой делегата, может рассматриваться как экземпляр класса, заданного делегатом.

1.6.1.5.1. Синтаксис объявления делегата имеет следующий вид:

1.6.2. Функции высших порядков

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

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

1.6.2.2.1. Программный код:

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

1.6.3.1. Метод "раскрутки" является одним из основных методов функционально-ориентированного построения сложных программных систем. Суть его состоит в том, что программная система создается слоями. Вначале пишется ядро системы - нулевой слой, реализующий базовый набор функций. Затем пишется первый слой с новыми функциями, которые интенсивно вызывают в процессе своей работы функции ядра. Теперь система обладает большим набором функций. Каждый новый слой расширяет функциональность системы. Процесс продолжается, пока не будет достигнута заданная функциональность. На рис.20.3, изображающем схему построения системы методом раскрутки, стрелками показано, как функции внешних слоев вызывают функции внутренних слоев.

1.6.4. Наследование и полиморфизм - альтернатива обратному вызову

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

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

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

1.6.4.3.1. class FIntegral { //базовый класс, в котором определен метод вычисления //интеграла и виртуальный метод, задающий базовую //подынтегральную функцию public double EvaluateIntegral(double a, double b, double eps) { int n=4; double I0=0, I1 = I( a, b, n); for( n=8; n < Math.Pow(2.0,15.0); n*=2) { I0 =I1; I1=I(a,b,n); if(Math.Abs(I1-I0)<eps)break; } if(Math.Abs(I1-I0)< eps) Console.WriteLine("Требуемая точность достигнута! "+ " eps = {0}, достигнутая точность ={1}, n= {2}", eps,Math.Abs(I1-I0),n); else Console.WriteLine("Требуемая точность не достигнута! "+ " eps = {0}, достигнутая точность ={1}, n= {2}", eps,Math.Abs(I1-I0),n); return(I1); } private double I(double a, double b, int n) { //Вычисляет частную сумму по методу трапеций double x = a, sum = sif(x)/2, dx = (b-a)/n; for (int i= 2; i <= n; i++) { x += dx; sum += sif(x); } x = b; sum += sif(x)/2; return(sum*dx); } protected virtual double sif(double x) {return(1.0);} }//FIntegral

1.6.5. Делегаты как свойства

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

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

1.6.6. Операции над делегатами. Класс Delegate

1.6.6.1. Давайте просуммируем то, что уже известно о функциональном типе данных. Ключевое слово delegate позволяет задать определение функционального типа (класса), фиксирующее контракт, которому должны удовлетворять все функции, принадлежащие классу. Функциональный класс можно рассматривать как ссылочный тип, экземпляры которого являются ссылками на функции. Заметьте, ссылки на функции - это безопасные по типу указатели, которые ссылаются на функции с жестко фиксированной сигнатурой, заданной делегатом. Следует также понимать, что это не простая ссылка на функцию. В том случае, когда экземпляр делегата инициирован динамическим методом, то экземпляр хранит ссылку на метод и на объект X, вызвавший этот метод.

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

1.6.6.2.1. Delegate FType = new Delegate(<определение типа>)

1.6.6.3. Операции "+" и "-"

1.6.6.3.1. Наряду с методами, над делегатами определены и две операции: "+" и "-", которые являются более простой формой записи добавления делегатов в список вызовов и удаления из списка. Операции заменяют собой методы Combine и Remove. Выше написанные присваивания объекту del1 с помощью этих операций могут быть переписаны в виде:

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

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

1.6.6.4.2. Начнем с построения класса с именем Combination, где, следуя уже описанной технологии, введем делегатов как закрытые свойства, доступ к которым идет через процедуру-свойство get. Три делегата одного класса будут описывать действия трех городских служб. Класс будет описываться ранее введенным делегатом MesToPers, размещенным в пространстве имен проекта. Вот программный код, в котором описаны функции, задающие действия служб:

1.7. 11.04.2020 Лекция 19: Интерфейсы. Множественное наследование

1.7.1. Интерфейсы

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

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

1.7.1.3. Подробнее о развернутых и ссылочных типах см. лекцию 17.

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

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

1.7.1.6. Две стратегии реализации интерфейса

1.7.2. Две стратегии реализации интерфейса

1.7.2.1. Давайте опишем некоторый интерфейс, задающий дополнительные свойства объектов класса:

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

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

1.7.3.1. Создать объект класса интерфейса обычным путем с использованием конструктора и операции new нельзя. Тем не менее, можно объявить объект интерфейсного класса и связать его с настоящим объектом путем приведения ( кастинга ) объекта наследника к классу интерфейса. Это преобразование задается явно. Имея объект, можно вызывать методы интерфейса - даже если они закрыты в классе, для интерфейсных объектов они являются открытыми. Приведу соответствующий пример, в котором идет работа как с объектами классов Clain, ClainP, так и с объектами интерфейсного класса IProps:

1.7.3.1.1. public void TestClainIProps() { Console.WriteLine("Объект класса Clain вызывает открытые методы!"); Clain clain = new Clain(); clain.Prop1(" свойство 1 объекта"); clain.Prop2("Владимир", 44); Console.WriteLine("Объект класса IProps вызывает открытые методы!"); IProps ip = (IProps)clain; ip.Prop1("интерфейс: свойство"); ip.Prop2 ("интерфейс: свойство",77); Console.WriteLine("Объект класса ClainP вызывает открытые методы!"); ClainP clainp = new ClainP(); clainp.MyProp1(" свойство 1 объекта"); clainp.MyProp2("Владимир", 44); Console.WriteLine("Объект класса IProps вызывает закрытые методы!"); IProps ipp = (IProps)clainp; ipp.Prop1("интерфейс: свойство"); ipp.Prop2 ("интерфейс: свойство",77); }

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

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

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

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

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

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

1.7.4.1.5. public interface IProps

1.7.4.1.6. {

1.7.4.1.7. void Prop1(string s);

1.7.4.1.8. void Prop2 (string name, int val);

1.7.4.1.9. void Prop3();

1.7.4.1.10. }

1.7.4.1.11. public interface IPropsOne

1.7.4.1.12. {

1.7.4.1.13. void Prop1(string s);

1.7.4.1.14. void Prop2 (int val);

1.7.4.1.15. void Prop3();

1.7.4.1.16. }

1.7.4.2. Наследование от общего предка

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

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

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

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

1.7.5.1. Часто, когда создается класс, желательно задать отношение порядка на его объектах. Такой класс следует объявить наследником интерфейса IComparable. Этот интерфейс имеет всего один метод CompareTo (object obj), возвращающий целочисленное значение, положительное, отрицательное или равное нулю, в зависимости от выполнения отношения "больше", "меньше" или "равно".

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

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

1.7.5.3.1. public class Person:IComparable { public int CompareTo( object pers) { const string s = "Сравниваемый объект не принадлежит классу Person"; Person p = pers as Person; if (!p.Equals(null)) return (fam.CompareTo(p.fam)); throw new ArgumentException (s); } // другие компоненты класса }

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

1.7.6.1. Клонированием называется процесс создания копии объекта, а копия объекта называется его клоном.

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

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

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

1.7.7.1. При работе с программной системой зачастую возникает необходимость в сериализации объектов. Под сериализацией понимают процесс сохранения объектов в долговременной памяти (файлах) в период выполнения системы. Под десериализацией понимают обратный процесс - восстановление состояния объектов, хранимых в долговременной памяти. Механизмы сериализации C# и Framework .Net поддерживают два формата сохранения данных - в бинарном файле и XML-файле. В первом случае данные при сериализации преобразуются в бинарный поток символов, который при десериализации автоматически преобразуется в нужное состояние объектов. Другой возможный преобразователь (SOAP formatter) запоминает состояние объекта в формате xml.

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

1.7.7.3. Еще одно важное применение сериализации - это обмен данными удаленных систем. При удаленном обмене данными предпочтительнее формат xml из-за открытого стандарта передачи данных в Интернете по soap-протоколу, из-за открытого стандарта на структуру xml-документов. Обмен становится достаточно простым даже для систем, построенных на разных платформах и в разных средах разработки.

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

1.7.7.5. Если класс объявить с атрибутом [Serializable], то в него встраивается стандартный механизм сериализации, поддерживающий, что крайне приятно, глубокую сериализацию. Если по каким-либо причинам стандартная сериализация нас не устраивает, то класс следует объявить наследником интерфейса ISerializable, реализация методов которого позволит управлять процессом сериализации. Мы рассмотрим обе эти возможности.

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

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

1.7.8. Интерфейс ISerializable

1.7.8.1. При необходимости можно самому управлять процессом сериализации. В этом случае наш класс должен быть наследником интерфейса ISerializable. Класс, наследующий этот интерфейс, должен реализовать единственный метод этого интерфейса GetObjectData и добавить защищенный конструктор. Схема сериализации и десериализации остается и в этом случае той же самой. Можно использовать как бинарный форматер, так и soap-форматер. Но теперь метод Serialize использует не стандартную реализацию, а вызывает метод GetObjectData, управляющий записью данных. Метод Deserialize, в свою очередь, вызывает защищенный конструктор, создающий объект и заполняющий его поля сохраненными значениями.

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

1.7.8.3. Рассмотрим, как устроен метод GetObjectData, управляющий сохранением данных. У этого метода два аргумента:

1.7.8.4. GetObjectData(SerializedInfo info, StreamingContext context)

1.7.8.5. Поскольку самому вызывать этот метод не приходится - он вызывается автоматически методом Serialize, то можно не особенно задумываться о том, как создавать аргументы метода. Более важно понимать, как их следует использовать. Чаще всего используется только аргумент info и его метод AddValue (key, field). Данные сохраняются вместе с ключом, используемым позже при чтении данных. Аргумент key, который может быть произвольной строкой, задает ключ, а аргумент field - поле объекта. Например, для сохранения полей name и age можно задать следующие операторы:

1.7.8.6. info.AddValue("name",name); info.AddValue("age", age);

1.7.8.7. Поскольку имена полей уникальны, то их разумно использовать в качестве ключей.

1.7.8.8. Если поле son класса Father является объектом класса Child и этот класс сериализуем, то для сохранения объекта son следует вызвать метод:

1.7.8.9. son.GetObjectData(info, context)

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

1.7.8.11. Перейдем теперь к рассмотрению специального конструктора класса. Он может быть объявлен с атрибутом доступа private, но лучше, как и во многих других случаях, применять атрибут protected, что позволит использовать этот конструктор потомками класса, осуществляющими собственную сериализацию. У конструктора те же аргументы, что и у метода GetObjectData. Опять-таки, в основном используется аргумент info и его метод GetValue(key, type), который выполняет операцию, обратную к операции метода AddValue. По ключу key находится хранимое значение, а аргумент type позволяет привести его к нужному типу. У метода GetValue имеется множество типизированных версий, позволяющих не задавать тип. Так что восстановление полей name и age можно выполнить следующими операторами:

1.7.8.12. name = info.GetString("name"); age = info.GetInt32("age");

1.7.8.13. Восстановление поля son, являющегося ссылочным типом, выполняется вызовом его специального конструктора:

1.7.8.14. son = new Child(info, context);

1.7.8.15. А теперь вернемся к нашему примеру со стариком, старухой и золотой рыбкой. Заменим стандартную сериализацию собственной. Для этого, оставив атрибут сериализации у класса Personage, сделаем класс наследником интерфейса ISerializable:

1.7.8.16. [Serializable]

1.7.8.17. public class Personage :ISerializable

1.7.8.18. {...}

1.7.8.19. Добавим в наш класс специальный метод, вызываемый при сериализации - метод сохранения данных:

1.7.8.20. //Специальный метод сериализации

1.7.8.21. public void GetObjectData(SerializationInfo info,

1.7.8.22. StreamingContext context)

1.7.8.23. {

1.7.8.24. info.AddValue("name",name); info.AddValue("age", age);

1.7.8.25. info.AddValue("status",status);

1.7.8.26. info.AddValue("wealth", wealth);

1.7.8.27. info.AddValue("couplename",couple.name);

1.7.8.28. info.AddValue("coupleage", couple.age);

1.7.8.29. info.AddValue("couplestatus",couple.status);

1.7.8.30. info.AddValue("couplewealth", couple.wealth);

1.7.8.31. }

1.7.8.32. В трех первых строках сохраняются значимые поля объекта и тут все ясно. Но вот запомнить поле, хранящее объект couple класса Personage, напрямую не удается. Попытка рекурсивного вызова

1.7.8.33. couple.GetObjectData(info,context);

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

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

1.7.8.36. //Специальный конструктор сериализации

1.7.8.37. protected Personage(SerializationInfo info,

1.7.8.38. StreamingContext context)

1.7.8.39. {

1.7.8.40. name = info.GetString("name"); age = info.GetInt32("age");

1.7.8.41. status = info.GetString("status");

1.7.8.42. wealth = info.GetString("wealth");

1.7.8.43. couple = new Personage(info.GetString("couplename"),

1.7.8.44. info.GetInt32("coupleage"));

1.7.8.45. couple.status = info.GetString("couplestatus");

1.7.8.46. couple.wealth = info.GetString("couplewealth");

1.7.8.47. this.couple = couple; couple.couple = this;

1.7.8.48. }

1.7.8.49. Опять первые строки восстановления значимых полей объекта прозрачно ясны. А с полем couple приходится повозиться. Вначале создается новый объект обычным конструктором, аргументы которого читаются из сохраняемой памяти. Затем восстанавливаются значения других полей этого объекта, а затем уже происходит взаимное связывание двух объектов.

1.7.8.50. Кроме введения конструктора класса и метода GetObjectData, никаких других изменений в проекте не понадобилось - ни в методах класса, ни на стороне клиента. Внешне проект работал совершенно идентично ситуации, когда не вводилось наследование интерфейса сериализации. Но с внутренних позиций изменения произошли: методы форматеров Serialize и Deserialize в процессе своей работы теперь вызывали созданный нами метод и конструктор класса. Небольшие изменения произошли и в файлах, хранящих данные.

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

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

1.7.9. Таблица 19.1. Размеры файлов при различных случаях сериализации

1.7.9.1. Формат Сериализация Размер файла

1.7.9.2. Бинарный поток Стандартная 355 байтов

1.7.9.3. Бинарный поток Управляемая 355 байтов

1.7.9.4. XML-документ Стандартная 1, 14 Кб.

1.7.9.5. XML-документ Управляемая 974 байта

1.8. 10.04.2020 Лекция 18: Отношения между классами. Клиенты и наследники

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

1.8.1.1. Каждый класс, как не раз отмечалось, играет две роли:

1.8.1.1.1. он является модулем - архитектурной единицей,

1.8.1.1.2. он имеет содержательный смысл, определяя некоторый тип данных.

1.8.1.2. Определение 1. Классы А и В находятся в отношении " клиент-поставщик ", если одним из полей класса В является объект класса А. Класс А называется поставщиком класса В, класс В называется клиентом класса А.

1.8.1.3. Определение 2. Классы А и В находятся в отношении " родитель - наследник ", если при объявлении класса В класс А указан в качестве родительского класса. Класс А называется родителем класса В, класс В называется наследником класса А.

1.8.1.4. Оба отношения - наследования и вложенности - являются транзитивными. Если В - клиент А, а С - клиент В, то отсюда следует, что С - клиент А. Если В - наследник А, а С - наследник В, то отсюда следует, что С - наследник А.

1.8.1.5. Определения 1 и 2 задают прямых или непосредственных клиентов и поставщиков, прямых родителей и наследников. Вследствие транзитивности необходимо ввести понятие уровня. Прямые клиенты и поставщики, прямые родители и наследники относятся к соответствующему уровню 1 (клиенты уровня 1, поставщики уровня 1 и так далее). Затем следует рекурсивное определение: прямой клиент клиента уровня k относится к уровню k+1.

1.8.1.6. Для отношения наследования используется терминология, заимствованная из естественного языка. Прямые классы-наследники часто называются сыновними или дочерними классами. Непрямые родители называются предками, а их непрямые наследники - потомками.

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

1.8.2.1. При проектировании классов часто возникает вопрос, какое же отношение между классами нужно построить. Рассмотрим совсем простой пример двух классов - Square и Rectangle, описывающих квадраты и прямоугольники. Наверное, понятно, что эти классы следует связать скорее отношением наследования, чем вложенности ; менее понятным остается вопрос, а какой из этих двух классов следует сделать родительским. Еще один пример двух классов - Car и Person, описывающих автомобиль и персону. Какими отношениями с этими классами должен быть связан класс Person_of_Car, описывающий владельца машины? Может ли он быть наследником обоих классов? Найти правильные ответы на эти вопросы проектирования классов помогает понимание того, что отношение " клиент-поставщик " задает отношение "имеет" ("has"), а отношение наследования задает отношение "является" ("is a"). В случае классов Square и Rectangle понятно, что каждый объект квадрат "является" прямоугольником, поэтому между этими классами имеет место отношение наследования, и родительским классом является класс Rectangle, а класс Square является его потомком.

1.8.2.2. В случае автомобилей, персон и владельцев авто также понятно, что владелец "имеет" автомобиль и "является" персоной. Поэтому класс Person_of_Car является клиентом класса Car и наследником класса Person.

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

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

1.8.3.1.1. public class ClassA { public ClassA(string f1, int f2) { fieldA1 = f1; fieldA2 = f2; } public string fieldA1; public int fieldA2; public void MethodA() { Console.WriteLine( "Это класс A"); Console.WriteLine ("поле1 = {0}, поле2 = {1}", fieldA1, fieldA2); } public static void StatMethodA() { string s1 = "Статический метод класса А"; string s2 = "Помните: 2*2 = 4"; Console.WriteLine(s1 + " ***** " + s2); } }

1.8.3.1.2. Построим теперь класс B - клиента класса A. Класс будет устроен похожим образом, но в дополнение будет иметь одним из своих полей объект inner класса A:

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

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

1.8.4.1.1. public void MethodB2() { ClassA loc = new ClassA("локальный объект А",77); loc.MethodA(); } public void MethodB3() { ClassA.StatMethodA(); }

1.8.4.2. Дадим теперь расширенное определение клиента.

1.8.4.2.1. Определение 3. Класс B называется клиентом класса A, если в классе B создаются объекты класса A - поля или локальные переменные - или вызываются статические поля или методы класса A.

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

1.8.5.1. Что могут делать клиенты и что могут делать поставщики? Класс-поставщик создает свойства (поля) и сервисы (методы), предоставляемые своим клиентам. Клиенты создают объекты поставщика. Вызывая доступные им методы и поля объектов, они управляют работой созданных объектов поставщика. Клиенты не могут ни повлиять на поведение методов поставщика, ни изменить состав предоставляемых им полей и методов, они не могут вызывать закрытые поставщиком поля и методы класса.

1.8.5.2. Класс-поставщик интересен клиентам своей открытой частью, составляющей интерфейс класса. Но большая часть класса может быть закрыта для клиентов - им незачем вникать в детали представления и в детали реализации. Сокрытие информации вовсе не означает, что разработчики класса не должны быть знакомы с тем, как все реализовано, хотя иногда и такая цель преследуется. В общем случае сокрытие означает, что классы-клиенты строят свою реализацию, основываясь только на интерфейсной части класса-поставщика. Поставщик закрывает поля и часть методов класса от клиентов, задавая для них атрибут доступа private или protected. Он может некоторые классы считать привилегированными, предоставляя им методы и поля, недоступные другим классам. В этом случае поля и методы, предназначенные для таких vip-персон, снабжаются атрибутом доступа internal, а классы с привилегиями должны принадлежать одной сборке.

1.8.5.3. В заключение построим тест, проверяющий работу с объектами классов A и B:

1.8.5.3.1. public void TestClientSupplier() { ClassB objB = new ClassB("AA",22, "BB",33); objB.MethodB1(); objB.MethodB2(); objB.MethodB3(); }

1.8.6. Наследование

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

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

1.8.6.3. Рассмотрим класс, названный Found, играющий роль родительского класса. У него есть обычные поля, конструкторы и методы, один из которых снабжен новым модификатором virtual, ранее не появлявшимся в классах, другой - модификатором override:

1.8.6.3.1. public class Found { //поля protected string name; protected int credit; public Found() { } public Found(string name, int sum) { this.name = name; credit = sum; } public virtual void VirtMethod() { Console.WriteLine ("Отец: " + this.ToString() ); } public override string ToString() { return(String.Format("поля: name = {0}, credit = {1}", name, credit)); } public void NonVirtMethod() { Console.WriteLine ("Мать: " + this.ToString() ); } public void Analysis() { Console.WriteLine ("Простой анализ"); } public void Work() { VirtMethod(); NonVirtMethod(); Analysis(); } }

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

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

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

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

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

1.8.8. Добавление методов и изменение методов родителя

1.8.8.1. Потомок может создать новый собственный метод с именем, отличным от имен наследуемых методов. В этом случае никаких особенностей нет. Вот пример такого метода, создаваемого в классе Derived:

1.8.8.1.1. public void DerivedMethod() { Console.WriteLine("Это метод класса Derived"); }

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

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

1.8.9.1.1. x1.M(arg1, arg2, ... argN)

1.8.9.2. Контролем типов называется проверка каждого вызова, удостоверяющая, что:

1.8.9.2.1. в классе A1 объекта x1 действительно имеется метод M ;

1.8.9.2.2. список фактических аргументов в точке вызова соответствует по числу и типам списку формальных аргументов метода M, заданного в классе A1.

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

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

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

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

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

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

1.8.10.1.2. переопределение потомком метода, наследованного от родителя. Благодаря переопределению, в семействе классов существует совокупность полиморфных методов с одним именем и сигнатурой;

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

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

1.8.11.1. Классы семейства с полиморфными методами уже созданы. Давайте теперь в клиентском классе Testing напишем метод, создающий объекты наших классов и вызывающий методы классов для объектов семейства:

1.8.11.1.1. public void TestFoundDerivedReal() { Found bs = new Found ("father", 777); Console.WriteLine("Объект bs вызывает методы класса Found"); bs.VirtMethod(); bs.NonVirtMethod(); bs.Analysis(); bs.Work(); Derived der = new Derived("child", 888, 555); Console.WriteLine("Объект der вызывает методы класса Derived"); der.DerivedMethod(); der.VirtMethod(); der.NonVirtMethod(); der.Analysis(); der.Work(); ChildDerived chider = new ChildDerived("grandchild", 999, 444); Console.WriteLine("Объект chider вызывает методы ChildDerived"); chider.VirtMethod(); chider.NonVirtMethod(); chider.Analysis(5); chider.Work(); }

1.8.11.2. Абстрактные классы

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

1.9. 09.04.2020 Лекция 17: Структуры и перечисления

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

1.9.1.1. Рассмотрим объявление объекта класса T с инициализацией:

1.9.1.1.1. T x = new T();

1.9.1.2. Определение 1. Класс T относится к развернутому типу, если память отводится сущности x ; объект разворачивается на памяти, жестко связанной с сущностью.

1.9.1.3. Определение 2. Класс T относится к ссылочному типу, если память отводится объекту; сущность x является ссылкой на объект.

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

1.9.1.5. Развернутые и ссылочные типы порождают две различные семантики присваивания - развернутое присваивание и ссылочное присваивание. Рассмотрим присваивание:

1.9.1.5.1. y = x;

1.9.1.5.2. Когда сущность y и выражение x принадлежат развернутому типу, то при присваивании изменяется объект. Значения полей объекта, связанного с сущностью y, изменяются, получая значения полей объекта, связанного с x. Когда сущность y и выражение x принадлежат ссылочному типу, то изменяется ссылка, но не объект. Ссылка y получает значение ссылки x, и обе они после присваивания указывают на один и тот же объект.

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

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

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

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

1.9.2.2.1. если необходимо отнести класс к развернутому типу, делайте его структурой ;

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

1.9.2.2.3. в остальных случаях проектируйте настоящие классы.

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

1.9.3.1. Синтаксис объявления структуры аналогичен синтаксису объявления класса:

1.9.3.1.1. [атрибуты][модификаторы]struct имя_структуры[:список_интерфейсов] {тело_структуры}

1.9.3.1.2. Какие изменения произошли в синтаксисе в сравнении с синтаксисом класса, описанным в лекции 16? Их немного. Перечислим их:

1.9.3.2. Перечислим ограничения, накладываемые на структуры.

1.9.3.2.1. Самое серьезное ограничение связано с ограничением наследования. У структуры не может быть наследников. У структуры не может быть задан родительский класс или родительская структура. Конечно, всякая структура, как и любой класс в C#, является наследником класса Object, наследуя все свойства и методы этого класса. Структура может быть наследником одного или нескольких интерфейсов, реализуя методы этих интерфейсов.

1.9.3.2.2. Второе серьезное ограничение связано с процессом создания объектов. Пусть T - структура, и дано объявление без инициализации - T x. Это объявление корректно, в результате будет создан объект без явного вызова операции new. Сущности x будет отведена память, и на этой памяти будет развернут объект. Но поля объекта не будут инициализированы и, следовательно, не будут доступны для использования в вычислениях. Об этих особенностях подробно говорилось при рассмотрении значимых типов. В этом отношении все, что верно для типа int, верно и для всех структур.

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

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

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

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

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

1.9.4.1.1. 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; } }//Конструктор //поля и методы класса }

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

1.9.4.2.1. 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"); }

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

1.9.5.1. Как уже говорилось, все значимые типы языка реализованы структурами. В библиотеке FCL имеются и другие встроенные структуры. Рассмотрим в качестве примера структуры Point, PointF, Size, SizeF и Rectangle, находящиеся в пространстве имен System.Drawing и активно используемые при работе с графическими объектами. Первые четыре структуры имеют два открытых поля X и Y ( Height и Width ), задающие для точек - структур Point и PointF - координаты, целочисленные или в форме с плавающей точкой. Для размеров - структур Size и SizeF - они задают высоту и ширину, целочисленными значениями или в форме с плавающей точкой. Структуры Point и Size позволяют задать прямоугольную область - структуру Rectangle. Конструктору прямоугольника можно передать в качестве аргументов две структуры - точку, задающую координаты левого верхнего угла прямоугольника, и размер - высоту и ширину прямоугольника.

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

1.9.5.2.1. public void TestPointAndSize() { Point pt1 = new Point(3,5), pt2 = new Point(7,10), pt3; PointF pt4 = new PointF(4.55f,6.75f); Size sz1 = new Size(10,20), sz2; SizeF sz3 = new SizeF(10.3f, 20.7f); pt3 = Point.Round(pt4); sz2 = new Size(pt1); Console.WriteLine ("pt1: " + pt1); Console.WriteLine ("sz2 =new Size(pt1): " + sz2); Console.WriteLine ("pt4: " + pt4); Console.WriteLine ("pt3 =Point.Round(pt4): " + pt3); pt1.Offset(5,7); Console.WriteLine ("pt1.Offset(5,7): " + pt1); Console.WriteLine ("pt2: " + pt2); pt2 = pt2+ sz2; Console.WriteLine ("pt2= pt2+ sz2: " + pt2); }//TestPointAndSize

1.10. 08.04.2020 Лекция 16: Классы

1.10.1. Классы и ООП

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

1.10.2. Две роли классов

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

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

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

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

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

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

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

1.10.3.1.1. [атрибуты][модификаторы]class имя_класса[:список_родителей] {тело_класса}

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

1.10.3.2.1. public class Rational {тело_класса}

1.10.4. Методы класса

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

1.10.5. Доступ к методам

1.10.5.1. Каждый метод имеет модификатор доступа, принимающий одно из четырех значений: public, private, protected, internal. Атрибутом доступа по умолчанию является атрибут private. Независимо от значения атрибута доступа, все методы доступны для вызова при выполнении метода класса. Если методы имеют атрибут доступа private, возможно, опущенный, то тогда они доступны только для вызова и только внутри методов самого класса. Такие методы считаются закрытыми. Понятно, что класс, у которого все методы закрыты, абсурден, поскольку никто не смог бы вызвать ни один из его методов. Как правило, у класса есть открытые методы, задающие интерфейс класса, и закрытые методы. Интерфейс - это лицо класса и именно он определяет, чем класс интересен своим клиентам, что он может делать, какие сервисы предоставляет клиентам. Закрытые методы составляют важную часть класса, позволяя клиентам не вникать во многие детали реализации. Эти методы клиентам класса недоступны, они о них могут ничего не знать, и, самое главное, изменения в закрытых методах никак не отражаются на клиентах класса при условии корректной работы открытых методов.

1.10.5.2. Если некоторые методы класса A должны быть доступны для вызовов в методах класса B, являющегося потомком класса A, то такие методы следует снабдить атрибутом protected. Если некоторые методы должны быть доступны только для методов классов B1, B2 и так далее, дружественных по отношению к классу A, то такие методы следует снабдить атрибутом internal, а все дружественные классы B поместить в один проект. Наконец, если некоторые методы должны быть доступны для методов любого класса B, которому доступен сам класс A, то такие методы снабжаются модификатором public.

1.10.6. Методы-свойства

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

1.10.6.1.1. чтение, запись ( Read, Write );

1.10.6.1.2. чтение, запись при первом обращении ( Read, Write-once );

1.10.6.1.3. только чтение ( Read-only );

1.10.6.1.4. только запись ( Write-only );

1.10.6.1.5. ни чтения, ни записи ( Not Read, Not Write ).

1.10.6.2. Открытость свойств (атрибут public ) позволяет реализовать только первую стратегию. В языке C# принято, как и в других объектных языках, свойства объявлять закрытыми, а нужную стратегию доступа организовывать через методы. Для эффективности этого процесса и введены специальные методы-свойства.

1.10.6.3. Приведу вначале пример, а потом уточню синтаксис этих методов. Рассмотрим класс Person, у которого пять полей: fam, status, salary, age, health, характеризующих соответственно фамилию, статус, зарплату, возраст и здоровье персоны. Для каждого из этих полей может быть разумной своя стратегия доступа. Возраст доступен для чтения и записи, фамилию можно задать только один раз, статус можно только читать, зарплата недоступна для чтения, а здоровье закрыто для доступа и только специальные методы класса могут сообщать некоторую информацию о здоровье персоны. Вот как на C# можно обеспечить эти стратегии доступа к закрытым полям класса:

1.10.6.3.1. public class Person { //поля (все закрыты) string fam="", status="", health=""; int age=0, salary=0; //методы - свойства /// <summary> ///стратегия: Read,Write-once (Чтение, запись при ///первом обращении) /// </summary> public string Fam { set {if (fam == "") fam = value;} get {return(fam);} } /// <summary> ///стратегия: Read-only(Только чтение) /// </summary> public string Status { get {return(status);} } /// <summary> ///стратегия: Read,Write (Чтение, запись) /// </summary> public int Age { set { age = value; if(age < 7)status ="ребенок"; else if(age <17)status ="школьник"; else if (age < 22)status = "студент"; else status = "служащий"; } get {return(age);} } /// <summary> ///стратегия: Write-only (Только запись) /// </summary> public int Salary { set {salary = value;} } }

1.10.7. Индексаторы

1.10.7.1. Свойства являются частным случаем метода класса с особым синтаксисом. Еще одним частным случаем является индексатор. Метод-индексатор является обобщением метода-свойства. Он обеспечивает доступ к закрытому полю, представляющему массив. Объекты класса индексируются по этому полю.

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

1.10.7.3. Добавим в класс Person свойство children, задающее детей персоны, сделаем это свойство закрытым, а доступ к нему обеспечит индексатор:

1.10.7.3.1. const int Child_Max = 20; //максимальное число детей Person[] children = new Person[Child_Max]; int count_children=0; //число детей public Person this[int i] //индексатор { get {if (i>=0 && i< count_children)return(children[i]); else return(children[0]);} set { if (i==count_children && i< Child_Max) {children[i] = value; count_children++;} } }

1.10.7.4. Имя у индексатора - this, в квадратных скобках в заголовке перечисляются индексы. В методах get и set, обеспечивающих доступ к массиву children, по которому ведется индексирование, анализируется корректность задания индекса. Закрытое поле count_children, хранящее текущее число детей, доступно только для чтения благодаря добавлению соответствующего метода-свойства. Надеюсь, текст процедуры-свойства Count_children сумеете написать самостоятельно. Запись в это поле происходит в методе set индексатора, когда к массиву children добавляется новый элемент.

1.10.7.5. Протестируем процесс добавления детей персоны и работу индексатора:

1.10.7.5.1. public void TestPersonChildren() { Person pers1 = new Person(), pers2 = new Person(); pers1.Fam = "Петров"; pers1.Age = 42; pers1.Salary = 10000; pers1[pers1.Count_children] = pers2; pers2.Fam ="Петров"; pers2.Age = 21; pers2.Salary = 1000; Person pers3= new Person(); pers3.Fam="Петрова"; pers1[pers1.Count_children] = pers3; pers3.Fam ="Петрова"; pers3.Age = 5; Console.WriteLine ("Фам={0}, возраст={1}, статус={2}", pers1.Fam, pers1.Age, pers1.Status); Console.WriteLine ("Сын={0}, возраст={1}, статус={2}", pers1[0].Fam, pers1[0].Age, pers1[0].Status); Console.WriteLine ("Дочь={0}, возраст={1}, статус={2}", pers1[1].Fam, pers1[1].Age, pers1[1].Status); }

1.10.8. Операции

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

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

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

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

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

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

1.10.10. Деструкторы класса

1.10.10.1. Если задача создания объектов полностью возлагается на программиста, то задача удаления объектов, после того, как они стали не нужными, в Visual Studio .Net снята с программиста и возложена на соответствующий инструментарий - сборщик мусора. В классическом варианте языка C++ деструктор так же необходим классу, как и конструктор. В языке C# y класса может быть деструктор, но он не занимается удалением объектов и не вызывается нормальным образом в ходе выполнения программы. Так же, как и статический конструктор, деструктор класса, если он есть, вызывается автоматически в процессе сборки мусора. Его роль - в освобождении ресурсов, например, файлов, открытых объектом. Деструктор C# фактически является финализатором (finalizer), с которыми мы еще встретимся при обсуждении исключительных ситуаций. Приведу формальное описание деструктора класса Person:

1.10.10.1.1. ~Person()

1.10.10.1.2. {

1.10.10.1.3. }

1.10.10.1.4. Имя деструктора строится из имени класса с предшествующим ему символом ~ (тильда). Как и у статического конструктора, у деструктора не указывается модификатор доступа.

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

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

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

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

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

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

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

1.10.12.1.1. /// <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; } }

1.10.13. Методы класса Rationalv

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

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

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

1.10.14.1.1. /// <summary> /// Закрытый метод класса. /// Возвращает наибольший общий делитель чисел a,b /// </summary> /// <param name="a">первое число</param> /// <param name="b">второе число, положительное</param> /// <returns>НОД(a,b)</returns> int nod(int m, int n) { int p=0; m=Math.Abs(m); n =Math.Abs(n); if(n>m){p=m; m=n; n=p;} do { p = m%n; m=n; n=p; }while (n!=0); return(m); }//nod

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

1.10.15.1. Почти любой класс содержит один или несколько методов, позволяющих выводить на печать данные о классе. Такой метод имеется и в классе Rational. Вот его текст:

1.10.15.1.1. public void PrintRational(string name)

1.10.15.1.2. {

1.10.15.1.3. Console.WriteLine(" {0} = {1}/{2}",name,m,n);

1.10.15.1.4. }

1.10.15.1.5. Метод печатает имя и значение рационального числа в форме m/n.

1.10.16. Операции над рациональными числами

1.10.16.1. определим над рациональными числами стандартный набор операций - сложение и вычитание, умножение и деление. Реализуем эти операции методами с именами Plus, Minus, Mult, Divide соответственно. Поскольку рациональные числа - это прежде всего именно числа, то для выполнения операций над ними часто удобнее пользоваться привычными знаками операций ( +, -, *, / ). Язык C# допускает определение операций, заданных указанными символами. Этот процесс называется перегрузкой операций, и мы рассмотрим сейчас, как это делается. Конечно, можно было бы обойтись только перегруженными операциями, но мы приведем оба способа. Пользователь сам будет решать, какой из способов применять в конкретной ситуации - вызывать метод или операцию.

1.10.16.1.1. Покажем вначале реализацию метода Plus и операции +:

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

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

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

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

1.11. 07.04.2020 Лекция 15: Регулярные выражения

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

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

1.11.2. Немного теории

1.11.2.1. Пусть T = {a1, a2, ....an} - алфавит символов. Словом в алфавите T называется последовательность записанных подряд символов, а длиной слова - число его символов. Пустое слово, не содержащее символов, обычно обозначается как e. Алфавит T можно рассматривать как множество всех слов длины 1. Рассмотрим операцию конкатенации над множествами, так, что конкатенация алфавита T с самим собой дает множество всех слов длины 2. Обозначается конкатенация ТТ как Т2. Множество всех слов длины k обозначается - Tk, его можно рассматривать как k -кратную конкатенацию алфавита T. Множество всех непустых слов произвольной длины, полученное объединением всех множеств Tk, обозначается T+, а объединение этого множества с пустым словом называется итерацией языка и обозначается T*. Итерация описывает все возможные слова, которые можно построить в данном алфавите. Любое подмножество слов L(T), содержащееся в T*, называется языком в алфавите T.

1.11.2.2. Определим класс языков, задаваемых регулярными множествами. Регулярное множество определяется рекурсивно следующими правилами:

1.11.2.2.1. пустое множество, а также множество, содержащее пустое слово, и одноэлементные множества, содержащие символы алфавита, являются регулярными базисными множествами;

1.11.2.2.2. если множества P и Q являются регулярными, то множества, построенные применением операций объединения, конкатенации и итерации - P>>Q, PQ, P*, Q* - тоже являются регулярными.

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

1.11.2.3.1. регулярные базисные выражения задаются символами и определяют соответствующие регулярные базисные множества, например, выражение f задает одноэлементное множество {f} при условии, что f - символ алфавита T ; если p и q - регулярные выражения, то операции объединения, конкатенации и итерации - p+q, pq, p*, q* - являются регулярными выражениями, определяющими соответствующие регулярные множества.

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

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

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

1.11.3.2.1. символы и escape-последовательности;

1.11.3.2.2. символы операций и символы, обозначающие специальные классы множеств;

1.11.3.2.3. имена групп и обратные ссылки;

1.11.3.2.4. символы утверждений и другие средства.

1.11.4. Таблица 15.1. Символы, используемые в регулярных выражениях

1.11.4.1. Символ Интерпретация

1.11.4.2. Категория: escape-последовательности

1.11.4.3. \b При использовании его в квадратных скобках соответствует символу "обратная косая черта" с кодом - \u0008

1.11.4.4. \t Соответствует символу табуляции \u0009

1.11.4.5. \r Соответствует символу возврата каретки \u000D

1.11.4.6. \n Соответствует символу новой строки \u000A

1.11.4.7. \e Соответствует символу escape \u001B

1.11.4.8. \040 Соответствует символу ASCII, заданному кодом до трех цифр в восьмеричной системе

1.11.4.9. \x20 Соответствует символу ASCII, заданному кодом из двух цифр в шестнадцатеричной системе

1.11.4.10. \u0020 Соответствует символу Unicode, заданному кодом из четырех цифр в шестнадцатеричной системе

1.11.4.11. Категория: подмножества (классы) символов

1.11.4.12. . Соответствует любому символу, за исключением символа конца строки

1.11.4.13. [aeiou] Соответствует любому символу из множества, заданного в квадратных скобках

1.11.4.14. [^aeiou] Отрицание. Соответствует любому символу, за исключением символов, заданных в квадратных скобках

1.11.4.15. [0-9a-fA-F] Задание диапазона символов, упорядоченных по коду. Так, 0-9 задает любую цифру

1.11.4.16. \p{name} Соответствует любому символу, заданному множеству с именем name, например, имя Ll задает множество букв латиницы в нижнем регистре. Поскольку все символы разбиты на подмножества, задаваемые категорией Unicode, то в качестве имени можно задавать имя категории

1.11.4.17. \P{name} Отрицание. Большая буква всегда задает отрицание множества, заданного малой буквой

1.11.4.18. \w Множество символов, используемых при задании идентификаторов - большие и малые символы латиницы, цифры и знак подчеркивания

1.11.4.19. \s Соответствует символам белого пробела

1.11.4.20. \d Соответствует любому символу из множества цифр

1.11.4.21. Категория: Операции (модификаторы)

1.11.4.22. * Итерация. Задает ноль или более соответствий; например, \w*

1.11.4.23. (abc)*. Аналогично, {0,}

1.11.4.24. + Положительная итерация. Задает одно или более соответствий; например, \w+ или (abc)+. Аналогично, {1,}

1.11.4.25. ? Задает ноль или одно соответствие; например, \w? или (abc)?. Аналогично, {0,1}

1.11.4.26. {n} Задает в точности n соответствий; например, \w{2}

1.11.4.27. {n,} Задает, по меньшей мере, n соответствий; например, (abc){2,}

1.11.4.28. {n,m} Задает, по меньшей мере, n, но не более m соответствий; например, (abc){2,5}

1.11.4.29. Категория: Группирование

1.11.4.30. (?<Name>) При обнаружении соответствия выражению, заданному в круглых скобках, создается именованная группа, которой дается имя Name. Например, (?<tel> \d{7}). При обнаружении последовательности из семи цифр будет создана группа с именем tel

1.11.4.31. () Круглые скобки разбивают регулярное выражение на группы. Для каждого подвыражения, заключенного в круглые скобки, создается группа, автоматически получающая номер. Номера следуют в обратном порядке, поэтому полному регулярному выражению соответствует группа с номером 0

1.11.4.32. (?imnsx) Включает или выключает в группе любую из пяти возможных опций. Для выключения опции перед ней ставится знак минус. Например, (?i-s: ) включает опцию i, задающую нечувствительность к регистру, и выключает опцию s - статус single-line

1.11.5. Класс Regex

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

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

1.11.5.2.1. Метод Match

1.11.5.2.2. Метод Matches

1.11.5.2.3. Метод NextMatch

1.11.5.2.4. Метод Split

1.11.6. Классы Match и MatchCollection

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

1.11.6.1.1. свойства Index, Length и Value наследованы от прародителя Capture. Они описывают найденную подстроку- индекс начала подстроки в искомой строке, длину подстроки и ее значение;

1.11.6.1.2. свойство Groups класса Match возвращает коллекцию групп - объект GroupCollection, который позволяет работать с группами, созданными в процессе поиска соответствия;

1.11.6.1.3. свойство Captures, наследованное от объекта Group, возвращает коллекцию CaptureCollection. Как видите, при работе с регулярными выражениями реально приходится создавать один объект класса Regex, объекты других классов автоматически появляются в процессе работы с объектами Regex.

1.11.7. Классы Group и GroupCollection

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

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

1.11.7.2.1. при обнаружении одной подстроки, удовлетворяющей условию поиска, создается не одна группа, а коллекция групп ;

1.11.7.2.2. группа с индексом 0 содержит информацию о найденном соответствии;

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

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

1.11.8. Классы Capture и CaptureCollection

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

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

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

1.11.9. Класс RegexCompilationInfo

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

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

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

1.11.10.1.1. static string FindMatch(string str, string strpat) { Regex pat = new Regex(strpat); Match match =pat.Match(str); string found = ""; if (match.Success) { found =match.Value; Console.WriteLine("Строка ={0}\tОбразец={1}\ tНайдено={2}", str,strpat,found); } return(found); }//FindMatch

1.12. 06.04.2020 Лекция 14: Строки C#. Классы String и StringBuilder

1.12.1. Класс String

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

1.12.2. Объявление строк. Конструкторы класса string

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

1.12.2.1.1. символа, повторенного заданное число раз;

1.12.2.1.2. массива символов char[] ;

1.12.2.1.3. части массива символов.

1.12.2.2. Некоторым конструкторам в качестве параметра инициализации можно передать строку, заданную типом char*. Но все это небезопасно, и подобные примеры приводиться и обсуждаться не будут. Приведу примеры объявления строк с вызовом разных конструкторов:

1.12.2.2.1. public void TestDeclStrings() { //конструкторы string world = "Мир"; //string s1 = new string("s1"); //string s2 = new string(); string sssss = new string('s',5); char[] yes = "Yes".ToCharArray(); string stryes = new string(yes); string strye = new string(yes,0,2); Console.WriteLine("world = {0}; sssss={1}; stryes={2};"+ " strye= {3}", world, sssss, stryes, strye); }

1.12.3. Операции над строками

1.12.3.1. присваивание ( = );

1.12.3.2. две операции проверки эквивалентности ( == ) и ( != );

1.12.3.3. конкатенация или сцепление строк ( + );

1.12.3.4. взятие индекса ( [] ).

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

1.12.3.6. Возможность взятия индекса при работе со строками отражает тот приятный факт, что строку можно рассматривать как массив и получать без труда каждый ее символ. Каждый символ строки имеет тип char, доступный только для чтения, но не для записи. Вот пример, в котором над строками выполняются данные операции:

1.12.3.6.1. public void TestOpers() { //операции над строками string s1 ="ABC", s2 ="CDE"; string s3 = s1+s2; bool b1 = (s1==s2); char ch1 = s1[0], ch2=s2[0]; Console.WriteLine("s1={0}, s2={1}, b1={2}," + "ch1={3}, ch2={4}", s1,s2,b1,ch1,ch2); s2 = s1; b1 = (s1!=s2); ch2 = s2[0]; Console.WriteLine("s1={0}, s2={1}, b1={2}," + "ch1={3}, ch2={4}", s1,s2,b1,ch1,ch2); //Неизменяемые значения s1= "Zenon"; //s1[0]='L'; }

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

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

1.12.4.1.1. обычные константы, которые представляют строку символов, заключенную в кавычки;

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

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

1.12.4.2.1. //Два вида констант s1= "\x50"; [email protected]"\x50"""; b1= (s1==s2); Console.WriteLine("s1={0}, s2={1}, b1={2}", s1,s2,b1); s1 = "c:\\c#book\\ch5\\chapter5.doc"; s2 = @"c:\c#book\ch5\chapter5.doc"; b1= (s1==s2); Console.WriteLine("s1={0}, s2={1}, b1={2}", s1,s2,b1); s1= "\"A\""; [email protected]"""A"""; b1= (s1==s2); Console.WriteLine("s1={0}, s2={1}, b1={2}", s1,s2,b1);

1.12.5. Неизменяемый класс string

1.12.5.1. В языке C# существует понятие неизменяемый (immutable) класс. Для такого класса невозможно изменить значение объекта при вызове его методов. Динамические методы могут создавать новый объект, но не могут изменить значение существующего объекта. К таким неизменяемым классам относится и класс String. Ни один из методов этого класса не меняет значения существующих объектов. Конечно, некоторые из методов создают новые значения и возвращают в качестве результата новые строки. Невозможность изменять значения строк касается не только методов. Аналогично, при работе со строкой как с массивом разрешено только чтение отдельных символов, но не их замена. Оператор присваивания из нашего последнего примера, в котором делается попытка изменить первый символ строки, недопустим, а потому закомментирован.

1.12.5.1.1. //Неизменяемые значения s1= "Zenon"; ch1 = s1[0]; //s1[0]='L';

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

1.12.6.1. Метод Описание

1.12.6.2. Empty Возвращается пустая строка. Свойство со статусом read only

1.12.6.3. Compare Сравнение двух строк. Метод перегружен. Реализации метода позволяют сравнивать как строки, так и подстроки. При этом можно учитывать или не учитывать регистр, особенности национального форматирования дат, чисел и т.д.

1.12.6.4. CompareOrdinal Сравнение двух строк. Метод перегружен. Реализации метода позволяют сравнивать как строки, так и подстроки. Сравниваются коды символов

1.12.6.5. Concat Конкатенация строк. Метод перегружен, допускает сцепление произвольного числа строк

1.12.6.6. Copy Создается копия строки

1.12.6.7. Format Выполняет форматирование в соответствии с заданными спецификациями формата. Ниже приведено более полное описание метода

1.12.6.8. Intern, IsIntern Отыскивается и возвращается ссылка на строку, если таковая уже хранится во внутреннем пуле данных. Если же строки нет, то первый из методов добавляет строку во внутренний пул, второй - возвращает null. Методы применяются обычно тогда, когда строка создается с использованием построителя строк - класса StringBuilder

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

1.12.7. Метод Format

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

1.12.7.1.1. Console.WriteLine("s1={0}, s2={1}", s1,s2);

1.12.7.1.2. Общий синтаксис, специфицирующий формат, таков:

1.12.7.1.3. Обязательный параметр N задает индекс объекта, заменяющего формат. Можно считать, что методу всегда передается массив объектов, даже если фактически передан один объект. Индексация объектов начинается с нуля, как это принято в массивах. Второй параметр M, если он задан, определяет минимальную ширину поля, которое отводится строке, вставляемой вместо формата. Третий необязательный параметр задает коды форматирования, указывающие, как следует форматировать объект. Например, код C ( Currency ) говорит о том, что параметр должен форматироваться как валюта с учетом национальных особенностей представления. Код P ( Percent ) задает форматирование в виде процентов с точностью до сотой доли. Все становится ясным, когда появляются соответствующие примеры. Вот они:

1.12.8. Методы Join и Split

1.12.8.1. Методы Join и Split выполняют над строкой текста взаимно обратные преобразования. Динамический метод Split позволяет осуществить разбор текста на элементы. Статический метод Join выполняет обратную операцию, собирая строку из элементов.

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

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

1.12.8.3.1. public string[] Split(params char[])

1.12.8.4. На вход методу Split передается один или несколько символов, интерпретируемых как разделители. Объект string, вызвавший метод, разделяется на подстроки, ограниченные этими разделителями. Из этих подстрок создается массив, возвращаемый в качестве результата метода. Другая реализация позволяет ограничить число элементов возвращаемого массива.

1.12.8.5. Синтаксис статического метода Join таков:

1.12.8.5.1. public static string Join(string delimiters, string[] items )

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

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

1.12.8.7.1. public void TestSplitAndJoin() { string txt = "А это пшеница, которая в темном чулане хранится," +" в доме, который построил Джек!"; Console.WriteLine("txt={0}", txt); Console.WriteLine("Разделение текста на простые предложения:"); string[] SimpleSentences, Words; //размерность массивов SimpleSentences и Words //устанавливается автоматически в соответствии с //размерностью массива, возвращаемого методом Split SimpleSentences = txt.Split(','); for(int i=0;i< SimpleSentences.Length; i++) Console.WriteLine("SimpleSentences[{0}]= {1}", i, SimpleSentences[i]); string txtjoin = string.Join(",",SimpleSentences); Console.WriteLine("txtjoin={0}", txtjoin); Words = txt.Split(',', ' '); for(int i=0;i< Words.Length; i++) Console.WriteLine("Words[{0}]= {1}",i, Words[i]); txtjoin = string.Join(" ",Words); Console.WriteLine("txtjoin={0}", txtjoin); }//TestSplitAndJoin

1.12.9. Динамические методы класса String

1.12.9.1. Операции, разрешенные над строками в C#, разнообразны. Методы этого класса позволяют выполнять вставку, удаление, замену, поиск вхождения подстроки в строку. Класс String наследует методы класса Object, частично их переопределяя. Класс String наследует и, следовательно, реализует методы четырех интерфейсов: IComparable, ICloneable, IConvertible, IEnumerable. Три из них уже рассматривались при описании классов-массивов. Рассмотрим наиболее характерные методы при работе со строками. Сводка методов, приведенная в таблице 14.2, дает достаточно полную картину широких возможностей, имеющихся при работе со строками в C#. Следует помнить, что класс string является неизменяемым. Поэтому Replace, Insert и другие методы представляют собой функции, возвращающие новую строку в качестве результата и не изменяющие строку, вызвавшую метод.

1.12.10. Таблица 14.2. Динамические методы и свойства класса String

1.12.10.1. Метод Описание

1.12.10.2. Insert Вставляет подстроку в заданную позицию

1.12.10.3. Remove Удаляет подстроку в заданной позиции

1.12.10.4. Replace Заменяет подстроку в заданной позиции на новую подстроку

1.12.10.5. Substring Выделяет подстроку в заданной позиции

1.12.10.6. IndexOf, IndexOfAny, LastIndexOf, LastIndexOfAny Определяются индексы первого и последнего вхождения заданной подстроки или любого символа из заданного набора

1.12.10.7. StartsWith, EndsWith Возвращается true или false, в зависимости от того, начинается или заканчивается строка заданной подстрокой

1.12.10.8. PadLeft, PadRight Выполняет набивку нужным числом пробелов в начале и в конце строки

1.12.10.9. Trim, TrimStart, TrimEnd Обратные операции к методам Pad. Удаляются пробелы в начале и в конце строки, или только с одного ее конца

1.12.10.10. ToCharArray Преобразование строки в массив символов

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

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

1.12.11.2. Объявление строк. Конструкторы класса StringBuilder

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

1.12.11.2.2. public StringBuilder (string str, int cap). Параметр str задает строку инициализации, cap - емкость объекта ;

1.12.11.2.3. public StringBuilder (int curcap, int maxcap). Параметры curcap и maxcap задают начальную и максимальную емкость объекта ;

1.12.11.2.4. public StringBuilder (string str, int start, int len, int cap). Параметры str, start, len задают строку инициализации, cap - емкость объекта.

1.12.11.3. Операции над строками

1.12.11.3.1. Над строками этого класса определены практически те же операции с той же семантикой, что и над строками класса String:

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

1.12.12.1. У класса StringBuilder методов значительно меньше, чем у класса String. Это и понятно - класс создавался с целью дать возможность изменять значение строки. По этой причине у класса есть основные методы, позволяющие выполнять такие операции над строкой как вставка, удаление и замена подстрок, но нет методов, подобных поиску вхождения, которые можно выполнять над обычными строками. Технология работы обычно такова: конструируется строка класса StringBuilder ; выполняются операции, требующие изменение значения; полученная строка преобразуется в строку класса String ; над этой строкой выполняются операции, не требующие изменения значения строки. Давайте чуть более подробно рассмотрим основные методы класса StringBuilder:

1.12.12.1.1. public StringBuilder Append (<объект>). К строке, вызвавшей метод, присоединяется строка, полученная из объекта, который передан методу в качестве параметра. Метод перегружен и может принимать на входе объекты всех простых типов, начиная от char и bool до string и long. Поскольку объекты всех этих типов имеют метод ToString, всегда есть возможность преобразовать объект в строку, которая и присоединяется к исходной строке. В качестве результата возвращается ссылка на объект, вызвавший метод. Поскольку возвращаемую ссылку ничему присваивать не нужно, то правильнее считать, что метод изменяет значение строки;

1.12.12.1.2. public StringBuilder Insert (int location,<объект>). Метод вставляет строку, полученную из объекта, в позицию, указанную параметром location. Метод Append является частным случаем метода Insert ;

1.12.12.1.3. public StringBuilder Remove (int start, int len). Метод удаляет подстроку длины len, начинающуюся с позиции start ;

1.12.12.1.4. public StringBuilder Replace (string str1,string str2). Все вхождения подстроки str1 заменяются на строку str2 ;

1.12.12.1.5. public StringBuilder AppendFormat (<строка форматов>, <объекты>). Метод является комбинацией метода Format класса String и метода Append. Строка форматов, переданная методу, содержит только спецификации форматов. В соответствии с этими спецификациями находятся и форматируются объекты. Полученные в результате форматирования строки присоединяются в конец исходной строки.

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

1.12.13. Емкость буфера

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

1.12.13.1.1. У класса StringBuilder имеется 2 свойства и один метод, позволяющие анализировать и управлять емкостными свойствами буфера. Напомню, что этими характеристиками можно управлять также еще на этапе создания объекта, - для этого имеется соответствующий конструктор. Рассмотрим свойства и метод класса, связанные с емкостью буфера:

1.12.13.1.2. Приведу код, в котором проводятся различные эксперименты с емкостью буфера:

1.13. 04.04.2020 Лекция 13: Символы и строки постоянной длины в C#

1.13.1. Общий взгляд

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

1.13.1.1.1. отдельные символы, чаще всего, его называют типом char ;

1.13.1.1.2. строки постоянной длины, часто они представляются массивом символов;

1.13.1.1.3. строки переменной длины - это, как правило, тип string, соответствующий современному представлению о строковом типе.

1.13.2. Строки С++

1.13.2.1. В языке С++ есть все виды строк. Символьный тип char используется для задания отдельных символов. Для строк постоянной длины можно использовать массив символов - char[]. Особенностью, характерной для языка С++, точнее для языка С, является завершение строки символом с нулевым кодом. Строки, завершаемые нулем, называются обычно строками С. Массив char[] задает строку С и потому должен иметь размер, по крайней мере, на единицу больше фактического размера строки. Вот пример объявления подобных строк в С++:

1.13.2.1.1. //Массивы и строки char strM1[] = "Hello, World!"; char strM2[20] = "Yes";

1.13.2.2. Другой способ задания строк С, заканчивающихся нулем, состоит в использовании типизированного указателя - char*.

1.13.2.2.1. //Строки, заданные указателем char* char* strPM1 ="Hello, World!"; char* strPM2;

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

1.13.2.3.1. void mycopy(char* p, const char* q) { while(*p++ = *q++); }

1.13.3. Класс char

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

1.13.3.1.1. символом, заключенным в одинарные кавычки;

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

1.13.3.1.3. Unicode-последовательностью, задающей Unicode-код символа.

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

1.13.3.2.1. 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

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

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

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

1.13.4.2. Методы IndexOf, LastIndexOf позволяют определить индексы первого и последнего вхождения в строку некоторого символа. К сожалению, их нельзя использовать для более интересной операции - нахождения индекса вхождения подстроки в строку. При необходимости такую процедуру можно написать самому. Вот как она выглядит:

1.13.4.2.1. 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

1.14. 28.03.2020 Лекция 12: Класс Array и новые возможности массивов

1.14.1. Класс Array

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

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

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

1.14.1.2.1. 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

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

1.14.1.3.1. 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

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

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

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

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