Предговор

Ако по принцип не четете уводите на книгите, помислете преди да пропуснете и този. Той е малко по-различен от всички останали, защото тази книга е също малко по-различна от всички останали.

Ако смятате, че ще ви досадим с общи приказки, можете да не се задълбочавате прекалено, но ви препоръчваме поне да преминете през следващите страници "по вентилаторната система", за да разберете какво ви предстои да научите от следващите страници. Ще разберете какво е .NET Framework, за какво служи, какви технологии обхваща и как настоящата книга от една идея се превърна в реалност.

Това е първата чисто българска книга за програмиране с .NET Framework и C#, но за сметка на това е една от най-полезните книги в тази област. Написана от специалисти с опит както в практическата работа с .NET, така и в обучението по програмиране, книгата ще ви даде не само основите на .NET програмирането, но и ще ви запознае с някои по-сложни концепции и ще ви предаде от опита на авторите.

За кого е предназначена тази книга?

.NET Framework? Ама какво е това? Някаква нова измислица на Microsoft или просто поредния език за програмиране? Да не би да са направили нова версия на C++ или Java? A какъв е тоя език C#? Не мога ли да си пиша на C или C++? Какво е това среда за управлявано изпълнение на код? Не отмина ли вече времето на интерпретираните езици? Защо въобще трябва да сменяме добрите стари платформи с този .NET?

Ако нямате ясен отговор на всички тези въпроси, тази книга е за вас! Ако пък имате – тази книга също е за вас, защото едва ли знаете всичко за програмирането с .NET Framework и едва ли познавате добре всички по-важни технологии, свързани с него.

Тази книга ще ви даде много повече от начални знания. Тя ще ви предаде опит, натрупан в продължение години, и ще ви запознае с утвърдените практики при използването на .NET технологиите.

Тази книга е за всички, които искат да се научат да програмират с .NET Framework и C#, както и за всички, които вече имат основни знания и умения в областта, но искат да ги разширят и да навлязат в някои от по-сложните технологии, с които нямат достатъчно опит.

Книгата е полезна не само за .NET програмисти, но и за всички, които имат желание да се занимават сериозно с разработка на софтуер. В нея се обръща внимание не само на специфичните .NET технологии, но и на някои фундаментални концепции, които всеки програмист трябва добре да знае и разбира.

Необходими начални познания

Тази книга не е подходяща за хора, които никога не са програмирали в живота си. Ако сте абсолютно начинаещ, спрете да четете и просто започнете с друга книга!

В нея няма да намерите обяснения за това какво е променлива, какво е тип данни, какво е условна конструкция, какво е цикъл и какво е функция. Очакваме читателят да е запознат добре с всички тези понятия и с основите на програмирането. Познанията по обектно-ориентирано програмиране (ООП) също ще са полезни, тъй като в книгата не се изясняват в дълбочина теоретичните концепции на ООП, а само средствата за тяхното прилагане в езика C#.

Какво представлява .NET Framework?

.NET Framework е съвременна платформа за разработка и изпълнение на приложения. Тя предоставя програмен модел, стандартна библиотека от класове и среда за контролирано изпълнение на програмен код.

.NET Framework поддържа различни езици за програмиране и позволява тяхната съвместна работа. .NET приложенията се пишат на езици от високо ниво (C#, VB.NET, Managed C++ и други) и се компилират до междинен език от ниско ниво, наречен IL (Intermediate Language). По време на изпълнение IL програмите (т. нар. управляван код) се компилират до инструкции за текущата хардуерна архитектура, съобразени с текущата операционна система, и след това се изпълняват от микропроцесора.

.NET Framework включва в себе си стандартна библиотека, която съдържа базова функционалност за разработка, необходима за повечето приложения, като вход/изход, връзка с бази данни, работа с XML, изграждане на уеб приложения, използване на уеб услуги, изграждане на графичен потребителски интерфейс и др.

Какво обхваща тази книга?

Програмирането за .NET Framework изисква познания на неговите базови концепции (модел на изпълнение на кода, обща система от типове, управление на паметта, масиви, колекции, символни низове и др.), както и познаване на често използваните технологии – ADO.NET (за достъп до бази от данни), Windows Forms (за приложения с графичен потребителски интерфейс), ASP.NET (за уеб приложения и уеб услуги) и др.

Настоящата книга обхваща всички тези концепции и технологии, свързани с разработката на приложения за .NET Framework. Тя има за цел да запознае читателя с принципите на разработка на приложения за Microsoft .NET Framework и да даде широки познания по всички по-важни технологии, свързани с него.

Най-важните теми, които ще бъдат разгледани, са: архитектура на .NET Framework, управлявана среда за изпълнение на код (CLR), езикът C# и реализация на обектно-ориентирано програмиране с неговите средства, обща система от типове (CTS), основна библиотека от класове (Framework Class Library), достъп до бази от данни с ADO.NET, работа с XML, създаване на графичен потребителски интерфейс с Windows Forms и уеб-базирани приложения с ASP.NET. Ще бъде обърнато внимание и на някои по-сложни концепции като отражение на типовете, сериализация, многонишково програмиране, уеб услуги, отдалечено извикване на методи (remoting), взаимодействие с неуправляван код, асемблита, управление на сигурността, по-важни инструменти за разработка и др. Ще бъде разгледана и свободната имплементация на .NET Framework за Linux и други операционни системи (Mono). Накрая ще бъде описана разработката на един цялостен практически проект, който обхваща всички по-важни технологии и демонстрира добрите практики при изграждането на .NET приложения.

Фокусът е върху .NET Framework 1.1

Всички теми са базирани на .NET Framework 1.1, Visual Studio .NET 2003 и MS SQL Server 2000. Не се обръща много внимание на новостите в .NET Framework 2.0, Visual Studio 2005 и SQL Server 2005, тъй като по време на разработката на книгата тези продукти и технологии все още не бяха официално излезли на пазара и тяхното бъдеще не беше съвсем ясно.

Въпреки предстоящото излизане на .NET Framework 2.0, настоящата книга си остава изключително полезна, тъй като в същината си версия 2.0 не носи фундаментални промени, а по-скоро разширява вече съществуващите технологии, които ще разгледаме в книгата.

Как е представена информацията?

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

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

Всички автори ясно съзнават, че примерният сорс код е едно от най-важните неща в една книга за програмиране. Именно поради тази причина текстът е съпроводен с много, много примери, илюстрации и картинки.

Въобще някой чете ли текста, когато има добър и ясен пример? Повечето програмисти първо гледат дали примерът ще им свърши работа, и само ако нещо не е ясно, се зачитат в текста (това всъщност не е никак добра практика, но такава е реалността). Ето защо многото и добре подбрани примери са един от най-важните принципи, залегнали в тази книга.

Защо C#?

Всички примери в книгата са написани на езика C#, въпреки, че .NET Framework поддържа много други езици. Този избор е направен по няколко причини:

- C# е препоръчваният език за програмиране за .NET Framework. Архитектите на езика специално са го проектирали за .NET Framework и са го съобразили с особеностите на платформата още по време на дизайна. C# наследява простотата на Java, мощността на C++ и силните черти на Delphi. Той притежава максимално стегнат и ясен синтаксис.

- В България C# е най-популярният от .NET езиците и се използва най-масово в българските софтуерни компании.

- C# е от семейството на C-базираните езици и синтактично много прилича на Java, C++, C и PHP. Много хора, които не знаят езика, биха разбрали примерите без особени усилия.

- За C# има повече статии в специализираните сайтове и лични дневници (blogs) в Интернет. Общността на C# разработчиците е по-добре развита, отколкото на разработчиците на другите .NET езици.

- Поради голямата популярност на езика C# за него има по-добра поддръжка от инструментите за разработка.

- Езици като C++, Visual Basic и JScript не са проектирани специално за .NET Framework, а са адаптирани допълнително към него чрез редица изменения и добавки. В следствие на това те запазват някои синтактични особености, които не са удобни при работата с .NET.

Ако сега започвате да изучавате .NET Framework, Ви препоръчваме да стартирате от езика C#. След като го овладеете, можете да опитате и другите .NET езици, но за начало C# е най-подходящ.

По принцип езикът C++ може да се използва при програмиране с .NET Framework, но това се препоръчва само при някои много специфични приложения. Този език по първоначален замисъл не е проектиран за .NET платформата и има съвсем друго предназначение. Той е много по-сложен и труден от C# и затова е по-добре да използвате C#, дори ако трябва да го учите от начало. Ако вече знаете C++, няма да ви е трудно да овладеете C# и когато го направите, ще се убедите, че с него се работи много по-лесно.

Въпреки, че езикът Visual Basic .NET (VB.NET) има някои предимства и се използва масово по света, за предпочитане е да ползвате C# при изграждане на .NET приложения. Езикът Visual Basic е масово разпространен по исторически причини (благодарение най-вече на Бил Гейтс). Някои специалисти изказват силно негативни мнения срещу BASIC и произлизащите от него езици, докато други (включително и Microsoft) го подкрепят и препоръчват.

Ще си позволим да цитираме изказването на един от най-известните учени в областта на компютърните науки проф. д-р Едсгар Дейкстра за езика BASIC, от който произлиза VB.NET:

Практически е невъзможно да научиш на добро програмиране студенти, които са имали предишен досег до езика BASIC – като потенциални програмисти, те са мисловно осакатени, без надежда за възстановяване.

Едсгар Дейкстра

Горният цитат се отнася за старите версии на езика BASIC. VB.NET е вече съвременен обектно-ориентиран език, който не отстъпва по нищо на C#, освен че има малко по-нетрадиционен синтаксис (в сравнение със семейството на C-базираните езици).

.NET Framework позволява всеки да програмира на любимия си език. Изборът си е лично ваш. Ние можем само да ви дадем препоръки. За целите на настоящата книга авторският колектив е избрал езика C# и препоръчва на читателите да започнат от него.

Поглед към съдържанието на книгата

Книгата се състои от 29 глави, които поради големия обем са разделени в два тома. Том 1 съдържа първите 14 глави, а том 2 – останалите 15. Това важи само за хартиеното издание на книгата. В електронния вариант тя се разпространява като едно цяло.

Нека направим кратък преглед на всяка една от главите и да се запознаем с нейното съдържание, за да разберем какво ни очаква по-нататък.

Глава 1. Архитектура на .NET Framework

В глава 1 е представена платформата .NET, която въплъщава визията на Microsoft за развитието на информационните и софтуерните технологии, след което е разгледана средата за разработка и изпълнение на .NET приложения Microsoft .NET Framework.

Обръща се внимание на управлявания код, на езика IL, на общата среда за контролирано изпълнение на управляван код (Common Language Runtime) и на модела на компилация и изпълнение на .NET кода. Разглеждат се още Common Language Specification (CLS), Common Type System (CTS), Common Language Infrastructure (CLI), интеграцията на различни езици, библиотеката от класове Framework Class Library и интегрираната среда за разработка Visual Studio .NET.

Автори на главата са Виктор Живков и Николай Недялков. Текстът е написан с широко използване на лекциите на Светлин Наков по темата и е редактиран от Иван Митев и Светлин Наков.

Глава 2. Въведение в езика C#

Глава 2 разглежда езика С#, неговия синтаксис и основни концепции. Представя се средата за разработка Visual Studio .NET 2003 и се демонстрира работата с нейния дебъгер. Отделя се внимание на типовете данни, изразите, програмните конструкции и конструкциите за управление в езика C#. Накрая се демонстрира колко лесно и полезно е XML документирането на кода в С#.

Автор на главата е Моника Алексиева. Текстът е базиран на лекцията на Светлин Наков по същата тема и е редактиран от Панайот Добриков и Преслав Наков.

Глава 3. Обектно-ориентирано програмиране в .NET

В глава 3 се прави кратък обзор на основните принципи на обектно-ориентираното програмиране (ООП) и средствата за използването им в .NET Framework и езика C#. Представят се типовете "клас", "структура" и "интерфейс" в C#. Въвежда се понятието "член на тип" и се разглеждат видовете членове (член-променливи, методи, конструктори, свойства, индексатори и др.) и тяхната употреба. Разглежда се наследяването на типове в различните му аспекти и приложения. Обръща се внимание и на полиморфизма в C# и свързаните с него понятия и програмни техники. Накрая се дискутират някои утвърдени практики при създаването на ефективни йерархии от типове.

Автор на главата е Стефан Кирязов. Текстът е написан с широко използване на лекции на Светлин Наков и е редактиран от Цветелин Андреев и Панайот Добриков.

Глава 4. Обработка на изключения в .NET

В глава 4 се разглеждат изключенията в .NET Framework като утвърден механизъм за управление на грешки и непредвидени ситуации. Дават се обяснения как се прихващат и обработват изключения. Разглеждат се начините за тяхното предизвикване и различните видове изключения в .NET Framework. Дават се примери за дефиниране на собствени (потребителски) изключения.

Автори на главата са Явор Ташев и Светлин Наков. Текстът е написан с широко използване на лекции на Светлин Наков по темата. Редактор е Мартин Кулов.

Глава 5. Обща система от типове

В глава 5 се разглежда общата система от типове (Common Type System) в .NET Framework. Обръща се внимание на разликата между стойностни и референтни типове, разглежда се основополагащият тип System.Object и йерархията на типовете, произлизаща от него. Дискутират се и някои особености при работа с типове – преобразуване към друг тип, проверка на тип, клониране, опаковане, разопаковане и др.

Автор на главата е Светлин Наков. Текстът е базиран изцяло на лекцията на Светлин Наков по същата тема и е редактиран от Преслав Наков и Панайот Добриков.

Глава 6. Делегати и събития

В глава 6 се разглежда референтният тип "делегат". Илюстрирани се начините за неговото използване, различните видове делегати, както и негови характерни приложения. Представя се понятието "събитие" и се обяснява връзката му с делегатите. Прави се сравнение между делегатите и интерфейсите и се дават препоръки в кои случаи да се използват едните и в кои – другите.

Автор на главата е Лазар Кирчев. Текстът е базиран на лекцията на Светлин Наков по същата тема.

Глава 7. Атрибути

В глава 7 се разглежда какво представляват атрибутите в .NET Framework, как се прилагат и къде се използват. Дават се обяснения как можем да дефинираме собствени атрибути и да извличаме приложените атрибути от метаданните на асемблитата.

Автори на главата са Преслав Наков и Панайот Добриков. Текстът е базиран основно на лекцията на Светлин Наков по същата тема и е редактиран от него.

Глава 8. Масиви и колекции

В глава 8 се представят масивите и колекциите в .NET Framework. Разглеждат се видовете масиви – едномерни, многомерни и масиви от масиви (т. нар. назъбени масиви), както и базовият за всички масиви тип System. Array. Дискутират се начините за сортиране на масиви и търсене в тях. Разглеждат се колекциите и тяхната реализация в .NET Framework, класовете ArrayList, Queue, Stack, Hashtable и SortedList, както и интерфейсите, които те имплементират.

Автори на главата са Стефан Добрев и Деян Варчев. Текстът е базиран на лекцията на Светлин Наков по същата тема и е редактиран от него.

Глава 9. Символни низове

В глава 9 се разглежда начинът на представяне на символните низове в .NET Framework и методите за работа с тях. Обръща се внимание на кодиращите схеми, които се използват при съхраняване и пренос на текстова информация. Разглеждат се подробно различните начини за манипулиране на низове, както и някои практически съображения при работата с тях. Демонстрира се как настройките за държава и регион (култура) определят вида на текста, показван на потребителите, и как можем да форматираме изхода в четлив и приемлив вид. Разглеждат се също и начините за преобразуване на вход от потребителя от текст в обект от стандартен тип, с който можем лесно да работим.

Автори на главата са Васил Бакалов и Александър Хаджикръстев. В текста е широко използвана лекцията на Светлин Наков по същата тема. Главата е редактирана от Иван Митев.

Глава 10. Регулярни изрази

В глава 10 се разглеждат регулярните изрази, набиращи все по-голяма популярност сред разработчиците на софтуер при решаването на проблеми, свързани с обработката на текст. Дискутират се произходът и същността на регулярните изрази, техният синтаксис и основните правила при конструирането им. В главата е предложено кратко представяне на основните дейности, при които е подходящо използването на регулярни изрази, и са дадени конкретни насоки как можем да правим това със средствата на .NET Framework. Разглежда се инструментариумът, за работа с регулярни изрази, който стандартната библиотека с класове предоставя, и се описват най-важните методи, съпроводени с достатъчно примери.

Автор на главата е Георги Пенчев. При изготвянето на текста е частично използвана лекцията на Светлин Наков по темата. Технически редактор е Иван Митев.

Глава 11. Вход/изход

В глава 11 се разглежда начинът, по който се осъществяват вход и изход от дадена програма в .NET Framework. Представят се различните видове потоци – абстракцията, която позволява връзката на програмата с някакво устройство за съхранение на данни. Обяснява се работата на четците и писачите, които обвиват потоците и така улесняват тяхното използване. Накрая, се прави преглед на средствата, които .NET Framework предоставя за работа с файлове и директории и за наблюдение на файловата система.

Автор на главата е Александър Русев. Текстът е базиран на лекцията на Светлин Наков по същата тема и е редактиран от Галин Илиев и Светлин Наков.

Глава 12. Работа с XML

В глава 12 се разглежда работата с XML в .NET Framework. Обяснява се накратко какво представлява езикът XML. Обръща се внимание на приликите и разликите между него и HTML. Разглеждат се приложенията на XML, пространствата от имена и различните схеми за валидация на XML документи (DTD, XSD, XDR). Представят се средствата на Visual Studio .NET за работа с XSD схеми. Разглеждат се особеностите на класическите XML парсери (DOM и SAX) и как те са имплементирани в .NET Framework. Описват се подробно класовете за работа с DOM парсера (XmlNode и XmlDocument) и ролята на класа XmlReader при SAX парсерите в .NET Framework. Обръща се внимание на начина на работа на класа XmlWriter за създаване на XML документи. Дискутират се начините за валидация на XML документи спрямо дадена схема. Разглежда се поддръжката в .NET Framework и на някои други XML-базирани технологии като XPath и XSLT.

Автор на главата е Манол Донев, а редактори са Иван Митев и Светлин Наков. Текстът широко използва лекцията на Светлин Наков по същата тема.

Глава 13. Релационни бази от данни и MS SQL Server

В глава 13 се разглеждат системите за управление на релационни бази от данни. Обясняват се свързаните с тях понятия като таблици, връзки, релационна схема, нормализация, изгледи, ограничения, транзакции, съхранени процедури и тригери. Прави се кратък преглед на езика SQL, използван за манипулиране на релационни бази от данни.

След въведението в проблематиката на релационните бази от данни се прави кратък преглед на Microsoft SQL Server, като типичен представител на RDBMS сървърите. Разглеждат се неговите основни компоненти и инструменти за управление. Представя се използваното от него разширение на езика SQL, наречено T-SQL, и се дискутират основните DDL, DML и DBCC команди. Обръща се внимание на съхранените процедури в SQL Server и се обяснява как той поддържа някои важни характеристики на една релационна база от данни, като транзакции, нива на изолация и др.

Автор на главата е Стефан Захариев. В текста са използвани учебни материали от Бранимир Гюров, Светлин Наков и Стефан Захариев. Редактор е Светлин Наков.

Глава 14. ADO.NET и работа с данни

В глава 14 се разгледат подробно двата модела за достъп до данни, реализирани в ADO.NET – свързан и несвързан. Описва се програмният модел на ADO.NET, неговите компоненти и доставчиците на данни. Обяснява се кои класове се използват за свързан достъп до данни, и кои – за несвързан.

При разглеждането на свързания модел за достъп до данни се обръща внимание на доставчикa на данни SqlClient за връзка с MS SQL Server и се обяснява как се използват класовете SqlConnection, SqlCommand и SqlDataReader. Разглежда се работата с параметризирани заявки и използването на транзакции от ADO.NET. Дава се пример за достъп и до други бази от данни през OLE DB. Разглеждат се и някои проблеми при работа с дати и съхранение на графични изображения в базата данни.

При разглеждането на несвързания модел за достъп до данни се дискутират в детайли основните ADO.NET класове за неговата реализация – DataSet и DataTable. Дават се примери и обяснения как се използват ограничения, изрази, релации и изгледи в обектния модел DataSet. Обръща се специално внимание на класа DataAdapter и вариантите за неговото използване при зареждане на данни и обновяване на базата от данни. Разглеждат се подходите за решаване на конфликти при нанасяне на промени в базата данни. Дискутират се и начините за връзка между ADO.NET и XML, а накрая се разглеждат проблемите със сигурността в приложенията, използващи бази от данни.

Автори на главата са Христо Радков (частта за свързания модел) и Лазар Кирчев (частта за несвързания модел). Главата е разработена с широко използване на лекцията на Бранимир Гюров и Светлин Наков по същата тема. Редактори са Светлин Наков и Мартин Кулов.

Глава 15. Графичен потребителски интерфейс с Windows Forms

В глава 15 се разглеждат средствата на Windows Forms за създаване на прозоречно-базиран графичен потребителски интерфейс (GUI) за .NET приложенията. Представят се програмният модел на Windows Forms, неговите базови контроли, средствата за създаване на прозорци, диалози, менюта, ленти с инструменти и статус ленти, както и някои по-сложни концепции като: MDI приложения, data-binding, наследяване на форми, хостинг на контроли в Internet Explorer, работа с нишки във Windows Forms и др.

Автори на главата са Радослав Иванов (по-голямата част) и Светлин Наков. Текстът е базиран на лекцията на Светлин Наков по същата тема.

Глава 16. Изграждане на уеб приложения с ASP.NET

В глава 16 се разглежда разработката на уеб приложения с ASP.NET. Представят се програмният модел на ASP.NET, уеб формите, кодът зад тях, жизненият цикъл на уеб приложенията, различните типове контроли и техните събития. Показва се как се дебъгват и проследяват уеб приложения. Отделя се внимание на валидацията на данни, въведени от потребителя. Разглежда се концепцията за управление на състоянието на обектите – View State и Session State. Демонстрира се как могат да се визуализират и редактират данни, съхранявани в база от данни. Дискутират се разгръщането и конфигурирането на ASP.NET уеб приложенията в Internet Information Server (IIS) и сигурността при уеб приложенията.

Автор на главата е Михаил Стойнов. Текстът е базиран на лекцията на Михаил Стойнов по същата тема.

Глава 17. Многонишково програмиране и синхронизация

В глава 17 се разглежда многозадачността в съвременните операционни системи и средствата за паралелно изпълнение на програмен код, които .NET Framework предоставя. Обръща се внимание на нишките (threads), техните състояния и управлението на техния жизнен цикъл – стартиране, приспиване, събуждане, прекратяване и др.

Разглеждат средствата за синхронизация на нишки при достъп до общи данни, както и начините за изчакване на зает ресурс и нотификация при освобождаване на ресурс. Обръща се внимание както на синхронизационните обекти в .NET Framework, така и на неуправляваните синхронизационни обекти от операционната система.

Изяснява се концепцията за работа с вградения в .NET Framework пул от нишки (thread pool), начините за асинхронно изпълнение на задачи, средствата за контрол над тяхното поведение и препоръчваните практики за работа с тях.

Автор на главата е Александър Русев. Текстът е базиран в голямата си част на лекцията на Михаил Стойнов и авторските бележки в нея.

Глава 18. Мрежово и Интернет програмиране

В глава 18 се разглеждат някои основни средства, предлагани от .NET Framework за мрежово програмиране. Главата започва със съвсем кратко въведение в принципите на работа на съвременните компютърни мрежи и на Интернет и продължава с протоколите, чрез които се осъществява мрежовата комуникация. Обект на дискусия са както класовете за работа с TCP и UDP сокети, така и някои класове, предлагащи по-специфични възможности, като представяне на IP адреси, изпълняване на DNS заявки и др. В края на главата ще се представят средствата за извличане на уеб-ресурси от Интернет и на класовете за работа с e-mail в .NET Framework.

Автори на главата са Ивайло Христов и Георги Пенчев. Текстът широко използва лекцията на Ивайло Христов по същата тема.

Глава 19. Отражение на типовете (Reflection)

В глава 19 се представя понятието Global Assembly Cache (GAC) и отражение на типовете (reflection). Разглеждат се начините за зареждане на асембли. Демонстрира се как може да се извлече информация за типовете в дадено асембли и за членовете на даден тип. Разглеждат се начини за динамично извикване на членове от даден тип. Обяснява се как може да се създаде едно асембли, да се дефинират типове в него и асемблито да се запише във файл по време на изпълнение на програмата.

Автор на главата е Димитър Канев. Текстът е базиран на лекцията на Ивайло Христов по същата тема. Редактор е Светлин Наков.

Глава 20. Сериализация на данни

В глава 20 се разглежда сериализацията на данни в .NET Framework. Обяснява се какво е сериализация, за какво се използва и как се контролира процесът на сериализация. Разглеждат се видовете форматери (formatters). Обяснява се какво е XML сериализация, как работи тя и как може да се контролира изходният XML при нейното използване.

Автор на главата е Радослав Иванов. Текстът е базиран на лекцията на Михаил Стойнов по същата тема. Редактор е Светлин Наков.

Глава 21. Уеб услуги с ASP.NET

В глава 21 се разглеждат уеб услугите, тяхното изграждане и консумация чрез ASP.NET и .NET Framework. Обект на дискусия са основните технологии, свързани с уеб услугите, и причината те да се превърнат в стандарт за интеграция и междуплатформена комуникация. Представят се различни сценарии за използването им. Разглежда се програмният модел за уеб услуги в ASP.NET и средствата за тяхното изграждане, изпълнение и разгръщане (deployment). Накрая се дискутират някои често срещани проблеми и утвърдени практики при разработката на уеб услуги чрез .NET Framework.

Автори на главата са Стефан Добрев и Деян Варчев. В текста са използвани материали от лекцията на Светлин Наков по същата тема. Технически редактор е Мартин Кулов.

Глава 22. Отдалечено извикване на методи (Remoting)

В глава 22 се разглежда инфраструктурата за отдалечени извиквания, която .NET Framework предоставя на разработчиците. Обясняват се основите на Remoting технологията и всеки един от нейните компоненти: канали, форматери, отдалечени обекти и активация. Дискутират се разликите между различните типове отдалечени обекти. Обясняват се техният жизнен цикъл и видовете маршализация. Стъпка по стъпка се достига до създаването на примерен Remoting сървър и клиент. Накрая се представя един гъвкав и практичен начин за конфигуриране на цялата Remoting инфраструктура чрез конфигурационни файлове.

Автор на главата е Виктор Живков. В текста са използвани материали от лекцията на Светлин Наков. Редактори са Иван Митев и Светлин Наков.

Глава 23. Взаимодействие с неуправляван код

Глава 23 разглежда как можем да разширим възможностите на .NET Framework чрез употреба на предоставените от Windows приложни програмни интерфейси (API). Дискутират се средствата за извикване на функционалност от динамични Win32 библиотеки и на проблемите с преобразуването (маршализацията) между Win32 и .NET типовете.

Обръща се внимание на връзката между .NET Framework и COM (компонентният модел на Windows). Разглеждат се както извикването на COM обекти от .NET код, така и разкриването на .NET компонент като COM обект. Демонстрира се и технологията IJW за използване на неуправляван код от програми, написани на Managed C++.

Автор на главата е Мартин Кулов. Текстът е базиран на неговата лекция по същата тема. Технически редактор е Галин Илиев.

Глава 24. Управление на паметта и ресурсите

В глава 24 се разглежда писането на правилен и ефективен код по отношение използването на паметта и ресурсите в .NET Framework. В началото се прави сравнение на предимствата и недостатъците на ръчното и автоматичното управление на памет и ресурси. След това се разглежда по-обстойно автоматичното им управление с фокус най-вече върху системата за почистване на паметта в .NET (т. нар. garbage collector). Обръща се внимание на взаимодействието с нея и практиките, с които можем да й помогнем да работи възможно най-ефективно.

Автори на главата са Стоян Дамов и Димитър Бонев. Технически редактор е Светлин Наков.

Глава 25. Асемблита и разпространение (deployment)

В глава 25 се разглежда най-малката съставна част на .NET приложенията – асембли, различните техники за разпространение на готовия софтуерен продукт на клиентските работни станции и някои избрани техники за създаване на инсталационни пакети и капаните, за които трябва да се внимава при създаване на инсталационни пакети.

Автор на тази глава е Галин Илиев. В текста е използвана частично лекцията на Михаил Стойнов. Технически редактор е Светлин Наков.

Глава 26. Сигурност в .NET Framework

В глава 26 се разглежда как .NET Framework подпомага сигурността на създаваните приложения. Това включва както безопасност на типовете и защита на паметта, така и средствата за защита от изпълнение на нежелан код, автентикация и оторизация, електронен подпис и криптография. Разглеждат се технологиите на .NET Framework като Code Access Security, Role-Based Security, силно-именувани асемблита, цифрово подписване на XML документи (XMLDSIG) и други.

Автори на главата са Тодор Колев и Васил Бакалов. В текста е широко използвана лекцията на Светлин Наков по същата тема. Технически редактор е Светлин Наков.

Глава 27. Mono - свободна имплементация на .NET

В глава 27 се разглежда една от алтернативите на Microsoft .NET Framework – проектът с отворен код Mono. Обясняват се накратко начините за инсталиране и работа с Mono, използването на вградените технологии ASP.NET и ADO.NET, както и създаването на графични приложения. Дават се и няколко съвети и препоръки за писането на преносим код.

Автори на главата са Цветелин Андреев и Антон Андреев. Текстът е базиран на лекцията на Антон Андреев по същата тема. Технически редактор е Светлин Наков. Коректор е Соня Бибиликова.

Глава 28. Помощни инструменти за .NET разработчици

В глава 28 се разглеждат редица инструменти, използвани при разработката на .NET приложения. С тяхна помощ може значително да се улесни изпълнението на някои често срещани програмистки задачи. Изброените инструменти помагат за повишаване качеството на кода, за увеличаване продуктивността на разработка и за избягване на някои традиционни трудности при поддръжката. Разглеждат се в детайли инструментите .NET Reflector, FxCop, CodeSmith, NUnit (заедно с допълненията към него NMock, NUnitAsp и NUnitForms), log4net, NHibernate и NAnt.

Автори на главата са Иван Митев и Христо Дешев. Текстът е по техни авторски материали. Редактор е Светлин Наков.

Глава 29. Практически проект

В глава 29 се дискутира как могат да се приложат на практика технологиите, разгледани в предходните теми. Поставена е задача да се разработи един сериозен практически проект – система за запознанства в Интернет с възможност за уеб и GUI достъп.

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

При изготвяне на архитектурата приложението се разделя на три слоя – база от данни (която се реализира с MS SQL Server 2000), бизнес слой (който се реализира като ASP.NET уеб услуга) и клиентски слой (който се реализира от две приложения – ASP.NET уеб клиент и Windows Forms GUI клиент).

Ръководител на проекта е Ивайло Христов. Автори на проекта са: Ивайло Христов (отговорен за Windows Forms клиента), Тодор Колев и Ивайло Димов (отговорни за уеб услугата и базата данни) и Бранимир Ангелов (отговорен за ASP.NET уеб клиента). Инсталаторът на проекта е създаден от Галин Илиев. Технически редактори на кода са Мартин Кулов, Светлин Наков, Стефан Добрев и Деян Варчев.

Автори на текста са Ивайло Христов, Тодор Колев, Ивайло Димов и Бранимир Ангелов. Редактор на текста е Светлин Наков.

За използваната терминология

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

- По-голямата част от техническата документация за .NET Framework е на английски език (повечето книги и в частност MSDN Library) и затова е много важно читателите да знаят английския еквивалент на всеки използван термин.

- Много от използваните термини не са пряко свързани с .NET и са навлезли отдавна в програмисткия жаргон от английски език (например "дебъгвам", "компилирам" и "плъгин"). Тези термини ще бъдат изписвани най-често на кирилица.

- Някои термини (например "framework" и "deployment") са трудно преводими и трябва да се използват заедно с оригинала в скобки. В настоящата книга на места такива термини са превеждани по различни начини (според контекста), но винаги при първо срещане се дава и оригиналният термин на английски език.

Конвенция за кода

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

Константите пишем с главни букви

Примери:

private const int MAX_VALUE = 4096;

private const string INPUT_FILE_NAME = "input.xml";

Това е утвърдена практика, възприета от повечето програмисти на C, C++, Java и C#.

Член-променливите пишем с префикс "m"

Примери:

private Hashtable mUsersProfiles;

private ArrayList mUsers;

Тази конвенция не е стандартна, но тъй като Microsoft нямат официална препоръка по този въпрос, ние възприехме тази конвенция за именуване на член-променливите, за да ги отличаваме от останалите променливи. Префиксът "m" произхожда от думата "member" (член).

Параметрите на методите пишем с префикс "a"

Пример:

public void IsLoginValid(string aUserName, string aPassword)

{

// ...

}

Тази конвенция също не е стандартна, но ние я възприехме, за да можем лесно да отличаваме параметрите в методите от останалите променливи, което често пъти е много полезно. Префиксът "a" произхожда от думата "argument" (аргумент на метод).

Именуване на идентификатори

Възприели сме конвенция за именуване на идентификаторите, която е близка до официалните препоръки на Microsoft (за случаите, в които Microsoft са дали препоръки) и е съобразена с принципите за именуване на член-променливи и параметри, които вече разгледахме. Ето как изглежда тази конвенция:

Идентификатор	Стил	Пример
пространство от имена (namespace)	Pascal Case	System.Windows.Forms
тип (клас, структура, ...)	Pascal Case	TextWriter
интерфейс (interface)	Pascal Case, префикс "I"	ISerializable
изброен тип (enum type)	Pascal Case	FormBorderStyle
изброена стойност (enum value)	Pascal Case	FixedSingle
поле само за четене (read-only field)	Pascal Case	UserIcons
поле-константа (constant)	UPPERCASE	MAX_VALUE
свойство (property)	Pascal Case	BorderColor
събитие (event)	Pascal Case	SizeChanged
метод (method)	Pascal Case	ToString()
член-променлива (field)	Pascal Case, префикс "m"	mUserProfiles
статична член-променлива (static field)	Pascal Case, префикс "m"	mTotalUsersCount
параметър на метод (parameter)	Pascal Case, префикс "a"	aFileName
локална променлива (local variable)	Camel Case	currentIndex

Именуване на контроли

При именуване на контроли използваме Pascal Case и представка, която съответства на техния тип. Не слагаме префикс "m", когато контролата е член-променлива:

Контрола	Пример
Button	ButtonOk, ButtonCancel
Label	LabelCustomerName
TextBox	TextBoxCustomerName
Panel	PanelCustomerInfo
Image	ImageProduct

Конвенции за базата данни

Използваме множествено число за именуване на таблици (например Users, Countries, StudentsCourses, …). При имената на колоните в таблица използваме Pascal Case (например UserName, MessageSender, UserId и т.н.).

Служебните думи в езика SQL (например SELECT, CREATE TABLE, FROM, INTO, ORDER BY и др.) изписваме с главни букви.

Как възникна тази книга?

Историята на тази книга е дълга и интересна.

Няколко години след официалното излизане на .NET платформата, през 2002 г. .NET Framework вече беше навлязъл широко на пазара и много български фирми разработваха .NET приложения. Езикът C# и .NET платформата вече бяха добре познати сред софтуерните специалисти, но по университетите все още никой не преподаваше тези технологии.

В този момент в Софийски университет възникна курсът "Програмиране за платформа .NET".

Курсът по програмиране за платформа .NET в СУ (2002/2003 г.)

Курсът "Програмиране за платформа .NET" в Софийски университет беше организиран през летния семестър на учебната 2002/2003 г. от група студенти с изявен интерес към .NET технологиите, някои от които имаха вече натрупан сериозен практически опит като .NET разработчици.

Преподавателският екип беше в състав Светлин Наков (работещ тогава в Мусала Софт), Стоян Йорданов (работещ тогава в Рила Солюшънс), Георги Иванов (работещ тогава във WebMessenger) и Николай Недялков (работещ тогава в Информационно обслужване).

Курсът (http://www.nakov.com/dotnet/2003/) обхващаше всички основни технологии, свързани с .NET Framework. Интересът към него беше много голям. Над 300 студента преминаха обучението, което беше с обем 60 учебни часа. Много от тях след това започнаха професионалната си кариера като .NET програмисти.

По време на семестъра бяха разработени авторски учебни материали за повечето от темите, които по-късно бяха използвани при изготвянето на лекции по "Програмиране за .NET Framework", на които е базирана настоящата книга.

Проектът на Microsoft Research и БАРС

Две години по-късно Microsoft Research отправиха предложение към Софийски университет за участие в академичен проект за създаване на учебно съдържание и учебни материали по дисциплини, изучаването на които е базирано на технологиите на Microsoft.

Екипът на Светлин Наков, съвместно с Българска асоциация на разработчиците на софтуер и Софийски университет предложиха проект за разработка на изчерпателно учебно съдържание и провеждане на университетски курсове по "Програмиране за .NET Framework". Проектът беше одобрен и частично финансиран от Microsoft Research.

Така започна съставянето на учебните материали, върху които е базирана настоящата книга. За година и половина бяха изработени повече от 2000 PowerPoint слайда по 26 теми, съдържащи над 600 примера, около 200 демонстрации на живо и над 300 задачи за упражнения. Учебните материали са с много високо качество и предоставят задълбочена информация по всички по-важни технологии, свързани с програмирането с .NET Framework. По някои от темите лекциите се получиха значително по-добри от официалните учебни материали на Microsoft (т. нар. Microsoft Official Curriculum). Лекциите са достъпни за свободно изтегляне от сайта на книгата.

Курсът по програмиране за .NET Framework в СУ (2004/2005 г.)

По разработените вече учебни материали през зимния семестър на 2004/2005 г. беше проведен курс във Факултета по математика и информатика на Софийски университет с продължителност 90 учебни часа.

Курсът (http://www.nakov.com/dotnet/) беше организиран от Светлин Наков и неговия екип – Бранимир Гюров, Мартин Кулов, Георги Иванов, Михаил Стойнов и Ивайло Христов. Интересът към курса отново беше голям и стотици студенти избраха да преминат обучението. Мнозина от тях след това започнаха работа като .NET програмисти във водещи български софтуерни компании.

Няколко месеца след приключване на курса започна писането и на настоящата книга по материалите, използвани в лекциите.

Курсът по програмиране за .NET Framework в СУ (2005/2006 г.)

През зимния семестър на 2005/2006 г. във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски" отново се организира курс по .NET Framework (http://www.devbg.org/dotnetcourse/) с продължителност 90 учебни часа.

Преподавателският екип е съставен от представители на авторския колектив, разработил настоящата книга: Светлин Наков, Ивайло Христов, Михаил Стойнов, Галин Илиев, Васил Бакалов, Стефан Захариев, Радослав Иванов, Антон Андреев, Стефан Кирязов и Виктор Живков.

Курсът се провежда по официалните лекции и учебни материали, разработени по съвместния проект между Microsoft Research, Софийски университет и БАРС, които са достъпни за свободно изтегляне от сайта на курса.

Настоящата книга се използва като официален учебник в курса.

Проектът за настоящата книга

Първоначално идеята беше да се разпишат като текст изготвените вече лекции и да се компилира учебник за курсовете по програмиране за .NET Framework. По-късно проектът силно се разрасна и в него се включиха над 30 души. Появиха се допълнителни теми, появиха се и множество допълнения към обхванатите в лекциите теми.

Книгата е безплатна!

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

Екипът, реализирал идеята

Екипът, написал настоящата книга, е съставен от хора, които имат силен интерес към .NET технологиите и желаят безвъзмездно да споделят своя опит като участват в написването на една или няколко от темите. Някои от участниците в екипа са бивши студенти, посещавали курсовете по .NET Framework в Софийски университет, други са членове на Софийската .NET потребителска група (www.sofiadev.org), а трети – разработчици, които от някъде са научили за проекта. Всички автори, съавтори и редактори от екипа по разработката на книгата са програмисти с реален практически опит.

Участниците в проекта дадоха своя труд безвъзмездно, без да получат материални или други облаги, защото съзнаваха липсата на добра книга за .NET Framework на български език и имаха силно желание да помогнат на своите настоящи и бъдещи колеги да навлязат с много по-малко усилия в .NET технологиите.

Процесът на работа

Написването на книгата отне около 6 месеца. Екипът беше ръководен от Светлин Наков, който има богат опит с писането на статии, презентации и книги и притежава добри технически познания по .NET Framework. Екипът се събираше на всеки 2 седмици за да дискутира напредъка по задачите и проблемите, възникнали по време на работата по проекта.

Работата по всяка тема изискваше нейният автор да предава по 10-15 страници на всеки 2 седмици. Този подход доведе до намаляване на риска от закъснение на работата по темите, и позволи проблемите да бъдат идентифицирани и решавани още при възникването им. В крайна сметка проектът завърши успешно, макар и доста след планираните първоначално срокове.

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

За улесняване на съвместната работа бе използвана системата за екипна работа по проекти, предлагана свободно от портала sciforge.org. За целите на книгата в SciForge беше регистриран и използван проект "Книга за .NET Framework", който все още е публично достъпен от адрес http://sciforge.org/projects/dotnetbook/. Беше използвана системата за контрол на версиите Subversion, форумът и пощенският списък (mailing list), предлагани от SciForge.

За да се уеднаквят стиловете и форматирането във всички глави, беше разработено специално "ръководство за писателите", което дефинираше строги правила, свързани със стила на изказ, структурирането на текста, форматирането на кода, примерите, таблиците, схемите, картинките и т.н. Бяха разработени конвенции за кода, речник на преводните думи и други полезни стандарти. За всяка глава беше направен шаблон за MS Word 2003, в който авторите трябваше да пишат. Всички тези усилия силно ограничиха различията в стила и форматирането между отделните глави на книгата.

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

Авторският колектив

Авторският колектив се състои от над 30 души – автори, съавтори, редактори и други. Ще представим всеки от тях с по няколко изречения (подредбата е по азбучен ред).

Александър Русев

Александър Русев е програмист във фирма JCI (www.jci.com), където се занимава с разработка на софтуер за леки автомобили. Завършил е Технически университет – София, специалност компютърни системи и технологии. Александър се е занимавал и с разработка на софтуер за мобилни телефони. Професионалните му интереси включват Java технологиите и .NET платформата. Можете да се свържете с Александър по e-mail: [email protected].

Александър Хаджикръстев

Александър Хаджикръстев е софтуерен архитект със сериозен опит в областта на проектирането и разработката на уеб базирани системи и e-commerce приложения. Той е сътрудник и консултант на PC Magazine България (www.sagabg.net/PCMagazine/) и почетен член на Българската асоциация на софтуерните разработчици (www.devbg.org). Александър има дългогодишен опит като ръководител на софтуерни проекти във фирми, базирани в България и САЩ. Професионалните му интереси са свързани с проектирането и изграждането на .NET приложения, разработването на експертни системи и софтуер за управление и автоматизация на бизнес процеси.

Антон Андреев

Антон Андреев работи като ASP.NET уеб разработчик във фирма TnDSoft (www.tndsoft.com). Той се интересува се от всичко, свързано с компютрите и най-вече с .NET и Linux. Като ученик се е занимавал с алгоритми и е участвал в олимпиади по информатика. Завършил е математическа гимназия и езикова гимназия с английски език, а в момента е студент в специалност информатика във Факултета по математика и информатика (ФМИ) на Софийски университет "Св. Климент Охридски". Работил е и като системен администратор във ФМИ и сега продължава да подпомага проектите на факултета, разработвайки нови сайтове. Неговият личен сайт е достъпен от адрес: http://debian.fmi.uni-sofia.bg/~toncho/portfolio/. Можете да се свържете с Антон по e-mail: [email protected].

Бранимир Ангелов

Бранимир Ангелов е софтуерен разработчик във фирма Gugga (www.gugga.net) и студент във Факултета по Математика и информатика на Софийски университет "Св. Климент Охридски", специалност компютърни науки. Неговите професионални интереси са в областта на обектно-ориентирания анализ, моделиране и програмиране, уеб технологиите и в частност изграждането на RIA (Rich Internet Applications) и разработката на софтуер за мобилни устройства. Бранимир е печелил грамоти и отличия от различни състезания, както и първо място на Националната олимпиада по информационни технологии, на която е бил и жури година по-късно.

Васил Бакалов

Васил Бакалов е студент, последен курс, в Американския университет в България, специалност Информатика. Той е председател на студентския клуб по информационни технологии и е студент-консултант на Microsoft България за университета. В рамките на клуба се занимава с управление на проекти и консултации по изпълнението им. Като студент-консултант на Microsoft България Васил подпомага усилията на Microsoft да поддържа тясна връзка със студентите и да ги информира и обучава по най-новите й продукти и технологии. Васил работи и като сътрудник на PC Magazine България от няколко години и има редица статии и коментари в изданието. В университета той предлага и изготвя план за курс по практическо изучаване на роботика, като разширение на обучението по изкуствен интелект, който е одобрен и внедрен. Той работи и с няколко ИТ фирми, където изгражда решения, базирани на .NET платформата. Притежава професионална сертификация от Microsoft. Можете да се свържете с Васил по e-mail: [email protected].

Виктор Живков

Виктор Живков е софтуерен инженер в Интерконсулт България (www.icb.bg). В момента е студент в Софийски Университет "Св. Климент Охридски", специалност информатика. Професионалните му интереси са основно в областта на решенията, базирани на софтуер от Microsoft. Виктор има сериозен опит в работата с .NET Framework, Visual Studio .NET и Microsoft SQL Server. Той участва в проекти за различни информационни системи, главно за Норвегия. Членува в БАРС от 2005 година. За връзка с Виктор можете да използвате неговия e-mail: [email protected].

Деян Варчев

Деян Варчев е старши уеб разработчик във фирма Vizibility (www.vizibility.net). Неговите отговорности включват проектирането и разработката на уеб базирани приложения, използващи последните технологии на Microsoft, проучване на новопоявяващи се технологии и планиране на тяхното внедряване в производството, както и обучение на нови колеги. Неговите професионални интереси са свързани тясно с технологиите на Microsoft – .NET платформата, SQL Server, IIS, BizTalk и др. Деян е студент по информатика във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски".

Димитър Бонев

Димитър Бонев е софтуерен разработчик във фирма Formula Telecom Solutions (www.fts-soft.com). Той отговаря за разработването на уеб базирани приложения за корпоративни клиенти, както и за някои модули и инструменти, свързани с вътрешния процес на разработка във фирмата. Професионалните му интереси са насочени предимно към .NET платформата, методологията extreme programming и софтуерния дизайн. Димитър е завършил ВВВУ "Г. Бенковски", специалност компютърна техника. Той има богат опит в разработването на софтуерни решения, предимно с технологиите на Microsoft и Borland.

Димитър Канев

Димитър Канев е разработчик на софтуер във фирма Медсофт (www.medsoft.biz). Той е завършил Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност информатика. Професионалните му интереси са основно в областта на решенията, базирани на софтуер от Microsoft. Димитър има сериозен опит в работата с Visual Studio .NET, Microsoft SQL Server и ГИС системи. Работил е в проекти за изграждане на големи информационни системи, свързани с ГИС решения, и експертни системи за медицински лаборатории.

Галин Илиев

Галин Илиев е ръководител на проекти и софтуерен архитект в българския офис на Technology Services Consulting Group (www.wordassist. com). Галин е участвал в проектирането и разработването на големи информационни системи, Интернет сайтове с управление на съдържанието, допълнения и интеграция на MS Office със системи за управление на документи. Той притежава степен бакалавър по мениджмънт и информационни технологии, а също и сертификация MCSD за Visual Studio 6.0 и Visual Studio .NET. Той има сериозен опит с работата с Visual Studio .NET, MS SQL Server, MS IIS и MS Exchange. Личният му сайт е достъпен от адрес www.galcho.com, а e-mail адресът му е [email protected].

Георги Пенчев

Георги Пенчев е софтуерен разработчик във фирма Symex България (www.symex.bg), където отговаря за разработка на финансово ориентирани графични Java приложения и на Интернет финансови портали с Java и PHP. Участвал е в изграждането на продукти за следене и обработка на борсови индекси и котировки за Българската фондова борса. Георги е студент по информатика във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски". Професионалните и академичните му интереси са насочени към Java и .NET технологиите, биоинформатикатa, теоретичната информатика, изкуствения интелект и базите от знания. През 2004 и 2005 г. е асистент в курса по "Информационни технологии" за студенти с нарушено зрение и в практическия курс по "Структури от данни и програмиране" в Софийски университет. Можете да се свържете с Георги по e-mail: [email protected].

Иван Митев

Иван Митев е софтуерен разработчик във фирма EON Technologies (www.eontechnologies.bg). Той е завършил Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност информатика. Иван е участвал в проектирането и реализацията на множество информационни системи, основно ГИС решения. Професионалният му опит е в разработки предимно с продукти и технологии на Microsoft. Основните интереси на Иван са в създаването на качествени и ефективни софтуерни решения чрез използването на подходящи практики, технологии и инструменти. Технически уеблог, който той поддържа от началото на 2004 година, е с акцент върху .NET програмирането и е достъпен на адрес http://immitev.blogspot.com. Можете да се свържете с Иван по e-mail: [email protected].

Ивайло Димов

Ивайло Димов е софтуерен разработчик във фирма Gugga (www.gugga.com). Неговите интереси са в областта на обектно-ориентираното моделиране, програмиране и анализ, базите от данни, уеб приложенията и приложения, базирани на Microsoft .NET Framework. В момента Ивайло е студент във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност Компютърни науки. Той е сертифициран от Microsoft разработчик и е печелил редица грамоти и отличия от състезания по програмиране. През 2004 г. е победител в Националната олимпиада по информационни технологии и е участвал в журито на същата олимпиада година по-късно.

Ивайло Христов

Ивайло Христов е преподавател в Софийски университет "Св. Климент Охридски", където води курсове по "Програмиране за .NET Framework", "Качествен програмен код", "Увод в програмирането", "Обектно-ориентирано програмиране" и "Структури от данни в програмирането". Неговите професионални интереси са в областта на .NЕТ технологиите и Интернет технологиите. Като ученик Ивайло е участник в редица национални състезания и конкурси по програмиране и е носител на престижни награди и отличия. Той участва в екип, реализирал образователен проект на Microsoft Research в областта на .NET Framework. Личният сайт на Ивайло е достъпен от адрес: www.ivaylo-hristov.net.

Лазар Кирчев

Лазар Кирчев е завършил Факултета по математика и информатика на Софийски университет "Св. Климент Охридски" и в момента е дипломант в специализация "Информационни системи". Той работи в Института за паралелна обработка на информацията към БАН по съвместен проект между Факултета по математика и информатика и БАН за изграждане на grid система. Неговите интереси включват .NET платформата, grid системите и базите от данни.

Манол Донев

Манол Донев е софтуерен разработчик във фирма telerik (www.telerik. com). Той е част от екипа, който разработва уеб-базираната система за управление на съдържание Sitefinity (www.sitefinity.com). Манол е студент във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност Информатика. Неговите професионални интереси обхващат най-вече .NET технологиите (в частност ASP.NET уеб приложения, XML и уеб услуги). Можете да се свържете с Манол по e-mail: [email protected].

Мартин Кулов

Мартин Кулов е изпълнителен директор на фирма КодАтест (www. codeattest.com), в която разработва системи за управление на качеството и автоматизация на софтуерното производство. Той има дългогодишен професионален опит като разработчик и ръководител в различни по големина проекти за частния и обществения сектор. Интересите му са в областта на продуктите и технологиите на Microsoft. Мартин е сертифициран от Microsoft разработчик по програмите MCSD и MCSD.NET (Charter Member). Той е магистър инженер при Факултета по комуникационна техника и технологии на Технически университет – София. През 2004 г. той участва като лектор в курсовете "Програмиране за .NET Framework" и "Качествен програмен код" в Софийски университет "Св. Климент Охридски". Мартин е лектор и на семинари на Microsoft, свързани с .NET технологиите и разработката на софтуер. Той е почетен член на Българската асоциация на разработчиците на софтуер и член на SofiaDev .NET потребителската група. Можете да се свържете с него по e-mail: [email protected] или чрез неговия личен уеблог: http://www. codeattest.com/blogs/martin/.

Михаил Стойнов

Михаил Стойнов е софтуерен разработчик във фирма MPS (www.mps.bg), която е подизпълнител на Siemens A.G. Той се занимава професионално с програмиране за платформите Java и .NET Framework от няколко години. Участва като лектор в преподавателския екип на курсовете "Програмиране за .NEТ Framework" и "Качествен програмен код". Той е студент-консултант на Майкрософт България за Софийски университет през последните 2 години и подпомага разпространението на най-новите продукти и технологии на Microsoft в университета. Михаил е бил лектор на международни конференции за ГИС системи. Интересите му обхващат разработка на уеб приложения, приложения с бази от данни, изграждане на сървърни системи и участие в академични дейности.

Моника Алексиева

Моника Алексиева е софтуерен разработчик във фирма Солвер / Мидакс (www.midax.com). В момента следва специалност информатика във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски". Моника има професионален опит в разработката за .NET Framework с езика C# и е сертифициран от Microsoft разработчик за .NET платформата. Нейните интереси са в областта на технологиите за изграждането на графичен потребителски интерфейс и разработката на приложения за мобилни устройства. През 2004 година Моника е асистент по "Структури от Данни" в Софийски университет.

Николай Недялков

Николай Недялков е президент на Асоциацията за информационна сигурност (www.iseca.org) която е създадена с цел прилагане на най-добрите практики за осигуряване на информационната сигурност на национално ниво и при извършването на електронен бизнес. Николай е професионален разработчик на софтуер, консултант и преподавател с дългогодишен опит. Той е автор на статии и лектор на множество конференции и семинари в областта на софтуерните технологии и информационна сигурност. Преподавателският му опит се простира от асистент по "Структури от данни в програмирането", "Обектно-ориентирано програмиране със C++" и "Visual C++" до лектор в курсовете "Мрежова сигурност", "Сигурен програмен код", "Интернет програмиране с Java", "Конструиране на качествен програмен код", "Програмиране за платформа .NET" и "Разработка на приложения с Java". Интересите на Николай са концентрирани върху техническата и бизнес страната на информационната сигурност, Java и .NET технологиите и моделирането и управлението на бизнес процеси в големи организации. Николай има бакалавърска степен от Факултета по математика и информатика на Софийски университет "Св. Климент Охридски". Като ученик е дългогодишен състезател по програмиране, с редица призови отличия. През 2004 г. е награден от Президента на България Георги Първанов за приноса му към развитието на информационните технологии и информационното общество. Той е почетен член на БАРС. Личният му сайт е достъпен от адрес: www.nedyalkov.com.

Панайот Добриков

Панайот Добриков е софтуерен архитект в SAP A.G., Java Server Technology (www.sap.com), Германия и е отговорен за координацията на софтуерните разработки в SAP Labs България. Той е завършил Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност информатика. Панайот е дългогодишен участник (като състезател и ръководител) в ученически и студентски състезания по програмиране и е носител на много престижни награди в страната и чужбина. Той е автор на книгите "Програмиране = ++Алгоритми;" (www. algoplus.org) и "Java Programming with SAP Web Application Server", както и на десетки научно-технически публикации. През периода 2001-2003 води курсовете "Проектиране и анализ на компютърни алгоритми" и "Прагматика на обектното програмиране" в Софийски университет. Можете да се свържете с Панайот по e-mail: [email protected].

Преслав Наков

Преслав Наков е аспирант по изкуствен интелект в Калифорнийския университет в Бъркли (www.berkeley.edu), САЩ. Неговият професионален опит включва шестгодишна работа като софтуерен разработчик във фирмите Комсофт (www.comsoft.bg) и Рила Солюшънс (www.rila.bg). Интересите му са в областта на компютърната лингвистика и биоинформатикатa. Преслав получава магистърската си степен по информатика от Софийски университет "Св. Климент Охридски". Той е носител е на бронзов медал от Балканиада по информатика, заемал призови места в десетки национални състезания по програмиране като ученик и студент. Състезател е, а по-късно и треньор на отбора на Софийския университет, участник в Световното междууниверситетско състезание по програмиране (ACM International Collegiate Programming Contest). Той е асистент в множество курсове във Факултета по математика и информатика на Софийски университет, лектор-основател на курсовете "Проектиране и анализ на компютърни алгоритми" и "Моделиране на данни и проектиране на бази от данни". Преслав е автор на книгите "Основи на компютърните алгоритми" и "Програмиране = ++Алгоритми;" (www.algoplus.org). Той има десетки научни и научнопопулярни публикации в престижни международни и национални издания. Той е първият носител на наградата "Джон Атанасов" за принос към развитието на информационните технологии и информационното общество, учредена от президента на България Георги Първанов.

Радослав Иванов

Радослав Иванов е софтуерен разработчик във фирма Медсофт (www. medsoft.biz) и студент в специалност информатика във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски". Професионалните му интереси са в областта на информационната сигурност и продуктите и технологиите на Microsoft.

Светлин Наков

Светлин Наков е директор на Националната академия по разработка на софтуер (http://academy.devbg.org), където обучава софтуерни специалисти за практическа работа в ИТ индустрията. Той е хоноруван преподавател по съвременни софтуерни технологии в Софийски университет "Св. Климент Охридски", където води курсове по "Проектиране и анализ на компютърни алгоритми", "Интернет програмиране с Java", "Мрежова сигурност", "Програмиране за .NET Framework" и "Качествен програмен код". Светлин има сериозен професионален опит като софтуерен разработчик и консултант. Неговите интереси обхващат Java технологиите, .NET платформата и информационната сигурност. Той е завършил бакалавърската и магистърската си степен във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски". Като ученик и студент Светлин е победител в десетки национални състезания по програмиране и е носител на 4 медала от международни олимпиади по информатика. Той има десетки научни и технически публикации, свързани с разработката на софтуер, в български и чуждестранни списания и е автор на книгите "Интернет програмиране с Java" и "Java за цифрово подписване на документи в уеб". През 2003 г. той е носител на наградата "Джон Атанасов" на фондация Еврика. През 2004 г. получава награда "Джон Атанасов" от президента на България Георги Първанов за приноса му към развитието на информационните технологии и информационното общество. Светлин е един от учредителите на Българската асоциация на разработчиците на софтуер (www.devbg.org) и понастоящем неин председател.

Стефан Добрев

Стефан Добрев е старши уеб разработчик във фирма Vizibility (www.vizibility.net). Той отговаря за голяма част от .NET продуктите, разработвани в софтуерната компания, в това число уеб базирана система за изграждане на динамични сайтове и управление на тяхното съдържание, уеб система за управление на контакти и др. Негова отговорност е и внедряването на утвърдените практики и методологии за разработка на софтуер в производствения процес. Професионалните му интереси са насочени към уеб технологиите, в частност ASP.NET, XML уеб услугите и цялостната разработка на приложения, базирани на .NET Framework. Стефан следва информатика във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски".

Стефан Кирязов

Стефан Кирязов е софтуерен разработчик във фирма Verix (www.verix.bg). Той се занимава професионално с разработка на .NET решения за бизнеса и държавната администрация. Опитът му включва изграждане на уеб и настолни приложения с технологии на Microsoft, а също и Java и Oracle. Завършил е Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност информатика. Неговите професионални интереси включват архитектура, дизайн и методологии за разработка на големи корпоративни приложения. За контакти със Стефан можете да използвате неговия e-mail: [email protected].

Стефан Захариев

Стефан Захариев работи като софтуерен разработчик в Интерконсулт България (www.icb.bg), където е отговорен за създаването на инструменти за автоматизиране на процеса на разработка. Той има дългогодишен опит в създаването на ERP системи, който натрупва при работата си в различни фирми в България. Основните му интереси са свързани със системите за управление на бази от данни, платформата .NET, ORM инструментите, J2ME, както и Borland Delphi. При завършването си на средното образование в "Технологично училище – Електронни системи", печели отличителна награда за цялостни постижения. През 2005 г. завършва "Технически университет – София", където се дипломира като бакалавър във факултета по "Компютърни системи и управление". Той членува в БАРС и в Софийската .NET потребителска група Можете да се свържете със Стефан по e-mail: [email protected].

Стоян Дамов

Стоян Дамов е софтуерен консултант, пич, поет и революционер. Можете да се свържете с него по e-mail: [email protected] или от неговия личен сайт: http://spaces.msn.com/members/stoyan/.

Тодор Колев

Тодор Колев е софтуерен разработчик в Gugga (www.gugga.com) и студент във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност Информатика. Неговите професионални интереси са в областта на обектно-ориентирания анализ, моделиране и програмиране, уеб технологиите, базите данни и RIA (Rich Internet Applications). Тодор е дългогодишен участник в състезания по информатика и информационни технологии, печелил редица грамоти и отличия, както и сребърен медал на международна олимпиада по информационни технологии. Той е носител на първо място от националната олимпиада по информационни технологии и е участвал в журито на същата олимпиада година по-късно. Тодор има множество разработки в сферата на уеб технологиите и е участвал в изследователски екип в Масачузетският технологичен институт (MIT). Той е сертифициран Microsoft специалист.

Христо Дешев

Христо Дешев е разработчик на ASP.NET компоненти във фирма telerik (www.telerik.com). Той е завършил Американския университет в България, специалност информатика. Основните му интереси са в областта на подобряването на процеса на разработка на софтуер. Той е запален привърженик на Agile методологиите, основно на Extreme Programming (XP). Професионалният му опит е предимно в разработката на решения с кратък цикъл за обратна връзка, високо покритие от тестове и почти пълна автоматизация на всички нива от работния процес.

Христо Радков

Христо Радков е управител на фирма за софтуерни консултантски услуги Calisto ID (www.calistoid.com). Той е бакалавър от английската специалност "Manufacturing Engineering" в Технически Университет – София и магистър по информационни и комуникационни технологии във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски". Христо има дългогодишен опит с различни сървъри за бази от данни и сериозен опит с различни технологии на Microsoft, Borland, Sun и Oracle. Участник и ръководител е в проекти за изграждане на няколко големи и няколко по-малки информационни системи, динамични Интернет сайтове и др. Под негово ръководство е създаден най-успешния складово-счетоводен софтуер за фармацевтични предприятия в страната. Като ученик Христо има множество участия и награди от олимпиади по математика в страната и чужбина.

Цветелин Андреев

Цветелин Андреев е софтуерен разработчик във фирма Komero Technologies (www.komero.net). Той отговаря основно за UNIX базираните решения и за модули, свързани с вътрешния процес на разработка. В момента Цветелин е студент във Факултета по математика и информатика на Софийски университет "Св. Климент Охридски" и е професионално сертифициран от Sun. Неговите интереси са основно в областта на Java и UNIX технологиите, но обхващат и области от .NET платформата, изкуствен интелект, мрежова сигурност, анализ на изисквания, софтуерни архитектури и дизайн. Личният сайт на Цветелин е достъпен от адрес: www.flowerlin.net.

Явор Ташев

Явор Ташев е софтуерен разработчик във фирма TND Soft (www.tndsoft.com). Той е завършил Факултета по математика и информатика на Софийски университет "Св. Климент Охридски", специалност информатика. Участвал е в разработката на големи корпоративни сайтове и комуникационни системи, базирани на технологиите и платформите на Microsoft. Интересите му са насочени към .NET платформата, Java и изкуствения интелект. Професионалният му опит е свързан предимно с .NET Framework, Visual Studio .NET, Microsoft SQL Server и Microsoft Internet Information Server.

Благодарности

Настоящата книга стана реалност благодарение на много хора и няколко организации, които помогнаха и допринесоха за проекта. Нека изкажем своята благодарност и уважение към тях.

Светлин Наков

На първо място трябва да благодарим на главния организатор и ръководител на проекта, Светлин Наков, който успя да мотивира над 30 души да участват в начинанието и успя да ги ръководи успешно през всичките месеци на работата по проекта. Той успя да реализира своята идея за създаване на чисто българска книга за програмиране с .NET Framework най-вече благодарение на всички доброволни участници, които дариха своя труд за проекта и отделиха от малкото си свободно време за да споделят своите знания и опит безвъзмездно, за каузата.

Авторският колектив

Авторският колектив е наистина главният виновник за съществуването на тази книга. Текст с такъв обем и такова качество не може да бъде написан от един или двама автора за по-малко от няколко години, а до тогава информацията може вече да остаряла.

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

Българска асоциация на разработчиците на софтуер

Проектът получи силна подкрепа от Българската асоциация на разработчиците на софтуер (БАРС), тъй като е в синхрон с нейните цели и идеи.

БАРС официално държи правата за издаване и разпространение на книгата в хартиен вид, но няма право да реализира печалба от тази дейност. Асоциацията чрез своите контакти успя да намери финансиране за отпечатването на книгата, както и хостинг за нейния уеб сайт и форум.

Microsoft Research

В ранните си фази, когато бяха изготвени лекциите за курса "Програмиране за .NET Framework", проектът получи подкрепа и частично финансиране от Microsoft Research. Ако не беше тази подкрепа, вероятно нямаше да се стигне до създаването на лекциите и до написването на книгата.

SciForge.org

Порталът за организиране на работата в екип SciForge.org даде своя принос към проекта, като предостави среда за съвместна работа, включваща система за контрол над версиите, форум, пощенски списък (mailing list) и някои други средства за улеснение на работата.

Благодарностите са отправени главно към създателя на портала и негов главен администратор Калин Наков (www.kalinnakov.com), който указваше редовно съдействие в случай на технически проблеми.

Софийски университет "Св. Климент Охридски"

Факултетът по математика и информатика (ФМИ) на Софийски университет "Св. Климент Охридски" подпомогна проекта главно в началната му фаза, като подкрепи предложението на преподавателския екип от курса "Програмиране за платформа .NET" за участие в конкурса на Microsoft Research.

Благодарностите са отправени към ст. ас. Елиза Стефанова (която оформи изключително убедително текста на предложението за проекта към Microsoft Research) и доц. Магдалина Тодорова (която пое ролята на административен ръководител при взаимоотношенията с Microsoft).

По-късно, когато проектът на MS Research приключи и започна работата по настоящата книга, ФМИ предостави зали и техника за провеждане на регулярните срещи на авторския колектив.

telerik

Софтуерната компания telerik (www.telerik.com) подкрепи проекта чрез осигуряване на финансиране за отпечатване на книгата на хартия. Изказваме благодарности от името на целия авторски колектив.

Други

Изказваме благодарности още към:

- Георги Иванов, ръководител на проекти във фирма Sciant (www.sciant.com), участник в преподавателския екип на курсовете по "Програмиране за .NET Framework". Участник в създаването на лекциите, по които е изградена настоящата книга.

- Стоян Йорданов, софтуерен инженер в Microsoft Corporation, Redmond (www.microsoft.com), участник в преподавателския екип на курсовете по "Програмиране за .NET Framework". Участник в създаването на лекциите, по които е изградена настоящата книга.

- Бранимир Гюров, частичен съавтор на една от главите на книгата, участник в преподавателския екип на курса "Програмиране за .NET Framework". Участник в създаването на лекциите, на които се основава настоящата книга.

- Невена Партинова, графичен дизайнер. Благодарности за изготвянето на корицата на книгата и за цялото търпение по време на продължителните дискусии за графичния дизайн и цветовата гама.

- Михаил Балабанов, преводач и автор на спецификации за превод на софтуер, участник в превода на OpenOffice.org. Благодарности за помощта при превода на някои технически термини.

- Никола Касев, взел участие при създаването на лекциите, по които е изградена настоящата книга.

- Свилена Момова, частичен съавтор на една от главите на книгата.

- Веселин Райчев, частичен съавтор на една от главите на книгата.

Сайтът на книгата

Официалният уеб сайт на книгата "Програмиране за .NET Framework" е достъпен от адрес: http://www.devbg.org/dotnetbook/. От него можете да изтеглите цялата книга в електронен вид, лекциите, на които тя е базирана, както и сорс кода на практическия проект от глава 29, за който има специално изготвена инсталираща програма.

Към книгата е създаден и дискусионен форум, който се намира на адрес: http://www.devbg.org/forum/index.php?showforum=30. В него можете да дискутирате всякакви технически и други проблеми, свързани с книгата, да отправяте мнения и коментари и да задавате въпроси към авторите.

Лиценз

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

Общи дефиниции

1. Настоящият лиценз дефинира условията за използване и разпространение на комплект учебни материали и книга по "Програмиране за .NET Framework", разработени от екип под ръководството на Светлин Наков (www.nakov.com) с подкрепата на Българска асоциация на разработчиците на софтуер (www.devbg.org) и Microsoft Research (research.microsoft.com).

2. Учебните материали се състоят от:

- презентации;

- примерен сорс код;

- демонстрационни програми;

- задачи за упражнения;

- книга (учебник) по програмиране за .NET Framework с езика C#.

3. Учебните материали са достъпни за свободно изтегляне при условията на настоящия лиценз от официалния сайт на проекта:

http://www.devbg.org/dotnetbook/

4. Автори на учебните материали са лицата, взели участие в тяхното изработване. Всеки автор притежава права само над продуктите на своя труд.

5. Потребител на учебните материали е всеки, който по някакъв начин използва тези материали или части от тях.

Права и ограничения на потребителите

1. Потребителите имат право:

- да използват учебните материали или части от тях за всякакви цели, включително да ги да променят според своите нужди и да ги използват при извършване на комерсиална дейност;

- да използват сорс кода от примерите и демонстрациите, включени към учебните материали или техни модификации, за всякакви нужди, включително и в комерсиални софтуерни продукти;

- да разпространяват безплатно непроменени копия на учебните материали в електронен или хартиен вид;

- да разпространяват безплатно оригинални или променени части от учебните материали, но само при изричното споменаване на източника и авторите на съответния текст, програмен код или друг материал.

2. Потребителите нямат право:

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

- да премахват настоящия лиценз от учебните материали.

Права и ограничения на авторите

1. Всеки автор притежава неизключителни права върху продуктите на своя труд, с които взима участие в изработката на учебните материали.

2. Авторите имат право да използват частите, изработени от тях, за всякакви цели, включително да ги изменят и разпространяват срещу заплащане.

3. Правата върху учебните материали, изработени в съавторство, са притежание на всички съавтори заедно.

4. Авторите нямат право да разпространяват срещу заплащане учебни материали или части от тях, изработени в съавторство, без изричното съгласие на всички съавтори.

Права и ограничения на БАРС

Ръководството на Българска асоциация на разработчиците на софтуер (БАРС) има право да разпространява учебните материали или части от тях (включително модифицирани) безплатно или срещу заплащане, но без да реализира печалба от продажби.

Права и ограничения на Microsoft Research

Microsoft Research има право да разпространява учебните материали или части от тях по всякакъв начин – безплатно или срещу заплащане, но без да реализира печалба от продажби.

Светлин Наков,

24.09.2005 г.

Глава 1. Архитектура на платформата .NET и .NET Framework

Необходими знания

- Познания по програмиране

- Езици за програмиране

- Среди за разработка на софтуер

Съдържание

- Какво е .NET?

- Архитектура на платформата Microsoft .NET

- Какво е .NET Framework?

- Архитектура на .NET Framework

- Common Language Runtime (CLR)

- Управляван код

- Междинен език IL

- Модел за изпълнение на IL кода

- Асемблита и метаданни

- .NET приложения

- Домейни на приложението

- Common Language Specification (CLS), Common Type System (CTS)

- Common Language Infrastructure (CLI) и интеграцията на различни езици

- Framework Class Library

- Интегрирана среда за разработка Visual Studio .NET

В тази тема ...

В настоящата тема ще представим платформата .NET, която въплъщава визията на Microsoft за развитието на информационните и софтуерните технологии, след което ще разгледаме средата за разработка и изпълнение на .NET приложения Microsoft .NET Framework. Ще обърнем внимание на управлявания код, на езика IL, на общата среда за контролирано изпълнение на управляван код (Common Lnaguage Runtime) и на модела на компилация и изпълнение на .NET кода. Ще разгледаме още Common Language Specification (CLS), Common Type System (CTS), Common Language Infrastructure (CLI), интеграцията на различни езици, библиотеката от класове Framework Class Library и интегрираната среда за разработка Visual Studio .NET.

Какво представлява платформата .NET?

Microsoft дефинират платформата .NET като съвкупност от технологии, които свързват хората с информацията – навсякъде, по всяко време, от всяко устройство. Това определение звучи като маркетингова пропаганда, но .NET е не само технология, тя е и идеология. Платформата въплъщава визията на Microsoft, че информацията трябва да бъде максимално достъпна за хората.

.NET платформата осигурява стандартизирана инфраструктура за разработка, използване, хостинг и интеграция на .NET приложения и XML уеб услуги, базирана на .NET сървърите на Microsoft, средствата за разработка (.NET Framework и Visual Studio .NET), идеологията на smart клиентите и т. нар. .NET Building Block Services.

Визията на Microsoft

Визията на Microsoft за .NET е да създадат платформа, която да може да обединява хетерогенна инфраструктура от сървъри, да интегрира бизнес процесите на различни компании по стандартен начин, и да предоставя на потребителите достъп до информацията, която им е нужна, по всяко време, от всяко място и от всяко устройство. Както ще видим по-нататък, Microsoft са направили голяма крачка напред към реализирането на тази визия, като са поставили една стабилна технологична основа за разработка и изпълнение на приложения – Microsoft .NET Framework.

Разграничайвате понятията "платформа .NET" и ".NET Framework"!

.NET платформата е визията на Microsoft за развитието на технологиите и осигурява глобална инфраструктура за реализацията на тази визия.

.NET Framework е само част от .NET платформата – тази част, която е насочена към разработчиците на софтуер. Тя осигурява среда за разработка и контролирано изпълнение на .NET приложения и предоставя програмен модел и библиотеки от класове за разработка, независима от езиците за програмиране.

Имайте предвид, че много често под .NET се подразбира не платформата .NET, а средата .NET Framework, например ".NET език", ".NET приложение" и т. н. В настоящата книга също ще подразбираме под .NET не .NET платформата, а .NET Framework.

Архитектура на .NET платформата

Платформата .NET обединява в себе си четири технологични и идеологически компонента: инфраструктурата от сървъри .NET Enterprise Servers, средствата за разработка .NET Framework и Visual Studio .NET 2003, глобалните услуги .NET Building Block Services и идеологията .NET Smart Clients:

Всеки един от изброените компоненти на .NET платформата е достатъчно обемна тема, за да й се посвети цяла отделна книга, но нашата цел е само да се запознаем накратко с посочените технологии и идеологии, без да навлизаме в подробности. Нека сега ги разгледаме една по една.

.NET Enterprise Servers

.NET Enterprise Servers предоставят сървърната инфраструктура на .NET платформата и същевременно среда за изпълнение, управление и интеграция на XML уеб услуги.

Ключови характеристики

Ключовите характеристики на .NET Enterprise сървърите са:

- Силна поддръжка на XML – всички .NET сървъри използват широко XML стандарта за представяне и обмяна на информация.

- Висока надеждност – ключова характеристика, изключително важна за бизнеса.

- Добра скалируемост – възможност за поемане на огромно натоварване при необходимост.

- Оркестрация на бизнес процесите в приложенията и услугите (business process orchestration) – дава се възможност за схематично дефиниране на работните процеси по утвърдени стандарти (като BPEL) и контролираното им изпълнение, наблюдение и управление.

- Повишена сигурност – сигурността е основна архитектурна концепция при .NET сървърите.

- Лесно управление – леснота за администриране, настройка, наблюдение и управление на работата на сървърите.

По-важните сървърни продукти

Microsoft разработват сървърни продукти от много години и в момента предлагат цяло семейство от специализирани сървъри, насочени към различни бизнес нужди. Ще дадем съвсем кратко описание на най-важните от тях:

- Microsoft Windows Servers Family – представлява фамилия сървърни операционни системи (като Windows 2000 Server и Windows 2003 Server).

- Microsoft Internet Information Server – представлява уеб сървър, който е част от Windows. Служи за хостинг на уеб сайтове със статично и динамично съдържание.

- Microsoft SQL Server – служи за управление на релационни бази от данни, многомерни данни и XML.

- Microsoft BizTalk Server – използва се за интеграция и оркестрация на бизнес процеси, услуги и системи.

- Microsoft Exchange – позволява координация на съвместната работа в организации. В частност осигурява поддръжката на пощенски услуги (e-mail).

- Microsoft SharePoint Portal Server – позволява сътрудничество и споделяне на информация в реално време. Улеснява конкурентната работа с общи документи и работата в екип.

- Microsoft Host Integration Server – позволява интеграция на стари системи.

- Microsoft Application Center – осигурява хостинг, управление и мониторинг на критични за бизнеса приложения.

- Microsoft Content Management Server – служи за изграждане, поддръжка и управление на уеб съдържание.

- Microsoft Mobile Information Server – позволява интеграция с мобилни приложения.

- Microsoft Internet Security and Acceleration Server – контрол и защита на връзката с Интернет. Предоставя защитна стена (firewall) с възможност за филтриране и анализ на трафика на различни нива.

- Microsoft Commerce Server – използва се за реализация на приложения за електронна търговия.

.NET Framework и Visual Studio .NET 2003

.NET Framework е софтуерна платформа за разработка и изпълнение на .NET приложения. Тя представлява предоставя програмен модел и стандартна библиотека с класове за разработка на приложения и унифицирана среда за изпълнение на управляван код. Поддържа различни езици за програмиране и позволява тяхната съвместна работа.

.NET Framework съществува в два варианта:

- .NET Framework – пълна версия.

- .NET Compact Framework – съкратена версия за изпълнение върху мобилни устройства. Създадена е специално за устройства с ограничени хардуерни ресурси.

Visual Studio .NET 2003 представлява цялостна интегрирана среда за разработка на .NET приложения. Позволява създаване на различни видове приложения, писане на програмен код, изпълнение и дебъгване на приложения, изграждане на потребителски интерфейс и др. VS.NET предоставя единна среда за всички технологии и за всички програмни езици, поддържани стандартно от .NET Framework (C#, VB.NET, C++ и J#).

.NET Building Block Services

.NET Building Block Services са съвкупност от XML уеб услуги, насочени към крайния потребител. Основната им задача е да осигуряват персонализиран достъп до данните на даден потребител по всяко време и от всякакво устройство. За целта се използват отворени стандарти и протоколи за комуникация.

.NET Building Block Services са създадени с цел да позволяват лесна интеграция с други услуги и приложения и да позволяват връзка между тях. Ето няколко области, в които има изградени такива Building Block услуги:

- автентикация – на базата на .NET Passport

- доставка на съобщения

- съхранение на лични потребителски данни – документи, контакти, електронна поща, календар, любими сайтове и други

- съхранение на настройки на приложения, които потребителят използва.

.NET Smart Clients

Smart clients представлява архитектурна концепция, която позволява изграждането на клиентски приложения, които:

- предоставят гъвкав потребителски интерфейс (за разлика от уеб приложенията и WAP приложенията)

- консумират XML уеб услуги (чрез които си осигуряват връзка с останалия свят и обменят данни със сървърите, които съхраняват и обработват техните данни)

- могат да работят в online и offline режим (като синхронизират данните си когато са online)

- имат възможност да се самообновяват (и това може да става автоматично, с минимални усилия от страна на потребителя).

Смарт клиентите предоставят алтернатива на клиент-сървър приложенията и уеб приложенията. Като концепция те не са непременно обвързани с .NET. Има, например, реализация на smart клиент архитектури, базирани на Java платформата.

.NET платформата предоставя специализирана инфраструктура, която подпомага и улеснява реализацията на smart client приложения.

.NET smart клиентите работят както върху обикновени настолни компютри, така и върху различни преносими устройства: мобилни телефони, hand held устройства, вградени системи и т. н.

Основната им задача е да предоставят достъп до информацията, нужна на потребителя, навсякъде, по всяко време и във вид, удобен за потребителя.

.NET Framework и неговия вариант за мобилни приложения .NET Compact Framework предлагат възможности за разработка на smart client приложения за много разнообразни устройства.

Какво е .NET Framework?

До момента направихме преглед на .NET платформата и разгледахме компонентите, от които тя се състои. Сега ще разгледаме в детайли .NET Framework, неговата архитектура и модела за изпълнение на приложения, който тя използва.

.NET Framework e среда за разработка и изпълнение на приложения за .NET платформата. Тя предоставя програмен модел, библиотеки от типове и единна инфраструктура за разработка на приложения и поддържа различни езици за програмиране.

Приложенията, базирани на .NET Framework, се компилират до междинен код (на езика IL) и се изпълняват контролирано от средата за изпълнение на .NET Framework. Компилираният .NET код се нарича още управляван код и може да работи без да се прекомпилира върху различни платформи, за които има имплементация за .NET Framework (Windows, Linux, FreeBSD).

Компоненти на .NET Framework

Можем да разделим .NET Framework на два основни компонента:

- Common Language Runtime (CLR) – средата, в която се изпълнява управляваният код на .NET приложенията. Представлява виртуална машина, която контролирано изпълнява .NET кода и осигурява различни услуги, като управление на сигурността, управление на паметта и др.

- Framework Class Library (FCL) – представлява основната библиотека от типове, които се използват при изграждането на .NET приложения. Съдържа основната функционалност за разработка, необходима за повечето приложения, като вход/изход, връзка с бази данни, работа с XML, изграждане на уеб приложения, използване на уеб услуги, изграждане на графичен потребителски интерфейс и др. Стандартните класове и типове от FCL можем да използваме навсякъде, където има инсталиран .NET Framework.

Архитектура на .NET Framework

Архитектурата на .NET Framework често пъти се разглежда на нива, както това е направено на следната схема:

Ще разгледаме отделните слоеве един по един и ще обясним тяхната роля в .NET Framework. Ще започнем от най-долния.

Операционна система

Операционната система управлява ресурсите, процесите и потребителите на машината. Тя предоставя и някои услуги на приложенията като например: COM+, MSMQ, IIS, WMI и други.

Средата, която изпълнява .NET приложенията (CLR), е обикновен процес в операционната система и се управлява от нея, както останалите процеси.

Най-често операционната система, която изпълнява CLR е Microsoft Windows, но .NET Framework има имплементации и за други операционни системи (например проектът Mono).

Common Language Runtime

Общата среда за изпълнение Common Language Runtime (CLR) управлява процеса на изпълнение на .NET код. Тя се грижи за заделяне и освобождаване на паметта, управлява конкурентността, грижите за сигурността на приложенията и изпълнява други важни задачи, свързани с изпълнението на кода. Ще обърнем специално внимание на CLR малко по-нататък.

Base Class Library

Base Class Library (BCL) е част от стандартната библиотека на .NET Framework – Framework Class Library (FCL).

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

Технологиите ADO.NET, XML, ASP.NET и Windows Forms не са част от BCL, тъй като те са по-скоро допълнителни библиотеки, отколкото базова системна функционалност.

ADO.NET и XML

Слоят на ADO.NET и XML предоставя удобен начин за работа с релационни и други бази от данни и средства за обработка на XML. ADO.NET поддържа два моделa на работа с данни – свързан и несвързан. XML поддръжката реализира DOM модела и модел, подобен на SAX, за достъп до XML. Ще разгледаме в детайли XML и ADO.NET в темите "Работа с XML" и "Достъп до данни с ADO.NET".

ASP.NET и Windows Forms

ASP.NET и Windows Forms изграждат слоя за интерфейс към крайния потребител на приложенията и ни предоставят богата функционалност за създаване на уеб и Windows базиран потребителски интерфейс, както и уеб услуги. ASP.NET позволява по лесен начин да бъдат изграждани гъвкави динамични уеб сайтове и уеб приложения и уеб услуги. Windows Forms позволява изграждане на прозоречно-базиран графичен потребителски интерфейс с богати възможности.

ASP.NET и Windows Forms използват компонентно-базирана архитектура и благодарение на нея позволяват изграждане на потребителския интерфейс визуално, чрез сглобяване на компоненти в специално разработени за това редактори, предоставени от средите за разработка. Ще разгледаме в детайли технологиите Windows Forms и ASP.NET в темите "Графичен потребителски интерфейс с Windows Forms", "Изграждане на уеб приложения с ASP.NET" и "Уеб услуги с ASP.NET".

Езици за програмиране

.NET Framework позволява на разработчика да използва различни езици за програмиране, както и да интегрира в едно приложение компоненти, разработвани на различни езици. Възможно е дори клас, написан на един език, да бъде наследен и разширен от клас, написан на друг език.

Microsoft .NET Framework поддържа стандартно езиците C#, VB.NET, Managed C++ и J#, но трети доставчици предлагат допълнително .NET версия на още много други езици, като Pascal, Perl, Python, Fortran, Cobol и други.

Съвместимостта на езиците за програмиране в .NET Framework се дължи на архитектурни решения, които ще разгледаме в детайли след малко.

Common Language Runtime

След като се запознахме накратко с архитектурата на .NET Framework, нека сега разгледаме в детайли и най-важният компонент от нея – CLR.

Common Language Runtime (CLR) е сърцето на .NET Framework. Той представлява среда за контролирано изпълнение на управляван код. На практика CLR е тази част от .NET Framework, която изпълнява компилираните .NET програми в специална изолирана среда.

В своята същност CLR представлява виртуална машина, която изпълнява инструкции, на езика IL (Intermediate Language), езикът до който се компилират всички .NET езици. CLR е нещо като виртуален компютър, който обаче не изпълнява асемблерен код за процесор Pentium, AMD или някакъв друг, а IL код.

Има голямо сходство между .NET CLR и Java Virtual Machine, но между двете технологии и много разлики. По предназначение те служат за едно също нещо – да изпълняват код за някакъв виртуален процесор. В .NET това е IL кода, а при Java платформата – т. нар. Java bytecode. Основната разлика между IL и bytecode е, че IL е език от по-високо ниво, а това позволява да бъде компилиран много по-ефективно от Java bytecode.

Задачи и отговорности на CLR

Отговорностите на CLR включват:

- Изпълнение на IL кода. Реално IL инструкциите, преди да бъдат изпълнени за първи път, се компилират до инструкции за текущия процесор и след това се изпълняват от системния процесор. Този процес на междинно компилиране до машиннозависим (native) код се нарича JIT компилация (Just-In-Time compilation).

- Управление на паметта и ресурсите на приложенията. CLR включва в себе си система за заделяне на памет и система за почистване на неизползваната памет и ресурси (т. нар. garbage collector). Управлението на паметта при .NET приложенията се извършва в голяма степен автоматизирано и в повечето случаи програмистът не трябва да се грижи за освобождаване на заделената памет. Ще разгледаме в детайли как .NET Framework управлява паметта в темата "Управление на паметта и ресурсите".

- Осигуряване безопасността на типовете. .NET Framework е среда за контролирано изпълнение на програмен код (managed execution environment). Тя не позволява директен достъп до паметта, не позволява директна работа с указатели, не позволява преобразуване от един тип към друг, който не е съвместим с него, не позволява излизане от границите на масив, както и всякакви други опасни операции. По тази причина .NET се нарича управлявана среда – защото тя управлява изпълнението на кода и по този начин предпазва програмите от много досадни проблеми, които възникват при неуправляваните среди.

- Управление на сигурността. NET Framework има добре изградена концепция за сигурност на различни нива. От една страна .NET приложенията могат да се изпълняват с различни права. Правата могат да се задават от администраторите чрез т. нар. политики за сигурност. CLR следи дали кодът, който се изпълнява, спазва зададената политика за сигурност и не позволява тя да бъде нарушена. Тази техника се нарича "code access security". От друга страна .NET Framework поддържа и средства за управление на сигурността, базирана на роли (role-based security). Ще разгледаме в детайли всички тези техники и средства в темата "Сигурност в .NET Framework".

- Управление на изключенията. .NET Framework е изцяло обектно-ориентирана среда за разработка и изпълнение на програмен код. В нея механизмът на изключенията е залегнал като основно средство за управление на грешки и непредвидени ситуации. Една от задачите на CLR е да се грижи за изключенията, които възникват по време на изпълнение на кода. При настъпване на изключение CLR има грижата да намери съответния обработчик и да му предостави управлението. Ще разгледаме в детайли всичко това в темата "Управление на изключенията в .NET".

- Управление на конкурентността. CLR контролира паралелното изпълнението на нишки (threads) като за целта си взаимодейства с операционната система. Повече за работата с нишки ще научим в темата "Многонишково програмиране и синхронизация".

- Взаимодействие с неуправляван код. CLR осигурява връзка между управляван (.NET) код и неуправляван (Win32) код. За целта той изпълнява доста сложни задачи, свързани с конвертиране на данни, синхронизация, прехвърляне на извиквания, взаимодействие с компонентния модел на Windows (COM) и много други. Ще разгледаме в детайли тези проблеми в темата "Взаимодействие с неуправляван код".

- Подпомагане процесите на дебъгване (debugging) и оптимизиране (profiling) на управлявания код. CLR осигурява инфраструктура и средства за реализацията на дебъгване и оптимизиране на кода от външни специализирани програми.

Управляван код

Управляваният код (managed code) е кодът, който се изпълнява от CLR. Той представлява поредица от IL инструкции, които се получават при компилацията на .NET езиците. По време на изпълнение управляваният код се компилира допълнително до машиннозависим код за текущата платформа и след това се изпълнява директно от процесора.

Управляван код и неуправляван код

Управляваният код (.NET код) се различава значително от неуправлявания код (например Win32 кода).

Управляваният код е машиннонезависим, т. е. може да работи на различни хардуерни архитектури, процесори и операционни системи, стига за тях да има имплементация на CLR.

Неуправляваният код е машиннозависим, компилиран за определена хардуерна архитектура и определен процесор. Например програмите, написани на езика C, се компилират до неуправляван код за определена архитектура.

Ако компилираме една C програма за Embedded Linux върху платформа StrongARM, ще получим неуправляван машиннозависим (native) код за Linux за тази платформа. Кодът ще съдържа инструкции за микропроцесор StrongARM и ще използва системни извиквания към операционната система Embedded Linux. Съответно на друга платформа няма да може да работи без прекомпилация на сорс кода на C програмата.

По същия начин, ако компилираме една C програма за Windows върху архитектура x86, ще получим неуправляван код за процесор x86 (примерно Pentium, Athlon и т.н.), който използва системни извиквания към Windows. Този код се нарича Win32 код и може да работи само върху 32-битова Windows операционна система. За да се стартира върху друга платформа, трябва да се компилира.

При управлявания код нещата стоят по различен начин. Ако компилираме една C# програма за платформа .NET Framework 1.1, ще получим управляван, машиннонезависим IL код, който може да работи върху различен хардуер. Кодът реално ще е компилиран за платформа CLR 1.1 и ще се състои от IL инструкции за виртуалния процесор на CLR и ще използва системни извиквания към .NET Base Class Library.

Управляваният код лесно може да бъде пренесен върху различни платформи без да се променя или прекомпилира. Така например програма на C#, която е компилирана под Windows до управляван IL код, може да се изпълнява без промени както върху Windows под .NET Framework, така и върху Linux под Mono, а също и върху мобилни устройства под Windows CE и .NET Compact Framework.

Метаданните в управлявания код

Управляваният код се самоописва чрез метаданни и носи в себе си описание на типове данни, класове, интерфейси, свойства, полета, методи, параметри на методите и други, както и описание на библиотеки с типове, описание на изисквания към сигурността при изпълнение и т. н. Това дава голяма гъвкавост на разработчика и възможност за динамично зареждане, изследване и изпълнение на функционалност, компилирана като управляван (IL) код.

Неуправляваният код стандартно не съдържа метаданни и това силно затруднява динамичното зареждане и изпълнение на неуправлявана функционалност.

Управляваният код е обектно-ориентиран

Управляваният код задължително е обектно-ориентиран, докато за неуправлявания няма такова изискване. Всички .NET езици са обектно-ориентирани. Всички .NET програми се компилират до класове и други типове от общата система от типове на .NET Framework. Всички данни, използвани от управлявания код, са наследници (в смисъла на обектно-ориентираното програмиране) на базовия тип System.Object. Ще разгледаме това в подробности в темата "Обща система от типове".

Управляваният код е високо надежден

Управляваният код е защитен от неправилна работа с паметта и типовете и това го прави по-сигурен и високо надежден. Управляваният код не може да извършва неправилен достъп до паметта, достъп до чужда памет и неправилна работа с типове. Това предпазва програмисти от много досадни проблеми, присъщи при писането на неуправляван код, като загуба на памет, достъп до неинициализирана памет, повторно освобождаване на памет, работа с невалиден указател и т.н.

Управляваният код интегрира различни езици

До управляван код се компилират всички .NET езици. Това дава възможност за широко взаимодействие между код, писан на различни езици за програмиране. Възможно е дори клас, написан на един .NET език, да бъде наследен и разширен от клас, написан на друг .NET език.

За .NET Framework няма значение на какъв език е бил написан кода преди да бъде компилиран. Всичкият код се компилира до IL и се изпълнява от CLR по еднакъв начин.

Управление на паметта

Управлението на паметта е една от важните задачи на CLR. Идеята за автоматизирано управление на паметта е залегнала в .NET Framework на дълбоко архитектурно ниво. Целта е да се улесни разработчика като се освободи от досадната задача сам да следи за освобождаването на заделената памет.

CLR, като средата за изпълнение, управлява заделянето на памет, инициализирането й, и автоматичното й освобождаването посредством garbage collector.

Динамично заделените обекти се разполагат в динамичната памет, в тъй наречения "managed heap". След като техния живот завърши и те вече не са необходими на приложението, системата за почистване на паметта (garbage collector) освобождава заеманата от тях памет автоматично. По този начин се избягват най-често срещаните проблеми като загуба на памет и достъп до освободена или неинициализирана памет. Повече за управлението на паметта в .NET Framework ще научим в темата "Управление на паметта и ресурсите".

Важна особеност при работата с управляван код е, че при него няма указатели. Вместо указатели се работи с референции, които са силно типизирани и се управляват автоматично. Референцията (reference) прилича на указател, но не е просто адрес в паметта, а има тип, т. е. тя е указател към определен тип данни и не може да сочи към място в паметта, където няма инстанция на този тип.

Intermediate Language (IL)

Междинният език Intermediate Language (IL), е език за програмиране от ниско ниво, подобен на асемблерните езици. За разлика от тях, обаче, IL е от много по-високо ниво, отколкото асемблерите за съвременните микропроцесори.

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

Тъй като не е процесорно-специфичен, IL предоставя голяма гъвкавост и възможност за изпълнение на кода върху различни платформи чрез компилиране до съответния за платформата машинен език.

Възможна е и предварителна компилация до код за текущата платформа, но тази техника не носи голяма полза и рядко се използва.

Имплементацията на IL в .NET Framework се нарича MSIL (Microsoft Intermediate Language). IL може да има и други имплементации в други платформи и среди за изпълнение на .NET код.

Езикът IL е стандартизиран от организацията ECMA и в съответния стандарт се нарича CIL (Common Intermediate Language).

Често пъти термините IL и MSIL се използват като взаимозаменяеми и затова винаги трябва да имате предвид, че става въпрос за кода, който се изпълнява от CLR – машинният код, получен при компилацията на .NET езиците.

Intermediate Language (IL) – пример

За да илюстрираме по-добре казаното до тук, нека разгледаме една проста програмка, написана на MSIL – класическият пример "Hello world!":

.method private hidebysig static void Main() cil managed

{

.entrypoint

// Code size 11 (0xb)

.maxstack 8

ldstr "Hello, world!"

call void [mscorlib]System.Console::WriteLine(string)

ret

} // end of method HelloWorld::Main

Всичко, което прави тази MSIL програма, е да изведе съобщението "Hello, world!" на конзолата. Тя дефинира един статичен метод без параметри с име Main, в който извиква с параметър "Hello, world!" статичния метод WriteLine() от класа System.Console, който отпечатва посочения текст.

Компилация и изпълнение

Вече споменахме няколко пъти междинния код IL и обяснихме, че .NET езиците (C#, VB.NET и т. н.) се компилират до него, а след това полученият код се изпълнява от CLR.

Сега ще разгледаме детайлно процеса на компилиране и изпълнение на .NET приложенията. Ще изясним как се извършва компилирането на програми от високо ниво, как се получава IL код, как този код се записва в специален файлов формат (асембли) и как след това компилираните асемблита се изпълняват от CLR като се компилират междувременно до машинен код от JIT компилатора.

Целият този процес е изобразен схематично на фигурата:

Изходният код на .NET програмите може да е написан на предпочитания от нас .NET език, например C#, VB.NET, Managed C++ или друг. За да го компилираме до IL управляван код, използваме компилатора за съответния език. В резултат получаваме асембли.

Асемблито представлява изпълним файл, съдържащ .NET управляван код и метаданни, които описват съдържанието на асемблито. Метаданните съдържат имената на класовете и типовете в асемблито, информация за членовете на класовете (методи, полета, свойства и други).

Едно асембли може да бъде изпълним файл (.exe файл) или динамична библиотека (.dll файл). Изпълнимите файлове съдържат допълнителна информация, която подпомага началното им стартиране (например входна точка на изпълнение).

При изпълнение на дадено асембли CLR го зарежда в паметта и анализира метаданните му. Извършват се различни проверки на кода – дали е коректен спрямо IL стандарта, дали има необходимите права за изпълнение и др.

След това управляваният IL код преминава през специфичния за текущата платформа JIT компилатор и се компилира до машинен код за текущия процесор. Компилираният вече код след това се изпълнява директно от процесора.

JIT компилаторът не компилира в началото цялото асембли, а само методът, от който започва изпълнението му. След това при опит за изпълнение на некомпилиран метод, той се компилира. Така кодът се компилира само при нужда и това осигурява добро бързодействие. Забавянето е незначително и скоростта на изпълнение на управлявания код на практика е почти еднаква със скоростта на изпълнение на неуправлявания код.

Предимството на JIT компилацията е, че може да оптимизира кода за текущата хардуерна платформа по най-добрия начин. Например ако е наличен най-мощният процесор на Intel или AMD и CLR поддържа този процесор, той ще компилира IL кода по начин, оптимизиран специално за него, и ще използва пълните му възможности. При неуправляваният код това не е възможно, защото кодът се компилира така, че да работи върху всички процесори, без да използва пълните възможности на текущата хардуерна платформа. По тази причина в някои случаи управляваният код може да е дори по-бърз от неуправлявания въпреки нуждата от JIT компилация, която отнема време.

Когато разполагаме с компилирано асембли и искаме да го изпълним, имаме право на избор кога да компилираме IL кода до машинен код. Това може да стане по време на изпълнение (посредством JIT компилатора) и предварително (с прекомпилация за текущата платформа).

Прекомпилацията на асемблита се извършва с инструмента ngen.exe, който е стандартна част от .NET Framework.

Архитектура на CLR

Общата среда за изпълнение CLR се състои от доста модули, всеки от които изпълнява конкретна задача. Схематично архитектурата можем да представим по следния начин:

Ще разгледаме всеки от посочените компоненти съвсем накратко, тъй като функциите им са от много ниско ниво и рядко ще ни се налага да взаимодействаме директно с тях:

- Base Class Library Support – предоставя системни услуги, необходими за работата на Base Class Library (BCL).

- Thread Support – предоставя услуги за манипулация на нишки в .NET приложенията – създаване на нишка, управление на състоянието на нишка, синхронизация и др.

- COM Marshaler – грижи се за комуникацията с COM обекти. Осигурява извикването на COM сървъри от .NET код и извикването на .NET код от COM. Негова грижа са прехвърлянето на заявки, преобразуването на данни, управлението на жизнения цикъл на COM обектите и др.

- Type Checker – осъществява проверка на типовете за съответствие при извикване и поддържа класовите йерархии.

- Exception Manager – грижи се за управление на изключенията –предизвикване на изключение, прихващане, обработване и др.

- Security Engine – отговаря за проверките на сигурността при изпълнение на кода.

- Debug Engine – осигурява функционалност, свързана с дебъгването и оптимизирането на управляван код.

- JIT Compiler – един от най-важните модули – по време на изпълнение компилира IL кода в специфичен за процесора код.

- Code Manager – управлява изпълнението на кода.

- Garbage Collector – управлява паметта автоматичното почистване на паметта и ресурсите. Контролира живота на обектите.

- Class Loader – служи за зареждане на класове и типове. Използва се при началното изпълнение на приложението, както и при динамично зареждане на код по време на изпълнение.

Как CLR изпълнява IL кода?

Нека сега разгледаме по-подробно как CLR изпълнява IL кода. Изпълнението на кода, както можем да видим от схемата по-долу, е итеративен процес, който се състои от много стъпки.

При изпълнение на метод от едно асембли Class Loader подсистемата на CLR зарежда всички нужни за неговата работа класове и типове. В зависимост от това дали кодът е вече компилиран до машинен или не Class Loader предава кода за директно изпълнение или го компилира с JIT компилатора (при първо извикване на всеки метод).

Преди JIT компилацията се извършва процес, известен като верификация. Той проверява дали IL кодът е безопасен – дали не се опитва да осъществява директен достъп до паметта, дали не се опитва да заобикаля механизмите за сигурност и т. н. Ако системният администратор е определил кода за сигурен (trusted) неговото верифициране може да бъде се прескочено.

JIT компилаторът създава специфичен за машината код (native код), който се изпълнява директно от процесора. Този машинен код съдържа в себе си много допълнителни инструкции, чрез които си взаимодейства със CLR. Целта е кодът да се изпълнява по контролиран начин, за да не нарушава принципите за сигурност и надеждност, но без да се забавя излишно заради всички допълнителни проверки.

При изпълнението на кода, при достъп до ресурси, при извикване на системни библиотеки и в много други случаи се извършват проверки на сигурността (чрез т. нар. security engine).

Ако трябва да бъде извикан некомпилиран метод, този метод се връща в JIT компилатора и така се затваря цикълът на компилация до машинен код. Като резултат от описания алгоритъм не се налага компилиране на един и същ метод повече от веднъж и освен това, ако някой метод не се извиква никъде в приложението, той въобще не се компилира от JIT компилатора.

Асемблита

Асемблитата са най-малката самостоятелна градивна единица в .NET Framework. Те представляват наследници на познатите ни .exe и .dll файлове и съдържат IL изпълним код, метаданни и ресурси:

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

Асемблитата имат собствена версия и дефинират изисквания към правата, свързани със сигурността, на потребителя или процеса, който ги изпълнява. Те могат да имат и цифров подпис, положен от създателя им, чрез който се осигурява повишена сигурност.

Проблемът "DLL Hell"

С вграждането на версия в самия файл на асемблито се разрешава проблемът, известен като "DLL Hell". Той се състои в следното: Когато няколко приложения зависят от един и същ споделен файл и от точно определена негова версия, с досегашните технологии в Windows при поява на нова версия на този файл, старият файл се презаписва и на практика няма гаранция, че новата версия е 100% съвместима със старата. В резултат по "магически" начин някое от приложенията, което е използвало старата версия, престава да работи.

Например при Win32 приложенията може да се случи при инсталиране на нов софтуер част от старите приложения, които са работели до този момент, да спрат да работят. Причината е в това, че новият софтуер презаписва някоя от библиотеките, които старите приложения са използвали, с по-нова версия, която може да не е съвместима със старата.

Тъй като при асемблитата версията се задава за всяко едно от тях и се записва освен в метаданните на асемблито и в неговото файлово име, при поява на нова версия не се появяват конфликти между приложенията.

Всяко асембли може да посочи точно кое асембли му е необходимо и точно в коя негова версия. Освен, че могат да съществуват едновременно няколко различни версии на едно асембли, те могат и да се изпълняват едновременно. Така е възможно в един и същи момент да работят и старите и новите приложения и всяко приложение да използва версията на общите асемблита, с която е предвидено да работи.

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

Метаданни

Както вече споменахме, всички асемблита съдържат метаданни. Метаданните описват различни характеристики на асемблитата и съдържимото в тях:

- име на асемблито (например System.Windows.Forms)

- версия, състояща се от 4 числа (например 1.0.5000.0)

- локализация, описваща език и култура (например неутрална или en-US или bg-BG)

- цифров подпис на създателя (незадължителен)

- изисквания към правата за изпълнение

- зависимости от други асемблита (описани с точното име и версия)

- експортирани типове

- списък със дефинираните класове, интерфейси, типове, базови класове, имплементирани интерфейси и т.н.

- списък с дефинираните ресурси

Освен тези данни за всеки клас, интерфейс или друг тип, който е дефиниран в асемблито, се съдържа и следната информация:

- описание на член-променливите, свойствата и методите в типовете

- описание на параметри на методите, връщана стойност на метода за всеки метод

- приложени атрибути към асемблито, методите и другите елементи от кода

IL код

Във всяко асембли може да има секция, в която се намира неговият изпълним код (IL кодът). Тази секция не е задължителна. Вече разгледахме какво представлява IL кодът и как се изпълнява, така че няма да се спираме отново на това.

Ресурси

В ресурсната секция на асемблито могат да бъдат добавяни различни ресурси (иконки, картинки, локализирани низове и др.), необходими на приложението. Ресурсите могат да се пакетират във файла на асемблито, заедно с изпълнимия код и могат да се извличат от него по време на изпълнение. Тази секция не е задължителна.

За удобство имаме възможност да създаваме и асемблита, които се състоят от няколко файла, както и сателитни асемблита с различна култура. Ще разгледаме асемблитата по-детайлно в темата "Асемблита и разпространение".

Разгръщане на асемблита

Тъй като асемблитата са основната единица за разгръщане (deployment) в .NET Framework, ще се спрем накратко върху различните видове асемблита според начина им на разгръщане – частни и споделени.

Частните асемблита (private assemblies) се използват само от едно приложение и се записват в неговата директория или в нейна поддиректория. Те са лесни за разгръщане тъй като могат да се разпространяват чрез просто копиране и вмъкване (copy/paste). При тях контролът на версиите е по-лесен и не се изисква цифров подпис на създателя или силно име.

Споделените асемблита от своя страна са достъпни за всички приложения. Те се инсталират в специална област, наречена Global Assembly Cache (GAC). Всяко приложение, което реферира външно асембли търси споделените асемблита в тази област. Това поведение може да се контролира чрез манифеста, който задава правилата за търсене на нужните асемблита и версии. За да се определи уникално всяко асембли използва т. нар. силно име (strong name). To включва:

- име на асемблито

- версия

- локализация

- цифров подпис на създателя

Пример за силно име на асембли е идентификаторът:

["myDll, Version=1.0.0.1, Culture=neutral, PublicKeyToken= 9b35aa32c18d4fb1"]

Повече за разгръщане на приложения и асемблита можете да намерите в темата "Асемблита и разпространение".

.NET приложения

.NET приложенията се състоят от едно или повече асемблита, в които се съдържат техният код и ресурси. Те представляват изпълними единици, които могат да бъдат конфигурирани.

В зависимост от вида си .NET приложенията могат да бъдат самостоятелни или обвързани с други услуги или приложения. Например уеб приложенията не са самостоятелни и се изпълняват в средата на ASP.NET, докато конзолните приложения могат да се изпълняват самостоятелно.

За разлика от повечето Win32 приложения, .NET приложенията могат да бъдат инсталирани с просто копиране (XCOPY deployment), без да се налага регистриране на отделните им компоненти (регистрирането се налага само, ако искаме да позволим неуправлявани компоненти да могат да достъпват нашите асемблита). При .NET приложенията не се използва Windows Registry за регистрация на компонентите.

Всяко приложение използва собствена политика за зареждане на свързаните с него асемблита и намирането на нужната им версия. При липса на изрично указана такава първо се търси подходящо асембли в директориите на приложението и после в GAC. Всяко едно приложение може да използва различна версия на дадено асембли без да се влияе от останалите и, както вече споменахме, новите версии не предизвикват конфликти.

Поради всички посочени качества инсталирането, поддържането, обновяването и деинсталирането на .NET приложения е лесно и безопасно за останалите приложения.

Преносими изпълними файлове

В Windows и в .NET Framework се въвежда понятието "преносим изпълним файл" (Portable Executable или PE). Това са файлове, които съдържат информация за себе си, съдържат своя изпълним код и необходимите за работата си ресурси. Структурата на РЕ файловете може да се онагледи със следната фигура:

РЕ хедърът съдържа описание за вида на самия РЕ файл – дали той е изпълним или е библиотека с типове.

След него CLR хедърът дава нужната на CLR информация за изпълнение на самото асембли.

Останалите елементи са ни вече познати от структурата на асемблитата и затова няма да се спираме на тях отново.

Понятието РЕ представлява обобщение на двата файлови формата – .exe и .dll (става дума единствено за Windows платформи – при другите имплементации на CLI е много вероятно тези формати да се описват по друг начин.)

Application domains

Application domain (домейн на приложението) е ново понятие, което се въвежда с .NET Framework. То представлява допълнително ниво на изолация между отделни .NET приложения, изпълнявани в един и същ процес на операционната система.

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

Както вече знаем, всяко .NET приложение изисква CLR да бъде зареден в паметта. Ако трябва да го зареждаме за всяко .NET приложение, което стартираме, това ще предизвика голямо ненужно натоварване и неефективно използване на ресурсите.

Като решение на този проблем идва концепцията за обединяване на няколко .NET приложения в един процес от операционната система. Това, обаче крие рискове приложенията да си пречат едно на друго. Необходим е начин за изолиране на приложенията едно от друго в рамките на процеса. Точно такава е задачата на домейните на приложенията (application domains) – те ни позволяват да изпълняваме няколко приложения в един и същ процес и същевременно ни дават пълна изолация между тях. По този начин намаляваме броя на процесите, спестяваме разход на процесорно време за зареждане на CLR и прехвърляне между процесите и намаляваме количеството на използваната памет и елиминираме повторното зареждане на едни и същи библиотеки.

.NET Framework използва вътрешно домейни на приложението за много цели, например за да изолира едно от друго отделните ASP.NET уеб приложения в рамките на един уеб сървър.

Интеграция на езиците за програмиране

Една от най-добрите черти на .NET Framework е възможността за интеграция на множество езици за програмиране. Тя позволява да работим на предпочитания от нас език и да не губим възможността за използване на други езици в рамките на нашето решение.

За .NET Framework няма значение на какъв език е написан даден клас или компонент, стига езикът да поддържа общата езикова спецификация – CLS (Common Language Specification), т.е. да е един от .NET езиците.

Интеграцията на различни езици в .NET Framework е възможна благодарение на три важни стандарта:

- Common Language Specification (CLS)

- Intermediate Language (IL)

- Common Type System (CTS)

Ще разгледаме тези стандарти един по един с изключение на IL, тъй като вече се запознахме с него.

Common Language Specification (CLS)

CLS дефинира общите и задължителни характеристики, които един програмен език трябва да притежава, за да бъде съвместим с останалите .NET езици. Тази спецификация има за цел да минимизира разликите между .NET езиците.

CLS, например, налага ограничението да се прави разлика межди малки и главни букви в имената на типовете и техните публични членове, методи, свойства и събития. Ако нарушим това правило, нашият код ще се компилира, но ще загуби съвместимостта си с CLS и другите .NET езици.

Друго ограничение, което CLS налага, e езиците да бъдат обектно-ориентирани. Това означава, че за да бъде направен даден език съвместим с CLS и .NET Framework, той трябва да бъде разширен да поддържа класове, интерфейси, свойства, изключения и всички останали елементи на обектно-ориентираното програмиране с .NET.

Повечето .NET езици поддържат много повече възможности от тези, които изисква CLS. Поради това трябва да сме внимателни при създаването на класове и други типове и да подхождаме с ясната идея дали искаме те да са CLS съвместими или не.

Common Type System (CTS)

Общата система от типове в .NET Framework представлява формална спецификация на типовете данни, използвани в различните .NET езици за програмиране. CTS описва различните .NET типове (примитивни типове данни, класове, структури, интерфейси, делегати, атрибути и др.). В CTS се описват съдържанието и начина на дефиниране на типовете, модификаторите за достъп, начините за наследяване, времето на живот на обектите и много други технически характеристики.

CTS ни гарантира съвместимостта на данните между отделните езици за програмиране. Например типът String в С# е същия като String във Visual Basic .NET. Това позволява кодът, писан на различни езици, да си обменя свободно данни, защото данните са съвместими с CTS.

CTS дефинира двата типа обекти – референтни и стойностни, според това как се пазят в паметта и как се манипулират. CTS налага задължението всички типове да наследяват системния тип System.Object, дори и примитивните. Благодарение на това извикването "5.ToString()" е напълно валидно в езика C#.

Ще опишем съвсем накратко референтните и стойностните типове в CTS, а в по-големи детайли относно тях ще навлезем в темата "Обща система от типове".

Референтни типове

Референтни типове (reference types) са всички класове, масиви, интерфейси и делегати. Класът String също е референтен тип. Техните инстанции представляват типово-обезопасени указатели към паметта, в която са записани данните за определен обект.

Инстанциите на референтните типове се съхраняват в динамичната памет (managed heap) и подлежат на почистване от системата за събиране на боклука (garbage collector). При предаване като параметър, те се предават по референция (адрес).

Стойностни типове

Стойностни типове (value types) са структурите и примитивните типове (като int, float, char и други). Този тип обекти се съхраняват в стека и се унищожават при излизане от обхват. При предаване като параметър, се предават по стойност (освен, ако изрично не е указано друго).

Common Language Infrastructure (CLI)

Спецификацията за общата инфраструктура на .NET езиците CLI (Common Language Infrastructure) е стандартизираната част от CLR. Нейната цел е още по-мащабна от идеята да се интегрират различните езици за програмиране – става дума за междуплатформена съвместимост. За целта тя е стандартизирана от организациите ECMA и ISO (стандарт ISO 23271:2003).

В CLI се описва как приложения написани на различни езици да могат да се изпълняват в различни среди без да се налага да се променят или прекомпилират.

CLI стандартизира следните компоненти на .NET Framework:

- Common Language Specification (CLS)

- Common Type System (CTS)

- Common Intermediate Language (CIL)

- Начина за управление на изключения в .NET

- Форматите за асемблита и метаданни

- Части от .NET Framework Class Library

Имплементацията на CLI стандарта за Windows е Microsoft .NET Framework, а за UNIX и Linux е Mono. С учебна цел Майкрософт разпространяват официално имплементация на CLI с отворен код, т. нар. Shared Source CLI (http://msdn.microsoft.com/net/sscli/).

.NET езиците

Microsoft предлагат компилатори и поддръжка във Visual Studio .NET 2003 за следните езици:

- C# - препоръчителният език за програмиране под .NET Framework. Съвременен обектно-ориентиран език, подобен на C++ и Java, разработен специално за .NET Framework.

- Visual Basic .NET – обновена версия на езика Microsoft Visual Basic, адаптирана към .NET Framework.

- C++ (managed/unmanaged) – езикът C++ по идея е език от доста по-ниско ниво в сравнение със C# и VB.NET. Той е адаптиран към .NET Framework чрез множество разширения, допълнения и ограничения и е наречен Managed C++. Езикът продължава да съществува и като неуправляван език, който не е съвместим с .NET и се нарича Unmanaged C++.

- J# – езикът J# е създаден за да позволи по-лесното прехвърляне на Java приложения към C#. Той спазва синтаксиса на езика Java, на използва както стандартните библиотеки на Java платформата, така и стандартните библиотеки на .NET (Framework Class Library).

- JScript.NET – езикът JScript.NET е представител на слабо типизираните скриптови езици от фамилията ECMAScript (като JavaScript, VBScript и JScript), но е адаптиран към .NET Framework. Използва се за изпълнение на скриптове в някои уеб браузъри и някои други приложения.

Допълнително освен стандартните .NET езици трети доставчици са разработили съвместими с .NET Framework компилатори за Perl (ActiveState Perl for .NET), Python, Pascal (Borland Delphi 2005), Smalltalk, APL, COBOL, Eiffel, Haskell, Scheme и др.

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

Интеграцията на езиците за програмиране в .NET Framework е вградена и не се налага да правим "акробатики" за да я използваме. Това е възможно поради единните система от типове, програмен модел и библиотеки от класове.

Езикът C#

Както вече споменахме, C# е препоръчваният език за програмиране за .NET Framework. Този език е специално проектиран от архитектите на .NET Framework и е съобразен с особеностите на платформата още по време на дизайна. Именно по тази причина в настоящата книга всички примери и програмен код са написани на C#.

C# компилаторът е част от стандартния пакет на Microsoft .NET Framework SDK. C# е нов език, който се появява за пръв път в .NET и представлява смесица между C++ и Java, с елементи от Delphi. Проектиран е от екипа на Андерс Хейлсбърг, създателят на средата за бърза разработка на приложения Delphi, който е работил дълги години като архитект в Borland, а по-късно се присъединява към Microsoft.

C# е съвременен обектно-ориентиран език, силно типизиран, с широка поддръжка на идеите на компонентно-ориентирания подход за разработка. C# поддържа синтаксис за дефиниране и използване на свойства и събития, които играят важна роля при дефинирането и използването на компоненти.

C# е наследник на езика C++, но не наследява от него всичко, а само част от синтаксиса и някои негови силни страни (например предефинирането на оператори). По идея C# е проектиран да бъде лесен за използване като Java, но мощен като C++ и до голяма степен тази идея е осъществена.

В C# е премахната нуждата от допълнителни файлове като хедъри, IDL дефиниции и други, познати ни в повечето езици като C и С++. Езикът няма никакви ограничения в употребата си – еднакво добре можем да програмираме Windows, уеб или конзолни приложения, услуги (services) или библиотеки.

Заради силната типизация в С# всичко е обект – всеки един от типовете, дефинирани било в .NET Framework, било от нас, директно или индиректно наследяват базовия тип System.Object.

Самият език С# е стандартизиран от ЕСМА и ISO още преди да бъде реализирана финалната му версия в .NET Framework.

Езикът C# – пример

Както вече обяснихме, настоящата книга разглежда работата с .NET Framework в контекста на езика С#, така че от тук нататък често ще срещаме правоъгълни области с примерен код, като следващата:

using System;

namespace HelloCSharp

{

class HelloCSharp

{

static void Main()

{

Console.WriteLine("Hello, C#!");

}

Примерът дефинира нашата първа програма на C# – класическата програмка "Hello, World!", която е адаптирана за C# и се е превърнала в "Hello, C#!". Сега няма да обясняваме в детайли как работи тя, защото ще направим това по-късно, в темата "Въведение в C#".

Framework Class Library

Framework Class Library (FCL) е стандартната библиотека на .NET Framework. В нея се съдържат няколко хиляди дефиниции на типове, които предоставят богата функционалност.

FCL съдържа средства, които позволяват на програмистите да разработват различни видове приложения:

- Windows приложения с прозоречно-базиран графичен потребителски интерфейс

- Уеб-базирани приложения

- Конзолни приложения

- Приложения за мобилни устройства

- XML уеб услуги

- Windows услуги

- Библиотеки с компоненти

Основните библиотеки, от които се състои FCL, са:

- Base Class Library – библиотека съдържаща основните средства, нужни за разработване на приложения. Дефинира работа с вход и изход, многозадачност, колекции, символни низове и интернационализация, достъп до мрежови ресурси, сигурност, отдалечено извикване и други.

- ADO.NET и XML – осигуряват достъп до бази данни и средства за обработка на XML.

- ASP.NET – предоставя ни рамкова среда (framework) за разработка на уеб приложения с богата функционалност, както и средства за създаване и консумиране на уеб услуги.

- Windows Forms – служи за основа при разработването на Windows приложения с прозоречно-базиран графичен потребителски интерфейс. Windows Forms се базира на вградените в Windows средства за изграждане на графичен потребителски интерфейс.

По-нататък ще обърнем специално внимание на всички тези библиотеки и ще разгледаме средствата, които те предлагат, в дълбочина.

Пакетите от FCL

За да се работи по-лесно с това голяма многообразие от типове, което FCL предлага, типовете са разделени в отделни асемблита и допълнително са разпределени в пространства от имена (namespaces) според своето предназначение и взаимовръзка.

Да разгледаме основните пространства от имена от FCL и тяхното предназначение:

- System – съдържа основни типове, използвани от всяко .NET приложение. В пространството System се намира, например, базовият за всички типове в .NET Framework клас System.Object, както и класът System.Console, който позволява вход и изход от конзолата.

- System.Collections – в това пространство се намират често използвани типове за управление на колекции от обекти: стек, опашка, хеш таблица и други.

- System.IO – съдържа типовете, които осигуряват входно-изходните операции в .NET Framework – потоци, ресурси от файловата система и други.

- System.Reflection – съдържа типове, които служат за достъп до метаданните по време на изпълнение на кода. Чрез тях е възможна реализацията на динамично зареждане и изпълнение на код.

- System.Runtime.Remoting – имплементира технология, която позволява отдалечен достъп до обекти и данни по прозрачен за програмиста начин.

- System.Runtime.Serialization – обединява типове, отговорни за процеса на сериализация и десериализация на обекти (запазване на състоянието на обект и по-късното му възстановяване).

- System.Security – в това пространство се намират типовете, които се използват за управление на сигурността. Те позволяват защита на данни и ресурси, определяне и проверка на текущите права на потребителя и други.

- System.Text – типовете от това пространство предоставят функционалност за обработка на текст, промяна на кодовата му таблица и други услуги, свързани с конвертиране на данни и интернационализация на приложенията.

- System.Threading – дефинира типове, осигуряващи достъп до нишки и свързаните с тях операции, като например синхронизация.

- System.Xml – съдържа типове за работа с XML и технологиите, свързани с него.

Освен тези общодостъпни пространства от имена, разполагаме и с още някои, които са достъпни за различните типове приложения:

- System.Web.Services – дефинира типовете, използвани за изграждането и консумирането на уеб услуги.

- System.Web.UI – съдържа стандартни средства и компоненти за изграждане на уеб приложения.

- System.Windows.Forms – съдържа типове, използвани при създаването на Windows приложения с графичен потребителски интерфейс.

Visual Studio .NET

До момента се запознахме с .NET Framework, с нейната архитектура, със средата за контролирано изпълнение на управляван код CLR и с основните библиотеки на .NET Framework.

Време е да разгледаме и средата за разработка на .NET приложения, която Microsoft предоставят на разработчиците. Това е продуктът Microsoft Visual Studio .NET (VS.NET).

VS.NET е една от водещите в световен мащаб интегрирани среди за разработка на приложения (IDE – Integrated Development Environment). С негова помощ можем да извършваме всяка една от типичните задачи, свързани с изграждането на едно приложение – писане на код, създаване на потребителски интерфейс, компилиране, изпълняване и тестване, дебъгване, проследяване на грешките, създаване на инсталационни пакети, разглеждане на документацията и други.

Писане на код

Пакетът Visual Studio .NET 2003 поддържа стандартно езиците за програмиране Microsoft C# .NET, Microsoft Visual Basic .NET, Microsoft C++ .NET (managed/unmanaged) и Microsoft Visual J#. За да ползвате език, различен от тези, които Microsoft предлага стандартно, трябва да инсталирате нужните добавки към VS.NET.

Текстовият редактор за код на VS.NET поддържа всички утвърдени съвременни функции на редакторите за сорс код – синтактично оцветяване за по-лесно визуално възприемане на кода и намаляване на грешките, автоматично довършване на започнат израз, автоматично извеждане на помощна информация по време на писане, средства за навигация по кода и много други.

Поддържа се IntelliSense функционалност за подсказване на имена на класове, методи и променливи. Тя предоставя огромно улеснение за навлизащите тепърва .NET програмисти, тъй като позволява те да разгледат на място възможностите и да изберат от списък тази, която ги интересува. Така се спестяват усилия, време за изписване на името и се намалява значително вероятността за досадни "правописни" грешки.

Следващата илюстрация дава нагледна представа за редактора на код на Visual Studio .NET 2003:

Създаване на потребителски интерфейс

Visual Studio .NET 2003 предоставя удобен за работа графичен дизайнер за потребителски интерфейси. С него за няколко минути можем да изградим дизайна на даден потребителски интерфейс, независимо дали става дума за Windows Forms прозорец, уеб страница или интерфейс за мобилни приложения.

Това, което виждаме във VS.NET докато изграждаме потребителския интерфейс, е почти същото, което и потребителят ще види, когато стартира приложението. Начинът на работа с различните технологии за представяне на потребителски интерфейс е много подобен и това допълнително улеснява разработчиците и повишава тяхната продуктивност.

Добавянето на визуални компоненти (или потребителски контроли) става чрез влачене и пускане (drag and drop), а след това ни остава само да настроим нужните свойства на обекта със желаните от нас стойности и да добавим обработчици към някои от събитията.

Ето изглед от VS.NET в момент на редактиране на диалог от Windows Forms приложение:

Компилиране

Visual Studio .NET 2003 предлага унифициран начин за работа с компилаторите за различните езици. Не се налага да използваме командния ред и да знаем дългия списък с инструкции към компилатора за да можем да компилираме кода и да създаваме асемблита. Достатъчно е на натиснем [Shift+Ctrl+B] за да компилираме цялото решение с всички проекти в него.

При компилация VS.NET автоматично създава нужните асемблита и ресурсни файлове. Tя се грижи и за сателитните асемблита (ако има такива), опреснява референциите към външни файлове и класове и изпълнява още много други задачи.

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

Едно ограничение, което VS.NET има, е че то не може да създава многофайлови асемблита. Ако това наистина ни се наложи трябва да използваме инструмента Assembly Linker (al.exe).

VS.NET предлага два режима на компилация:

- Debug – в този режим компилаторът създава дебъг символи за всички методи в приложението и ги записва в отделен файл с разширение .pdb. Чрез него можем да извършваме проследяване на грешките (debugging). Този режим на компилация е препоръчителен за процеса на разработване и тестване на приложението.

- Release – в този режим на компилация VS.NET създава код, готов за продукция и разпространение до клиентите. От него са отстранени всички функции свързани с дебъгване и тестване. Не се генерират .pdb файлове и като цяло има по-добра производителност от Debug версията. За сметка на това възможностите за откриване грешки са намалени.

Изпълняване и тестване

Тъй като Visual Studio .NET интегрира в себе си разработването на приложения с различни технологии, ние можем да стартираме по унифициран начин всеки един от типовете приложения. Това, което трябва да направим, е единствено да натиснем бутона Start (или Debug/Start). Средата проверява дали има промени във файловете на проекта, ако има такива, тя прекомпилира приложението и след това стартира съответния процес.

VS.NET поддържа т. нар. решения (solutions). В едно решение може да има един или повече проекта. Например в една система може да 3 проекта – уеб услуга, Windows Forms клиент и ASP.NET уеб приложение.

Имаме възможност да указваме проект, който да се стартира при стартиране на решението. Допълнително можем да укажем да се стартират множество проекти при натискане на бутона Start. Тази опция е много удобна при разработване на клиент-сървър приложения, тъй като не ни се налага ръчно да стартираме всеки компонент.

Тестването на приложенията може да се извършва веднага след стартирането. Тъй като Visual Studio .NET 2003 се "закача" в дебъг режим към процеса на стартираното приложението, можем да дебъгваме лесно и бързо своя код.

Проследяване на грешки

Процесът на проследяване на грешки, или както по-често го наричаме дебъгване, се осъществява много лесно със Visual Studio .NET 2003. Средата ни предоставя множество вградени в нея инструменти, с които да извършваме тази задача. Инструментите са достъпни от менюто Debug и включват следните възможности:

- Breakpoints – списък със зададените точки на прекъсване (break points). Можем да премахваме, създаваме и настройваме параметрите на всяка точка поотделно.

- Running documents – списък с всички файлове, които се използват от приложението в момента. Използва се главно при дебъгване на уеб приложения.

- Call stack – показва ни стекът на извикванията на методите до дадения момент. Перфектен е за анализ на програмна логика и намиране на мястото, където е възникнало изключение.

- Autos – показва всички променливи, които са в момента в обхват.

- Local – показва всички локални променливи.

- Immediate/Command Window – позволява ни да изпълняваме инструкции и да променяме стойности на променливи по време на изпълнение. Предоставя множество мощни възможности, които обаче излизат извън рамките на нашата тема.

- Watch – показва списък с всички променливи, които сме заявили, че искаме да наблюдаваме. Чрез него можем и да променяме техните стойности по време на изпълнение на програмата.

- Quick Watch – показва стойността на избрана при дебъгване променлива.

- Step control – дава ни средства за постъпково изпълнение на кода ред по ред и стъпка по стъпка. Можем да избираме реда на изпълнение; да изпълняваме методи като влизаме в тях или ги изчакваме да завършват и преминаваме към следващата стъпка; можем да контролираме и кои редове от кода се изпълняват и при нужда да местим курсора на изпълнение напред и назад.

- Exception control – можем да задаваме дали нашето приложение да влиза в дебъг режим при възникване на изключение и да спира веднага след мястото на възникване на изключението без да сме сложили точка на прекъсване.

Освен тези удобства имаме възможност да разглеждаме съдържанието на паметта и регистрите в "суров" вид и да извършваме декомпилация на кода (disassembling).

Създаване на инсталационен пакет

Освен стандартните шаблони за всеки език за програмиране Visual Studio .NET 2003 ни предлага и шаблони за инсталационни пакети. Така се затваря цикълът на разработка на приложения. Можем да използваме готовите стандартни форми и технологии на инсталация и/или да добавим свои собствени към инсталационния пакет. След като сме завършили и тази стъпка, можем да разпространяваме своето приложение до крайните потребители.

Технологиите на инсталиране, които ни предлага Visual Studio .NET 2003, са приложими за почти всякакви приложения, независимо от това дали са конзолни, Windows Forms, уеб приложения или библиотеки с типове. Процеса на създаване на инсталационни пакети е разгледан подробно в темата "Асемблита и разпространение".

Получаване на помощ

При инсталиране на Visual Studio .NET с него се инсталира неговата документация и по желание документацията на Microsoft .NET Framework (т.нар. MSDN Library).

Те автоматично се интегрират в средата за разработка и позволяват да получим т. нар. контекстно-ориентирана помощ. Например, докато използваме даден клас от .NET Framework, VS.NET ни показва неговата документация в прозореца Dynamic Help. Интегрираната помощна система във VS.NET позволява при натискане на клавиша [F1] да получим информация за текущия клас, свойство или компонент, който е на фокус. Това значително улеснява разработчика.

VS.NET е силно разширяема среда

Интегрираната среда за разработка Microsoft Visual Studio .NET е така проектирана, че лесно да може да се разширява с допълнителни модули и нови възможности. Съществуват стотици добавки (plug-ins) за VS.NET, които добавят поддръжка на нови езици и нови технологии, подпомагат процеса на разработка по различни начини, добавят интеграция с други продукти и т. н. Някои от тях са свободни, докато други са комерсиални продукти. Благодарение на добре документираните програмни интерфейси за интеграция с VS.NET програмистите могат да добавят и собствени добавки за средата.

Упражнения

1. Опишете накратко платформата Microsoft .NET. Кои са основните принципи, които са заложени в нея? Избройте четирите компонента, от които тя се състои.

2. Какво представляват .NET Enterprise сървърите? Избройте някои от тях. Какво представлява .NET Framework? От какви компоненти се състои? Какво е Visual Studio .NET? За какво служат .NET Building Block услугите? Какво са .NET Smart клиентите? Какво е характерно за тях?

3. Опишете накратко .NET Framework. От какви компоненти се състои?

4. Какво представлява средата за контролирано изпълнение на програмен код Common Language Runtime (CLR)?

5. Какво представлява Framework Class Library (FCL)? Каква функционалност предлага тя?

6. Какво е управляван код? Има ли причина да бъде използван вместо традиционния машиннозависим код? Какво е характерно за междинния език IL?

7. Какво представляват .NET асемблитата (assemblies)? Каква информация съдържат метаданните в асемблитата? Какво представляват .NET приложенията? Какво е област на приложението (application domain)?

8. Какво е Common Language Specification (CLS)? Защо е необходима тази спецификация? Какво описва тя?

9. Какво представлява общата система от типове в .NET Framework (Common Type System)? Защо е необходима тя?

10. Избройте няколко от .NET езиците. Какво е общото между тях? Какво е специфичното за всеки от тях?

11. Избройте основните пакети от Framework Class Library (FCL). За какво служат те?

Използвана литература

1. Светлин Наков, Архитектура на платформата .NET и .NET Framework – http://www.nakov.com/dotnet/lectures/Lecture-1-MS.NET-Framework-Architecture-v1.03.ppt

2. Jeffrey Richter, Applied Microsoft .NET Framework Programming, Microsoft Press, 2002, ISBN 0735614229

3. MSDN, Common Language Runtime Overview – http://msdn.microsoft. com/library/en-us/cpguide/html/ cpconcommonlanguageruntimeoverview.asp

4. MSDN, Compiling to MSIL – http://msdn.microsoft.com/library/en-us/ cpguide/html/cpconMicrosoftIntermediateLanguageMSIL.asp

5. MSDN, Application Domains Overview – http://msdn.microsoft.com/ library/en-us/cpguide/html/cpconapplicationdomainsoverview.asp

Глава 2. Въведение в C#

Необходими знания

- Добро познаване на поне един език за програмиране от високо ниво (С, С++, Java, Pascal/Delphi, Perl, Python, PHP или друг)

- Базови познания за архитектурата на .NET Framework

Съдържание

- Принципи при дизайна на езика

- Нашата първа програма на C#

- Типове данни в C#. Примитивни типове данни. Изброен тип

- Декларации. Изрази. Оператори. Програмни конструкции

- Елементарни програмни конструкции. Съставни конструкции

- Конструкции за управление – условни конструкции, конструкции за цикъл, конструкции за преход. Специални конструкции

- Коментари в програмата

- Вход и изход от конзолата

- Дебъгерът на Visual Studio .NET

- XML документация в C# кода

В тази тема...

В настоящата тема ще разгледаме езика С#, ще се запознаем с неговите основни концепции, ще напишем и компилираме първата си C# програма. Ще се запознаем със средата за разработка Visual Studio .NET 2003 и ще демонстрираме работата с нейния дебъгер. Ще отделим внимание на типовете данни, изразите, програмните конструкции и конструкциите за управление в езика C#. Накрая ще демонстрираме колко лесно и полезно е XML документирането на кода в С#.

Настоящата тема има за цел да запознае читателя с конкретните синтактични правила на езика C# и неговите програмни конструкции без да претендира за изчерпателност. В нея няма да обясняваме какво е променлива, функция, цикъл и т. н., а ще се фокусираме върху реализацията на тези езикови примитиви в C#. Очаква се читателят да владее основите на програмирането с поне един език от високо ниво, а тази тема ще му помогне да премине към C#.

Какво е C#

С# е съвременен, обектно-ориентиран и типово обезопасен език за програмиране, който е наследник на C и С++. Той комбинира леснотата на използване на Java с мощността на С++.

Създаден от екипа на Андерс Хейлсбърг, архитектът на Delphi, С# заимства много от силните страни на Delphi – свойства, индексатори, компонентна ориентираност. С# въвежда и нови концепции – разделяне на типовете на два вида – стойностни (value types) и референтни (reference types), автоматично управление на паметта, делегати и събития, атрибути, XML документация и други. Той е стандартизиран от ECMA и ISO.

C# е специално проектиран за .NET Framework и е съобразен с неговите особености. Той е сравнително нов, съвременен език, който е заимствал силните страни на масово използваните езици за програмиране от високо ниво, като C, C++, Java, Delphi, PHP и др.

Принципи при дизайна на езика C#

Преди да се запознаем със синтаксиса и програмните конструкции в C#, нека първо разгледаме основните принципи, залегнали при проектирането му.

Компонентно-ориентиран

Езикът C# е насочен към компонентно-ориентираното програмиране, при което софтуерът се изгражда чрез съединяване на различни готови компоненти и описание на логиката на взаимодействие между тях.

При проектирането на .NET Framework и езика C# компонентният подход е залегнал на най-дълбоко архитектурно ниво. .NET Framework дефинира общ компонентен модел, който установява правилата за изграждане и използване на компоненти за всички .NET приложения. Езикът C# поддържа класове, интерфейси, свойства, събития и други средства за описание на компонентите, както и средства за тяхното използване. В темата "Графичен потребителски интерфейс с Windows Forms" ще дискутираме по-задълбочено компонентния модел на .NET Framework.

Всички данни са обекти

С# е обектно-ориентиран език за програмиране. В него залягат основните принципи на обектно-ориентираното програмиране, като капсулация на данните, наследяване и полиморфизъм.

В .NET Framework всички типове данни наследяват системния тип System. Object и придобиват от него някои общи методи, свойства и други характеристики.

В следствие на това в C# всички данни се третират като обекти. Дори примитивните типове, чрез въвеждането на автоматичното им опаковане (boxing) и разопаковане (unboxing) се превръщат в обекти. Например, 5.ToString() е валидно извикване в C#, защото 5 се опакова и се разглежда като обект от тип System.Object, на който се извиква метода ToString().

Сигурност и надеждност на кода

По идея .NET Framework и C# са проектирани за да осигурят висока сигурност и надеждност на изпълнявания софтуер. .NET Framework предоставя среда за контролирано изпълнение на управляван код, с което прави невъзможно възникването на някои от най-неприятните проблеми, свързани с управлението на паметта, неправилното преобразуване на типове и др. C# наследява всички тези характеристики от .NET Framework и добавя към тях някои допълнителни механизми за предпазване на програмистите от често срещани грешки.

Силна типизираност и типова безопасност

С# е силно типизиран и типово обезопасен. В него не се използват указатели към паметта, които създават много проблеми в по-старите езици за програмиране. Вместо тях се използват специални силно типизирани указатели, които се наричат референции (references). Използването на референции вместо указатели решава проблемите, които възникват от неправилната работа с указатели и директния достъп до паметта. В .NET Framework управлението на паметта се извършва почти изцяло от CLR.

Всъщност в C# може да се използват указатели (като тези в C и C++) чрез запазената дума unsafe, но това не е се препоръчва в масовия случай, защото лишава програмата от типова обезопасеност и позволява неправилна работа с паметта.

В С# не може да се излезе от границите на масив или символен низ. При опит да бъде направено това, се получава изключение, което може да бъде прихванато и обработено. В езици като C, C++ и Pascal излизането от границите на масив води до достъп до памет, използвана от други данни и най-често пъти предизвиква сривове или неочаквано поведение на програмата.

При създаване на клас, структура или друг тип C# компилаторът не позволява да останат неинициализирани член-данни. Това защитава програмиста от възможността да работи с неинициализирани данни.

Макар С# да не инициализира автоматично локалните променливи, компилаторът предупреждава за неправилното им използване. Например следният код ще предизвика грешка при опит за компилация:

int value;

value = value + 5;

Преобразуването на типове също е безопасно. CLR не позволява да се извърши невалидно преобразуване на типове – да се преобразува променлива от даден тип към променлива от тип, който не е съвместим с първия. При опит да бъде направено това, възниква изключение.

Неявното преобразуване на типове е разрешено само за съвместими типове, когато не е възможна загуба на информация. При явно преобразуване на типове, ако те не са съвместими, се хвърля InvalidCastException по време на изпълнение. Например следният код предизвиква изключение по време на изпълнение:

object a = "This will raise InvalidCastException!";

int b = (int) a;

Безопасност на аритметичните операции

В C# чрез запазената дума checked могат да се отделят блокове код, в които аритметичните операции се проверяват за препълване на типовете и ако това се случи, се хвърля OverflowException. Това е много полезно, защото за разлика от С++, където при такива ситуации се получава грешен резултат, в С# може да се реагира адекватно на такава специфична ситуация. Ето един пример, при който CLR засича препълване на типа int:

checked

{

int i = 100000;

int j = i*i; // OverflowException is thrown

}

Експлицитно задаване на виртуални методи и припокриване на метод

Една от целите на езика C# е да позволи с малко усилия да се пише надежден код. С цел да се намалят грешките от припокриване на виртуални методи са въведени запазените думи new и override, чрез които да се контролира припокриването на виртуален метод, който е в базов клас при наследяване. Каква е разликата между двете? При полиморфизъм (обект от базовия клас е създаден като обект от наследника), ако е използвана new като модификатор на метода в наследника, ще се извика функцията на базовия клас, а при използване на override – функцията на наследника.

Автоматично управление на паметта и ресурсите

В .NET Framework заделянето и използването на паметта се управлява автоматично от CLR (Common Language Runtime). Стойностните типове, които ще разгледаме по-подробно в темата "Обща система от типове", се пазят в стека, докато референтните – в т. нар. "динамична памет" (managed heap), за която се грижи системата за почистване на паметта (garbage collector).

Системата за почистване на паметта е част от CLR и нейна задача е да освобождава периодично паметта и ресурсите, заделени за обекти, които не се използват повече от приложението. Такива обекти могат да бъдат най-разнообразни: данни в динамичната памет, масиви, символни низове, а също и файлове, буфери в паметта, връзки към бази данни и др.

Грижата за паметта е трудна и сложна задача, но благодарение на CLR тя не е задължение на .NET програмистите. На нея ще обърнем специално внимание в темата "Управление на паметта и ресурсите".

Широко използване на изключения

Обработката на грешки, които могат да възникнат по време на изпълнение на програмата, в .NET Framework се реализира чрез използване на изключения. Механизмът на изключенията позволява да се съобщи за възникнал проблем или неочаквана ситуация и за нея да може да се реагира адекватно.

Изключенията представляват обекти от клас Exception или производен на него клас и съдържат информация за възникналата грешка. Например, при опит за деление на нула CLR прихваща проблема и предизвиква изключението DivideByZeroException, а при опит за излизане от границите на масив възниква ArgumentOutOfRangeException. Работата с изключения също ще бъде дискутирана в детайли в темата "Управление на изключенията в .NET".

Вградени механизми за сигурност на кода

В .NET Framework са въведени т. нар. сигурност на ниво достъп до кода (code access security) и сигурност, базирана на роли (role-based security). Чрез тях се осъществява контрол на достъпа до ресурси от програмата. Например, ако трябва да се извика системна функция или да се пише във файл, кодът трябва да има права да го направи. Сигурността на ниво достъп до кода оставя CLR да взима решения, докато при сигурност, базирана на роли, програмата може да реагира различно спрямо ролята и правата на потребителя.

Всичкият код е на едно място

В С# няма разделяне на хедър файлове и файлове с имплементация, както в C и C++. Това спестява много проблеми и улеснява поддръжката на сорс кода. В C# всичкият програмен код на даден клас е в един файл.

Програмите на C#

Програмите на С# представляват съвкупност от дефиниции на класове, структури и други типове. Във всяка C# програма някой от класовете съдържа метод Main() – входна точка за програмата.

Приложенията могат да се състоят от много файлове, а в един файл може да има няколко класове, структури и други типове.

Класовете логически се разполагат в пространства от имена (namespaces). Те от своя страна могат да се систематизират в йерархия, т.е. едно пространство от имена може да съдържа както класове, така и други пространства от имена. Едно пространство от имена може да е разположено в няколко файла и дори в няколко асемблита. Например, в пространството от имена System се съдържа пространството от имена Xml. Пространството System.Xml от своя страна е разделено в две различни асемблита - System.Xml.dll и System.Data.dll.

Във Visual Studio .NET има инструмент, наречен "Object Browser", чрез който могат да се разгледат йерархиите на пространствата от имена в проекта, какво съдържат те и в кои файлове се намират.

Нашата първа програма на C#

Всяка книга за запознаване с даден програмен език започва обикновено с програмката "Hello, world!". Ние няма да правим изключение от този принцип и ще започнем по подобен начин – с програмката "Hello, C#". Ето как изглежда нейният сорс код:

HelloCSharp.cs

using System;

class HelloCSharp

{

static void Main()

{

Console.WriteLine("Hello, C#");

}

Как работи програмата?

На първия ред директивата using System указва, че се използва пространството от имена System (т.е. всички класове, структури и други типове, декларирани в него). Тя е като #include в C++, като import в Java и като uses в Delphi.

Следва декларацията на клас с ключова дума class. Този клас се състои от един единствен метод – методът static void Main(), който е входна точка на програмата. Когато този метод завърши, завършва и програмата.

В метода Main() се извиква метода WriteLine(…) на класа Console, намиращ се в пространството от имена System. Класът Console осигурява средства за вход и изход от конзолата. Чрез него отпечатваме на конзолата текста "Hello, C#".

Компилиране от командния ред

Програми на C# могат да се компилират от командния ред чрез компилатора csc.exe, който е стандартна част от .NET Framework и е достъпен от директорията, в която е инсталиран той. При стандартна инсталация тя е C:\Windows\Microsoft.NET\Framework\v1.1.4322.

Можем да компилираме сорс кода на примерната програма по следния начин: Използвайки командния интерпретатор (cmd.exe) се придвижваме до директорията, където се намира файлът HelloCSharp.cs. След това можем да го компилираме със следната команда:

csc HelloCSharp.cs

За да бъде намерен компилаторът csc.exe, е необходимо в текущия път (в променливата PATH от средата) да е включена директорията на .NET Framework.

Ако компилацията премине успешно, в резултат се получава файлът HelloCSharp.exe, който представлява .NET асембли, записано като изпълним файл.

Стартиране от командния ред

Стартирането на получения изпълним (.exe) файл става както всички останали изпълними файлове, например чрез следната команда:

HelloCSharp.ехе

Резултатът

Резултатът от изпълнението на нашата първа C# програмка представлява един текстов ред:

Hello, C#

Резултатът от компилирането и изпълнението на примерната програма е показан на следващата картинка:

Създаване на проект, компилиране и стартиране от Visual Studio.NET

Ще покажем как може да се използва интегрираната среда за разработка на приложения Microsoft Visual Studio .NET за изпълнение на предходната примерна програмка. Ще създадем нов проект (конзолно приложение), ще го компилираме и изпълним. Трябва да преминем през следните стъпки:

1. Стартираме Visual Studio .NET.

2. От меню File избираме New Project. Избираме Visual C# Projects | Console Application. Избираме име и местоположение за проекта:

Visual Studio .NET създава за нас един Solution и един проект в него, съдържащ няколко файла. Файлът, в който можем да пишем нашия код, се отваря автоматично.

3. Въвеждаме примерната програмка. Можем да сменим името на файла Class1.cs с HelloCSharp.cs чрез клавиша [F2], натиснат в момент, в който е активен файлът Class1.cs от Solution Explorer:

4. За да компилираме, натискаме [Shift+Ctrl+B] или избираме менюто Build | Build Solution. Ето как изглежда VS.NET в този момент:

5. За да стартираме приложението, натискаме [Ctrl+F5] или избираме от менюто Debug | Start Without Debugging. В резултат приложението се изпълнява в нов конзолен прозорец и след приключване на работата му VS.NET ни приканва да натиснем някакъв клавиш, за да затвори прозореца:

Можем да стартираме приложението и само с [F5], но тогава то ще се изпълни в режим на дебъгване и след приключване на работата му прозорецът, в който е изведен резултата, веднага ще се затвори и няма да го видим.

Запазени думи в C#

Езикът C# дефинира следните запазени думи, които се използват в конструкциите и синтаксиса на езика:

abstract	as	base	bool	break	byte
case	catch	char	checked	class	const
continue	decimal	default	delegate	do	double
else	enum	event	explicit	extern	false
finally	fixed	float	for	foreach	goto
if	implicit	in	int	interface	internal
is	lock	long	namespace	new	null
object	operator	out	override	params	private
protected	public	readonly	ref	return	sbyte
sealed	short	sizeof	stackalloc	static	string
struct	switch	this	throw	true	try
typeof	uint	ulong	unchecked	unsafe	ushort
using	virtual	void	volatile	while

Ще видим за какво служат повечето от тях постепенно, в процеса на запознаване с езика C#, с обектно-ориентираното програмиране в .NET Framework, с общата система от типове и в някои други теми.

Типове данни в C#

Типовете данни в C# биват два вида – типове по стойност (value types) и типове по референция (reference types). Типовете по стойност (стойностни типове) директно съдържат своята стойност и се съхраняват в стека. Те се предават по стойност. Типовете по референция (референтни типове) представляват силно типизирани указатели към стойност в динамичната памет. Те се предават по референция (адрес) и се унищожават от garbage collector, когато не се използват повече от програмата.

Типовете биват още примитивни (вградени, built-in) типове и типове, дефинирани от потребителя.

Стойностни типове (value types)

Типовете по стойност (стойностни типове) са примитивните типове, изброените типове и структурите. Например:

int i; // примитивен тип int

enum State { Off, On } // изброен тип (enum)

struct Point { int x, y; } // структура (struct)

Референтни типове (reference types)

Типовете по референция (референтни типове) са класовете, интерфейсите, масивите и делегатите. Например:

class Foo: Bar, IFoo {...} // клас

interface IFoo: IBar {...} // интерфейс

string[] a = new string[5]; // масив

delegate void Empty(); // делегат

На всички типове в C# съответстват типове от общата система от типове (Common Type System – CTS) на .NET Framework. Например, на примитивния C# тип int съответства типа System.Int32 от CTS.

Примитивни типове

Примитивните типове данни в C# (built-in data types) биват:

Примитивни типове по стойност

- byte, sbyte, int, uint, long, ulong – цели числа

- float, double, decimal – реални числа

- char – Unicode символи

- bool – булев тип (true или false)

Примитивни типове по референция

- string – символен низ (неизменима последователност от Unicode символи)

- object – обект (специален тип, който се наследява от всички типове)

Типове дефинирани от потребителя

Типовете дефинирани от потребителя биват класове, структури, изброени типове, интерфейси и делегати:

class Foo: Bar, IFoo {...} // клас

struct Point { int x, y; } // структура

interface IFoo: IBar {...} // интерфейс

delegate void Empty(); // делегат

Вече се сблъскахме с класовете в C# в примерната програма "Hello, C#". Повече за тях, както и за структурите и интерфейсите ще научим в темата "Обектно-ориентирано програмиране в .NET".

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

Има два типа преобразувания на примитивните типове – преобразуване по подразбиране (implicit conversion) и изрично преобразуване (explicit conversion).

В C# преобразуването по подразбиране е позволено, когато е безопасно. Например, от int към long, от float към double, от byte към short:

short a = 10;

int b = a; // implicit type conversion from short to int

Изричното преобразуване се използва, когато преобразуваме към по-малък тип или типовете не са директно съвместими. Например, от long към int, от double към float, от char към short, от int към char, от sbyte към uint:

int a = 10;

short b = (short) a; // explicit type conversion

В С# има специална ключова дума checked, която указва при препълване да се получава System.OverflowException вместо грешен резултат. Ключовата дума unchecked действа противоположна на checked. Ето пример за преобразуване на типове с използване на тези ключови думи:

byte b8 = 255;

short sh16 = b8; // implicit conversion

int i32 = sh16; // implicit conversion

float f = i32; // implicit - possible loss of precision!

double d = f; // implicit conversion

checked

{

byte byte8 = (byte) sh16; // explicit conversion

// OverflowException is possible!

ushort ush16 = (ushort) sh16; // explicit conversion

// OverflowException is possible if sh16 is negative!

}

unchecked

{

uint ui32 = 1234567890;

sbyte sb8 = (sbyte) ui32; // explicit conversion

// OverflowException is not thrown in unchecked mode

}

Изброени типове (enumerations)

Изброените типове в C# се състоят от множество именувани константи. Дефинират се със запазената дума enum и наследяват типа System.Enum. Ето пример за изброен тип, който съответства на дните от седмицата:

public enum Days

{

Saturday,

Sunday,

Monday,

Tuesday,

Wednesday,

Thursday,

Friday

};

Изброените типове се използват за задаване на една измежду няколко възможности. Вътрешно се представят с int, но може да се зададе и друг числов тип.

Изброените типове са силно типизирани – те не се превръщат в int, освен експлицитно.

Ето пример как може да бъде използван даден изброен тип:

Days today = Days.Friday;

if (today == Days.Friday)

{

Console.WriteLine("Днес е петък.");

}

Както се вижда, инстанциите на изброените типове могат да приемат една от дефинираните в тях стойности.

Изброените типове могат да се използват и като съвкупност от битови флагове чрез атрибута [Flags]. Ето пример за изброен тип, който може да приема за стойност комбинация от дефинираните в него константи:

[Flags]

public enum FileAccess

{

Read = 1,

Write = 2,

Execute = 4,

ReadWrite = Read | Write

}

// ...

Console.WriteLine(

FileAccess.ReadWrite | FileAccess.Execute);

// The result is: "ReadWrite, Execute"

Какво представляват атрибутите и как се използват ще разгледаме по-детайлно в темата "Атрибути". Засега трябва да знаем, че чрез тях може да се асоциира допълнителна информация към типовете.

Използването на изброени типове осигурява по-високо ниво на абстракция и по този начин сорс кодът става по-разбираем и по-лесен за поддръжка.

В .NET Framework широко се използват изброени типове. Например, изброения тип ConnectionState, намиращ се в пространство от имена System.Data, характеризира състоянието на връзка към база от данни, създадена чрез ADO.NET (зададено е и числовото съответствие на всяко едно от състоянията):

public enum ConnectionState

{

Closed = 0,

Open = 1,

Connecting = 2,

Executing = 4,

Fetching = 8,

Broken = 16

}

Идентификатори

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

int алабала_портокала = 42;

bool \u1027\u11af = true;

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

- PascalCase – за имена на класове, пространства от имена, структури, типове, методи, свойства, константи

- camelCase – за имена на променливи и параметри

Въпреки, че е възможно, не се препоръчва да се използват идентификатори на кирилица или друга азбука, различна от латинската.

Декларации

Декларациите на променливи в C# могат да са няколко вида (почти като в C++, Java и Delphi) – локални променливи (за даден блок), член-променливи на типа и константи. Ето пример:

int count;

string message;

Член-променливите могат да имат модификатори, например:

public static int mCounter;

Константи

Константите в С# биват два вида – константи, които приемат стойността си по време на компилация (compile-time константи) и такива, които получават стойност по време на изпълнение на програмата (runtime константи).

Compile-time константи

Compile-time константите се декларират със запазената дума const. Те задължително се инициализират в момента на декларирането им и не могат да се променят след това. Те реално не съществуват като променливи в програмата. По време на компилация се заместват със стойността им. Например:

public const double PI = 3.1415926535897932;

const string COMPANY_NAME = "Менте Софт";

Runtime константи

Runtime константите се декларират като полета с модификатора readonly. Представляват полета на типа, които са само за четене. Инициализират се по време на изпълнение (в момента на деклариране или в конструктора на типа) и не могат да се променят след като веднъж са инициализирани. Например:

public readonly DateTime NOW = DateTime.Now;

Оператори

Операторите в С# са много близки до операторите в C++ и Java и имат същите действие и приоритет. Те биват:

- Аритметични: +, -, *, /, %, ++, --

- Логически: &&, ||, !, ^, true, false

- Побитови операции: &, |, ^, ~, <<, >>

- За слепване на символни низове: +

- За сравнение: ==, !=, <, >, <=, >=

- За присвояване: =, +=, -=, *=, /=, %=, &=, |=, ^=, <<=, >>=

- За работа с типове: as, is, sizeof, typeof

- Други: ., [], (), ?:, new, checked, unchecked, unsafe

В C# операторите могат да се предефинират. В темата "Обектно-ориентирано програмиране в .NET" ще видим как точно става това.

Изрази (expressions)

Програмен код, който се изчислява до някаква стойност, се нарича израз (expression). Изразите в C# имат синтаксиса на C++ и Java. Например:

a = b = c = 20; // израз със стойност 20

(а+5)*(32-a)%b // израз с числова стойност

"ала" + "бала" // символен израз (string)

Math.Cos(Math.PI/x) // израз с реална стойност

typeof(obj) // израз от тип System.Type

(int) arr[idx1][idx2] // израз от тип int

new Student() // израз от тип Student

(currentValue <= MAX_VALUE) // булев израз

Програмни конструкции (statements)

Програмните конструкции (statements) имат синтаксиса на C++ и Java. Те биват няколко вида:

Елементарни програмни конструкции

Елементарните програмни конструкции са най-простите елементи на програмата. Например:

// присвояване (<променлива> = <израз>)

sum = (a+b)/2;

// извикване на метод

PrintReport(report);

// създаване на обект

student = new Student("Светлин Наков", 3, 42688);

Съставни конструкции

Съставните програмни конструкции се състоят от няколко други конструкции, оградени в блок. Например:

{

Report report = GenerateReport(period);

report.Print();

}

Програмни конструкции за управление

Конструкциите за управление, както в повечето езици за програмиране, биват условни конструкции, конструкции за цикъл, за преход и т. н. В C# синтаксисът на тези конструкции е много близък до синтаксиса на C++ и Java.

Условни конструкции (conditional statements)

Условните конструкции в С# са if, if-else и switch. Техният синтаксис е еднакъв със синтаксиса им в C, C++ и Java.

if и if-else конструкциите за разлика от С и С++ могат да приемат единствено булево условие. Не са позволени целочислени стойности, които да играят ролята на true, ако са различни от 0 и false – иначе. Ето няколко примера за условна конструкция:

if (orderItem.Ammount > ammountInStock)

{

MessageBox.Show("Not in stock!", "error");

}

if (Valid(order))

{

ProcessOrder(order);

}

else

{

MessageBox.Show("Invalid order!", "error");

}

Ново в switch конструкцията за разлика от C и C++ е, че позволява изразът, по който се осъществява условието, да бъде от тип string или enum. Например:

switch (characterCase)

{

case CharacterCasing.Lower:

text = text.ToLower();

break;

case CharacterCasing.Upper:

text = text.ToUpper();

break;

default:

MessageBox.Show("Invalid case!", "error");

break;

}

Конструкцията switch се различава от реализацията си в С++. В С# не се разрешава "пропадане" (fall-through). Пропадането в switch конструкциите може да доведе до грешки. Независимо от удобствата, които предлага тази възможност, дизайнерите на езика С# са преценили, че рискът за грешка поради пропускане на break е по-голям, затова всеки case етикет трябва задължително да завършва с break.

Конструкции за повторение и цикъл

Конструкциите за повторение (iteration statements) са for-цикъл, while-цикъл, цикъл do-while и цикъл foreach – за обработка на колекции. Техният синтаксис е еднакъв със синтаксиса им в C, C++ и Java. Изключение прави foreach цикълът, който няма еквивалент в C и C++. Ето няколко примера:

Пример за for-цикъл:

// Отпечатваме числата от 1 до 100 и техните квадрати

for (int i=1; i<=100; i++)

{

int i2 = i*i;

Console.WriteLine(i + " * " + i + " = " + i2);

}

Пример за while-цикъл:

// Изчисляваме result = a^b

result = 1;

while (b > 0)

{

result = result * a;

b--;

}

Пример за цикъл do-while:

// Четем символи до достигане на край на ред

{

ch = ReadNextCharacter(stream);

}

while (ch != '\n');

Операторът foreach е приложим за масиви, колекции и други типове, които поддържат интерфейса IEnumerable или имaт метод за извличане на итератор (enumerator).

Пример за цикъл foreach:

string[] names = GetNames();

// Отпечатваме всички елементи на масива names

foreach (string name in names)

{

Console.WriteLine(name);

}

Конструкции за преход

Конструкциите за преход в C# са: break, continue – които се използват в цикли, goto – за безусловен преход и return – за връщане от метод. Те работят по същия начин, като в C, C++ и Java.

Пример за използване на конструкцията break:

// Търсим позицията на даден елемент target в масива a[]

int position = -1;

for (int i=0; i<a.length; i++)

{

if (a[i] == target)

{

position = i;

break;

}

return position;

Конструкции за управление на изключенията

Конструкциите за управление на изключенията в С# са: throw – за предизвикване на изключение, try-catch – за прихващане на изключение, try-finally – за сигурно изпълнение на завършваща секция и try-catch-finally – за прихващане на изключение със завършваща секция.

Пример за предизвикване и прихващане на изключение:

// ...

public static void ThrowException()

{

// ...

throw new System.Exception();

}

// ...

public static void Main()

{

try

{

ThrowException();

}

catch(System.Exception e)

{

// ...

}

finally

{

// ...

}

Методът ThrowException() предизвиква изключение от тип Exception, което може да бъде прихванато, ако функцията, която го предизвиква, се намира в try-catch блок. В такъв случай може да се извършат действия в catch блока, в зависимост от информацията, която носи това изключение.

Конструкциите try-finally и try-catch-finally се използват най-вече за освобождаване на ресурси, които се използват в тялото им. Независимо дали възникне изключение при работата с даден ресурс, той трябва да бъде освободен накрая – това обикновено се прави във finally блок, който се изпълнява независимо дали се минава през catch блока. Блокът finally се изпълнява дори и да има return в catch или try блок.

В темата "Управление на изключенията в .NET" ще разгледаме подробно работата с изключения, техните особености и препоръките за правилна работа с тях.

Специални конструкции

Специалните конструкции в С# са: lock – за синхронизирано изпълнение, checked, unchecked – за контрол на аритметичните препълвания, unsafe – за директен достъп до паметта чрез указатели, fixed – за фиксиране на местоположението в паметта при работа с неуправляван код.

Коментари в програмата

Коментарите биват два вида - коментар за част от програмен ред и блоков коментар.

Ето пример за коментар на един ред:

Order orders[]; // Съдържа всички поръчки на потребителя

Ето пример и за блоков коментар:

/* Изтриваме всички поръчки, за които някой артикул не

е наличен в необходимото количество. Изтриване реално

не се извършва, а само се променя статуса на Canceled */

foreach (Order order in customer.Оrders)

{

if (!AllItemsInStock(order))

{

order.Status = OrderStatus.Canceled;

}

Вход и изход от конзолата

В .NET Framework за вход и изход от конзолата се използват стандартни класове от BCL (Base Class Library). Входът и изходът от конзолата се осъществяват чрез класа Console, намиращ се в пространство от имена System.

Класът System.Console предоставя основната функционалност, от която се нуждаят конзолните приложения (console applications), които четат и пишат на екрана. Ако конзолата не съществува (например в Windows Forms и уеб-базираните приложения), писането в конзолата няма никакъв ефект и не се предизвикват изключения.

Всяко конзолно приложение при стартиране получава от операционната система три стандартни потока – за вход, изход и за грешки. При изпълнение от конзолата тези три потока автоматично се асоциират със самата нея. За достъп до стандартния вход, стандартния изход и стандартния изход за грешки в .NET Framework се използват свойствата In, Out и Error на класа Console.

Вход от конзолата

Входът от конзолата се осъществява чрез два метода на класа Console - Read() и ReadLine(). Методът Read() чете единичен символ от стандартния вход и го връща като int стойност или връща -1, ако няма повече символи. Методът ReadLine() чете цял символен ред и връща string или стойност null ако е достигнат края на входа.

И двата метода са синхронни (блокиращи) операции т. е. при извикване блокират, докато не бъде прочетен някакъв символ (ред).

Методът Read() има една особеност – той не връща управлението след всеки въведен символ, а връща прочетените символи наведнъж един след друг едва след като се натисне [Enter]. По тази причина този метод не е удобен за интерактивен вход от клавиатурата при конзолни приложения.

Вход от конзолата – примери

Ето един пример за използването на метода Read():

while (true)

{

int i = Console.Read();

if (i == -1)

{

break;

}

char c = (char) i;

Console.WriteLine ("Echo: {0}", c);

}

В практиката за въвеждане на стойности от конзолата по-често се използва методът ReadLine(). Ето пример за неговата употреба:

string s = Console.ReadLine();

Console.WriteLine("You enetered: {0}", s);

Изход към конзолата

Изходът към конзолата се осъществява чрез два метода на класа Console - Write(…) и WriteLine(…), които печатат на конзолата подадените като параметри данни, с разликата, че WriteLine(…) преминава на нов ред след като отпечата текста. Методите приемат string, int, float, double и други типове данни.

Write(…) и WriteLine(…) приемат и параметрични форматиращи низове, които позволяват печатане на текст чрез шаблони, които се попълват от подадените параметри. На форматиращите низове ще обърнем специално внимание в темата "Символни низове".

Изход на конзолата – пример

Ето един пример за вход и изход от конзолата, който илюстрира и използването на форматиращи низове:

int a = Int32.Parse(Console.ReadLine());

int b = Int32.Parse(Console.ReadLine());

Console.WriteLine("{0} + {1} = {2}", a, b, a+b);

// (въвеждаме съответно 2 и 3 като вход от конзолата)

// Резултат: 2 + 3 = 5

Console.WriteLine(

"Днес е {0:dd.MM.yyyy} г.", DateTime.Now);

// Резултат: Днес е 13.05.2004 г.

Console.WriteLine("Цена: {0,12:C}", 27);

// Резултат: Цена: 27,00 лв

// (точният формат зависи от текущите езикови настройки)

string name = Console.ReadLine();

Console.WriteLine("Хей, {0}, часът е {1:HH:mm}!",

name, DateTime.Now);

// (въвеждаме "Наков")

// Резултат: Хей, Наков, часът е 16:43!

Дебъгерът на Visual Studio .NET

Сега ще илюстрираме как се използва дебъгерът на Visual Studio .NET. Ще покажем поставяне на точка за спиране (breakpoint), изпълнение на програмата в дебъг режим, проследяване на изпълнението на програмата и следене на стойностите на променливите по време на изпълнение.

Ще си поставим за задача да напишем програма, която намира всички трицифрени числа, сумата от цифрите на които е стойността 25. Можем да решим задачата по следния начин:

Digits.cs

using System;

public class Digits

{

static void Main()

{

for (int d1=1; d1<=9; d1++)

{

for (int d2=0; d2<=9; d2++)

{

int d3 = 25 - d1 - d2;

if ((d3 >= 0) && (d3 <= 9))

{

int n = d1*100 + d2*10 + d3;

Console.WriteLine(n);

}

За да проследим изпълнението на примерната програма, ще изпълним следните стъпки:

1. Стартираме Visual Studio .NET.

2. Създаваме ново конзолно приложение с име Digits.sln. Въвеждаме в него сорс кода от примера Digist.cs.

3. За да го компилираме натискаме [Shift]+[Ctrl]+[B].

4. Слагаме точка на прекъсване (breakpoint) с мишката върху първия ред от най-вътрешния програмен блок (щракваме малко вляво от самия ред и редът се маркира по специфичен начин):

5. Стартираме програмата от съответния бутон за стартиране от лентата с инструменти на Visual Studio .NET. Програмата ще започне да се изпълнява и когато се достигне реда с точката на прекъсване, Visual Studio .NET ще спре изпълнението и ще влезе в дебъг режим.

6. От менюто Debug можем да разгледаме по-интересните функции на дебъгера на Visual Studio .NET. Можем да добавим точки на прекъсване (breakpoints), да следим стойностите на променливите, да проследяване на изпълнението на кода по различен начин (Step Into, Step over, Step out), да добавим променливи за следене (Add Watch), да следим стека за изпълнение на програмата и т.н. Можем да разгледаме представянето на променливите в паметта – като изберем Debug | Windows | Memory. Много полезен е и прозорецът Command Window, в който не само може да се види стойност на променлива в дебъг режим, но и да се изпълни някакъв метод и да се види върнатата от него стойност. С [Shift] + [F9] при маркирана променлива може да се извика прозорец за нейното наблюдение (Quick Watch).

Точките на прекъсване могат да бъдат асоциирани с някакво условие (conditional breakpoints) и да спират изпълнението на програмата само ако това условие е истина.

Ето как изглежда работното пространство на Visual Studio .NET по време на проследяване на изпълнението на програмата след спиране в точката на прекъсване и преминаване към следващия оператор с [F10]:

Инструментът ILDASM

Всяка програма на С# се компилира до междинен език IL (Intermediate Language). Microsoft предоставя стандартен инструмент за разглеждане на този, генериран от компилаторите на С#, код. Това е инструментът Microsoft .NET Framework Disassembler (ILDASM). С тази деасемблираща програма можем да отворим всяко .NET асембли и да разгледаме неговите пространства от имена, класове, типове и код.

Инструментът ildasm.exe е стандартна част от Microsoft .NET Framework SDK. Обикновено .NET Framework SDK идва заедно с Visual Studio .NET и се намира в директория C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin. Нека илюстрираме как се използва той. За целта трябва да изпълним следните стъпки:

1. Стартираме командния интерпретатор cmd.exe:

Start | Programs | Accessories | Command Prompt

2. Отиваме в директорията, където се намира компилираната програма, например, програмата от предходния пример Digits.exe:

cd "C:\DotNet-course-lectures\Lecture-2-Introduction-to-CSharp\Demo-3-Digits\bin\Debug"

3. Извикваме от командната линия инструмента ILDASM (ildasm.exe) и му подаваме като параметър компилираната програма Digits.exe:

ildasm Digits.exe

4. Навигирайки по дървото, което ILDASM показва за асемблито Digits.exe, можем да видим как изглежда MSIL кодът за конструктора на класа Digits и за метода му Main():

XML документация в C#

XML документацията в C# програмите представлява съвкупност от коментари, започващи с ///. Тя може да съдържа различни XML тагове – например, таг описващ връщана стойност на метод, таг за препратки към други методи и др. Като идея XML документацията прилича на JavaDoc в Java.

XML документацията значително улеснява поддръжката – документацията е част от кода, а не стои във външен файл. Поддържа се лесно и ползата от нея е видима още при разработката на приложението – Visual Studio .NET показва краткото описание на даден метод, ако той е документиран чрез вградената XML документация, при задействане на IntelliSense. C# компилаторът може да извлича XML документацията като XML файл за по-нататъшна обработка.

Ето пример за използване на XML документация:

/// <summary>

/// The main entry point for the application.

/// </summary>

/// <param name="args">The command line arguments</param>

static void Main(string[] args)

{

// ...

}

/// <summary>Calculates the square of a number</summary>

/// <param name="num">The number to calculate</param>

/// <returns>The calculated square</returns>

/// <exception cref="OverflowException">Thrown when the

/// result is too big to be stored in an int</exception>

/// <seealso cref="System.Int32" />

public static int square(int num)

{

// ...

}

Тагове в XML документацията

Ето по-важните тагове, използвани в XML документацията в C#:

- <summary>…</summary> – кратко описание за какво се отнася даден тип, метод, свойство и т.н. Visual Studio .NET показва това описание при задействане на IntelliSense.

- <remarks>…</remarks> – подробно описание на даден тип, метод, свойство и т.н. Visual Studio .NET показва това описание в областта Object Browser.

- <param name="…">…</param> – описание на един от параметрите на даден метод.

- <returns>…</returns> – описание на връщаната от даден метод стойност.

- <exception cref="…">…</exception> – описание на изключение, което може да възникне в даден метод.

- <seealso cref="…"/> – препратка към информация, свързана с текущото описание.

- <value>…</value> – описание на свойство (property).

Извличане на XML документация от C# сорс код

Сега ще покажем как чрез C# компилатора може да се извлече документацията от C# файл в отделен XML файл. Нека имаме следната програма на C#, която използва XML документация:

MainClass.cs

using System;

namespace XMLCommentsDemo

{

/// <summary>

/// MainClass is a sample illustrating how to use XML

/// documentation in C#.

/// </summary>

class MainClass

{

/// <summary>Calculates the square of a number</summary>

/// <param name="num">The number to calculate</param>

/// <returns>The calculated square</returns>

/// <exception cref="OverflowException">Thrown when the

/// result is too big to be stored in an int</exception>

/// <seealso cref="System.Int32" />

public static int Square(int num)

{

checked

{

return num*num;

}

/// <summary>

/// The main entry point for the application.

/// </summary>

/// <param name="args">The command line arguments</param>

static void Main(string[] args)

{

Console.WriteLine("3*3 = " + Square(3));

}

За да извлечем документацията от тази програма, трябва да изпълним следните стъпки:

1. Стартираме командния интерпретатор cmd.exe:

Start | Programs | Accessories | Command Prompt

2. Отиваме в директорията, където се намира сорс кода на програмата. Нека тя е Demo-6-XML-Comments:

cd "C:\DotNet-course-lectures\Lecture-2-Introduction-to-CSharp\Demo-6-XML-Comments"

3. Извикваме компилатора на C#, за да компилира файла MainClass.cs, като му задаваме опцията за извличане на XML документацията в отделен файл:

csc MainClass.cs /doc:MainClassComments.xml

4. Отваряме получения .xml файл с Internet Explorer, за да разгледаме съдържанието му.

Ето как полученият XML файл:

MainClassComments.xml

<?xml version="1.0"?>

<doc>

<name>MainClass</name>

</assembly>

MainClass is a sample illustrating how to use XML

documentation in C#.

</summary>

</member>

<member name="M:XMLCommentsDemo.MainClass.Square(

System.Int32)">

<summary>Calculates the square of a number</summary>

<param name="num">The number to calculate</param>

<returns>The calculated square</returns>

<exception cref="T:System.OverflowException">Thrown when

the result is too big to be stored in an int</exception>

</member>

<member name="M:XMLCommentsDemo.MainClass.Main(

System.String[])">

The main entry point for the application.

</summary>

<param name="args">The command line arguments</param>

</member>

</members>

</doc>

Генериране на HTML документация от VS.NET

Сега ще покажем как чрез Visual Studio .NET може да се генерира HTML документация за даден проект на C# по XML коментарите в неговия сорс код. Във вид на HTML документацията е много по-удобна за четене и разглеждане.

За целта трябва да изпълним следните стъпки:

1. Отваряме с Visual Studio .NET проект, в който сме използвали XML документиране, например проекта Demo-6-XML-Comments.sln, който съдържа кода от предходния пример.

2. От меню Tools избираме Build Comment Web Pages…. Указваме директория, където да се генерира HTML документацията, и натискаме бутона [OK]. Visual Studio .NET ще генерира в посочената директория съвкупност от HTML файлове, които документират нашия проект и съдържат XML коментарите от сорс кода му, подредени в подходящ за разглеждане вид.

3. Разглеждаме HTML документацията, която Visual Studio .NET е генерирал. Можем да навигираме по пространствата от имена, типовете от проекта и отделните му методи:

Директиви на предпроцесора

Нека сега разгледаме някои по-важни директиви на т. нар. предпроцесор. Преди компилация C# програмите преминават през процес на обработка, който идентифицира кода, който трябва да бъде компилиран при условна компилация. Този процес се изпълнява от предпроцесора. Програмно върху предпроцесора можем да указваме влияние чрез т.нар. директиви – запазени думи, започващи със символа #.

Директиви за форматиране на сорс кода

В С# са въведени директиви за форматиране на сорс кода - #region и #endregion, които ограждат блок от кода, който се "свива" от редактора на Visual Studio .NET:

#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

Visual Studio .NET редакторът много често слага региони, за да отдели автоматично-генерирания код от сорс кода, писан от програмиста. Директивите #region и #endregion се игнорират от C# компилатора и се използват единствено от средите за разработка.

Директиви за условна компилация

Директивите #define и #ifdef служат за условна компилация. Чрез тях може да се укаже на компилатора да компилира кода по различен начин според процесора, платформата и въобще средата, в която се извършва компилацията. Чрез #if, #else, #elif, #endif се задават границите на блоковете за условна компилация и съответните условия (знаци) за компилиране. Директивите #define и #undef дефинират знаци за условна компилация, според които се определя кой от блоковете за условна компилация да се разглежда.

Условна компилация – пример

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

#define DEBUG

#define VC_V7

using System;

public class MyClass

{

public static void Main()

{

#if (DEBUG && !VC_V7)

Console.WriteLine("Only DEBUG is defined");

#elif (!DEBUG && VC_V7)

Console.WriteLine("Only VC_V7 is defined");

#elif (DEBUG && VC_V7)

Console.WriteLine("DEBUG and VC_V7 are defined");

#else

Console.WriteLine("DEBUG and VC_V7 are not defined");

#endif

}

Ето и резултата от изпълнението на примера:

Директиви за контрол над компилатора

Директивите #warning и #error предизвикват предупреждения и грешки по време на компилация. Например следната програма на C# се компилира успешно, но с предупреждение:

#define DEBUG

public class MyClass

{

public static void Main()

{

#if DEBUG

#warning DEBUG symbol is defined

#endif

}

Документацията на .NET Framework

Програмирането с .NET Framework е немислимо без неговата документация. Затова нека сега разгледаме какво представлява тя и как можем да я използваме при търсене на помощна информация по време на разработката на .NET приложения.

MSDN Library

Документацията на .NET Framework се съдържа в "Microsoft MSDN Library".

MSDN Library е система, която предоставя пълен набор от технически документи, описващи продуктите, инструментите и технологиите за разработка на Microsoft (в частност .NET Framework и C#), както и средства за навигация и търсене в тях. MSDN Library съдържа технически ръководства, справочна информация, статии, примери и други ресурси за софтуерни разработчици.

MSDN Library е достъпен безплатно в on-line вариант от Интернет сайта за разработчици на Microsoft – http://msdn.microsoft.com/library/. Продуктът се разпространява и за локална инсталация заедно с партньорските програми на Microsoft.

MSDN Library – пример

За пример ще покажем как можем да намерим подробна информация за форматиращите низове в .NET Framework и тяхното използване. За целта стартираме MSDN Library и търсим "composite formatting":

.NET Framework и MSDN Library

Документацията на .NET Framework е част от MSDN Library и се разпространява заедно с VS.NET и .NET Framework SDK.

Когато бъде инсталирана, документацията за .NET Framework, тя се интегрира във VS.NET и може да се използва директно от него. Например, ако се нуждаем от помощна информация за метода WriteLine(…) на класа Console, натискаме [F1] във Visual Studio .NET докато курсорът е върху този метод. Отваря се нов прозорец, в който са описани параметрите, типа на връщаната стойност, типовете изключения, които може да предизвика описвания метод, в кое пространство от имена се намира и др.

Ето как изглежда описанието на метода WriteLine(…) на класа Console:

Упражнения

1. Съставете програма на C#, която въвежда от конзолата име на студент и го поздравява в стил "Здравей, <име>!".

2. Съставете програма на C#, която въвежда коефициентите на квадратно уравнение и пресмята реалните му корени.

3. Напишете програма, която намира всички символни низове, които се състоят от точно 5 малки латински букви и са симетрични спрямо средата си.

4. Проследете работата на програмата от задача 3 с дебъгера на Visual Studio .NET.

5. Променете програмата от задача 3, така че да намира само тези низове, които съдържат четен брой гласни букви. Колко са тези низове?

6. Добавете XML документация в програмата от задача 5 и генерирайте HTML документация от Visual Studio .NET.

7. Напишете програма, която намира сумарната стойност на група фактури. Програмата трябва да въвежда последователно от конзолата сумите на фактурите (реални числа със знак) докато стигне до празен ред. Сумарната стойност на фактурите трябва да се отпечата в 10-символно поле, дясно подравнена, с точност 2 знака след десетичната запетая (потърсете в документацията подходящ форматиращ стринг).

8. Напишете програма, която прочита прост числен израз, състоящ се от реални числа, свързани с операциите "+" и "-", и изчислява и отпечатва стойността му.

Използвана литература

1. Светлин Наков, Въведение в C# – http://www.nakov.com/dotnet/ lectures/Lecture-2-Introduction-to-CSharp-v1.0.ppt

2. MSDN Training, Programming C# (MOC 2124C), Module 2: Overview of C#

3. MSDN Training, Programming C# (MOC 2124C), Module 3: Using Value-Type Variables

4. Jessy Liberty, Programming C#, Second Edition, O’Reilly, 2002, ISBN 0-596-00309-9

5. Svetlin Nakov, .NET Framework Overview – http://www.nakov.com/ publications/Nakov-DotNET-Framework-Overview-english.ppt

6. MSDN, C# Keywords – http://msdn.microsoft.com/library/en-us/csref/ html/vclrfcsharpkeywords_pg.asp

7. MSDN, C# Built-in Types Table – http://msdn.microsoft.com/library/en-us/csref/html/vclrfbuiltintypes.asp

8. MSDN, Common Type System Overview – http://msdn.microsoft.com/ library/en-us/cpguide/html/cpconcommontypesystemoverview.asp

9. MSDN, Enumerations – http://msdn.microsoft.com/library/en-us/cpguide/ html/cpconEnumerations.asp

10. MSDN, C# Operators – http://msdn.microsoft.com/library/en-us/csref/ html/vclrfCSharpOperators.asp

11. MSDN, Statements (C# Programmer's Reference) – http://msdn.microsoft.com/library/en-us/csref/html/vclrfstatements.asp

12. MSDN, XML Documentation Tutorial (C# Programmer's Reference) – http://msdn.microsoft.com/library/en-us/csref/html/vcwlkxmldocumentationtutorial.asp

13. MSDN, C# Preprocessor Directives - http://msdn.microsoft.com/ library/en-us/csref/html/vclrfPreprocessorDirectives.asp

14. MSDN, Composite Formatting – http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcompositeformatting.asp

15. MSDN, Console Class (.NET Framework) – http://msdn.microsoft.com/ library/en-us/cpref/html/frlrfsystemconsoleclasstopic.asp

Глава 3. Обектно-ориентирано програмиране в .NET

Необходими знания

- Познаване на принципите на обектно-ориентираното програмиране

- Познаване на поне един обектно-ориентиран език за програмиране – C++, Java, C#, Object Pascal/Delphi

Съдържание

- Предимства и особености на ООП.

- Основни принципи на ООП. Основни понятия

- ООП и .NET Framework

- Членове на клас

- Член-променливи (полета). Константни полета

- Методи (член-функции)

- Статични членове

- Конструктори. Статичен конструктор

- Предаване на параметрите

- Свойства. Индексатори

- Предефиниране на оператори

- Наследяване

- Интерфейси. Абстрактни класове

- Виртуални членове. Предефиниране и скриване.

- Клас диаграми

- Принципи при обектно-ориентирания дизайн

- Пространства от имена (namespaces)

В тази тема ...

В настоящата тема ще направим кратък обзор на основните принципи на обектно-ориентираното програмиране (ООП) и средствата за използването им в .NET Framework и езика C#. Ще се запознаем с типовете "клас", "структура" и "интерфейс" в C#. Ще въведем понятието "член на тип" и ще се разгледаме видовете членове (член-променливи, методи, конструктори, свойства, индексатори и др.) и тяхната употреба. Ще се спрем и на наследяването на типове в различните му аспекти и приложения. Ще обърнем внимание и на полиморфизмът в C# и свързаните с него понятия и програмни техники. Накрая ще обсъдим някои утвърдени практики при създаването на ефективни йерархии от типове.

Предимства и особености на ООП

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

Моделиране на обекти от реалния свят

В основата на ООП стоят обектите, моделиращи обекти от реалния свят и взаимодействията между тях. Това позволява изграждането на софтуерни системи, които въпреки сложността си са разбираеми и в следствие на това - лесни за разширяване и поддръжка. Даден обект, представящ същност (entity) от реалния свят, би могъл (почти) без изменения да играе ролята на същия физически обект в друга софтуерна система.

Обектите притежават атрибути, които описват свойствата на им, и операции – възможните действия, които могат да се извършват с обекта.

Преизползване на програмния код

Едно от основните предимства на обектно-ориентирания подход е, че позволява лесно преизползване на програмния код (code reuse). Това се постига с помощта на наследяване и полиморфизъм, които ни позволяват да дефинираме общите свойства и действия за множество от типове обекти само в един от тях.

Основни принципи на ООП

Трите основни принципа на ООП са капсулация на данните, наследяване и полиморфизъм. Те са основните характеристики, които определят един език за програмиране като обектно-ориентиран.

Капсулация на данните

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

Обектите в ООП съдържат своите данни и средствата за тяхната обработката, капсулирани като едно цяло.

Наследяване

Ако един обект съдържа всички свойства и действия на друг, първият може да го наследи. По този начин наследеният обект освен собствените си атрибути и операции приема и тези на "родителя" си (базовия клас), като така се избягва повторното им дефиниране и се позволява създаването на йерархии от класове, моделиращи по естествен начин зависимостите от реалността.

За да изясним това понятие, ще си послужим с класическият в OOП пример за класа от обекти Animal, който представлява абстракция за множеството от всички животни. Всички обекти от този клас имат общи характеристики (например цвят и възраст) и обща функционалност, например операциите Eat и Sleep, докато за класът Dog, представляващ множеството от всички кучета, които също са животни, би могъл да предоставя операциите Eat, Sleep и Bark. Удачно е класът Dog да наследи Animal – тогава той ще съдържа описание само на собственото си действие Bark, докато тези на Eat и Sleep ще получи от базовия си клас.

Чрез наследяването се постига специализация, или конкретизация на класовете, тъй като базовият клас представлява категория от обекти по-обща от тази на наследяващите го. Ако си послужим с горния пример, множествата на кучетата и котките са подмножества на множеството от всички животни.

Може да се каже, че наследяването моделира "is-a" отношението между обектите, например можем да твърдим, че кучето е животно, тъй като то "може да прави" всичко, което и животното и притежава всички животински характеристики (цвят, възраст и т.н.).

Полиморфизъм

Полиморфизъм буквално означава приемането на различни форми от един обект. Нека е даден базов клас, представящ категория от обекти, които реализират общо действие, което се наследява от множество класове, описващи по-тесни категории. Въпреки, че те всички споделят това действие, те могат да го реализират по различен начин. Когато разполагаме с обекти от базовия клас, знаем че всички те реализират това действие, независимо на кой наследен клас принадлежат. Поради това можем да го използваме без да се интересуваме от конкретната му реализация. Например, ако класът Animal предоставя действието Talk и разгледаме наследяващите го класове Dog и Cat, всеки от тях го реализира по конкретен начин. И ако имаме животно, което издава звук и то е куче – ще лае, а ако е котка – ще мяучи.

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

Основни понятия в ООП

Без да претендираме за изчерпателност ще даден кратка дефиниция за основните понятия от ООП, които ще използваме по-нататък. Ако откривате, че повечето от тези термини са ви напълно непознати, ви препоръчваме първо да се запознаете с принципите на обектно-ориентираното програмиране от някоя специализирана книга по ООП, а след това да продължите нататък. В настоящата тема ще направим преглед на реализацията на ООП в .NET Framework, а не на ООП като идеология.

Клас

Класовете са категории от обекти, споделящи общи свойства и операции, които могат да се извършват върху тях. Например класът "студент" представя множеството от всички студенти. Класът не съществува реално като физическа същност, а по-скоро можем да го разгледаме като описание на неговите обекти.

Обект

Обект наричаме конкретен елемент от даден клас (инстанция), например студентът Тодор Георгиев, трети курс, ядрена физика в СУ.

Инстанциране

Процесът на създаване на обект от даден клас е инстанциране. Обектите, създадени при инстанциране на даден клас, се наричат негови инстанции. Например в резултат от инстанцирането на класа "студент" можем да получим обекта "Иван Петров", който е инстанция на класа "студент".

Свойство

Свойство се нарича видима за външния свят характеристика (атрибут) на обектите от даден клас. Например свойства на класа "студент" са личните имената му, личните му данни, оценките му и др.

Метод

Метод е действие, което всички обекти от даден клас могат да извършват. Например всички обекти от класа "студент" могат да извършват действието "явяване на изпит".

Интерфейс

Интерфейсът е описание на съвкупност от действия, които даден обект може да извършва. Ако един обект може да извършва всички действия от даден интерфейс, казваме че обектът реализира, или имплементира интерфейса. Класът "студент", например, би могъл да реализира интерфейса "учащ" съдържащ действието "учене".

Наследяване на класове

Наследяване в ООП наричаме възможността един клас, наричан наследник, да придобие свойства и действия на друг клас – родител (базов клас). Например класът "прекъснал студент" би могъл да наследи класа "студент", като към наследените методи и свойства добави собствени, например "получаване на призовка от военните власти".

Абстракция на данните

Абстракция на данните наричаме възможността да работим с данни без да се интересуваме от тяхното вътрешно представяне, а само от операциите, които можем да извършваме над тях. Удачно е този подход да се осъществи чрез използването на интерфейси.

Структури от данни, които дефинират група от операции, но не разкриват информация как са имплементирани тези операции, се наричат абстрактни структури от данни.

Абстракция на действията

Абстракцията на действията е възможността да изпълняваме действия, без да се интересуваме от конкретната им реализация. Обикновено се постига чрез полиморфизъм. Например ако извикваме даден метод от даден клас през неговия базов клас или интерфейс, ние реално извикваме абстрактно действие от базовия клас, което е реализирано в класа-наследник.

ООП и .NET Framework

В .NET Framework обектно-ориентираният подход е залегнал на най-дълбоко архитектурно ниво. Всеки тип, дефиниран от потребителя, и всички типове от Common Type System (CTS) наследяват System.Object или негов наследник.

В някои обектно-ориентирани езици се използват примитивни типове данни (булеви, числови, символни), които в езиците от .NET Framework са също наследници на System.Object.

Всички .NET езици са обектно-ориентирани и приложенията се пишат изцяло обектно-ориентирано – няма глобални функции и всички действия се извършват или чрез създаване на обекти и с използване на методите и свойствата им, или чрез използване на статични членове (тях ще разгледаме малко по-нататък).

Типове данни

В предходната глава въведохме понятието тип и разделихме типовете в C# на типове стойностни и референтни. Следва да представим една по-подробна класификация на типовете данни в .NET Framework. Те биват:

Реализация на понятието клас

Понятието "клас" от ООП се реализира в .NET Framework чрез класове (classes) и структури (structs).

Не трябва да бъркаме понятието клас от концепциите на ООП с понятието клас в .NET Framework. Разликата е тънка – класът в .NET действително е клас според ООП терминологията, но обратното не е вярно. ООП терминът клас се реализира и по още един начин – чрез структури.

Основната разлика между класовете и структурите в .NET Framework е, че структурите са стойностни типове, докато класовете са референтни типове. Структурите по-интуитивно моделират данни, от които се очаква поведение като на примитивни типове, докато класовете по-добре моделират обекти от реалния свят, които могат да извършват определени действия.

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

Множествено наследяване

Някои обектно-ориентирани езици позволяват използването на множествено наследяване – възможността един клас да приеме методи и свойства от няколко родителя. При проектирането на .NET Framework е взето решение това да не се допуска.

Една от причините в .NET Framework да няма множествено наследяване е, че множественото наследяване води до конфликти, например ако един клас наследи елемент с едно и също име от повече от един родител.

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

В .NET Framework приемането на характеристики и поведение от повече от една същности от реалния свят се осъществява чрез реализиране на няколко интерфейса едновременно, при което обаче не може да се наследят данни или програмен код, а само дефиниции на действия.

Класове

Класовете в C# са основните единици, от които се състоят програмите. Те моделират обектите от реалния свят и могат да дефинират различни членове (член-променливи, методи, свойства и др.). Нека видим как изглежда един примерен клас на езика C#:

class Student

{

// Private member declarations

private string mFirstName;

private string mLastName;

private string mStudentId;

// Constant

private const double PI = 3.1415926535897932384626433;

// Constructor

public Student(string aStudentId)

{

mStudentId = aStudentId;

}

// Property

public string FirstName

{

get

{

return mFirstName;

}

set

{

mFirstName = value;

}

// Read-only property

public string StudentId

{

get

{

return mStudentId;

}

// Method

public string StoreExamResult(

string aSubject, double aGrade)

{

// ...

}

В горния пример е дефиниран класът Student, илюстриращ някои от видовете членове, които класовете могат да реализират – капсулираните полета mFirstName, mLastName и mStudentId, константата PI, конструкторът Student(…), свойствата FirstName и StudentId и методът StoreExamResult(…). С течение на темата ще се запознаем по-отблизо с всеки от тези видове членове.

Членове на тип

В .NET типовете "клас" и "структура", като реализация на понятието клас от ООП, могат да съдържат в себе си членове (members), подобно на други обектно-ориентирани езици като Java и C++. Членовете могат да бъдат от един от следните видове:

- полета, или член-променливи (fields)

- константи (constants)

- методи, или член-функции (methods)

- свойства (properties)

- индексатори (indexers)

- събития (events)

- оператори (operators)

- конструктори (constructors)

- деструктори (destructors)

- вложени типове (класове, структури, изброени типове и др.)

Видимост на членовете

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

public

Глобална видимост – членовете с такова ниво на достъп могат да се достъпват от всеки тип.

protected internal

Това са членовете, видими от всички типове, дефинирани в асемблито, в което е дефиниран дадения, a също и от наследниците на типа.

internal

Членове, които се достъпват от всички типове, дефинирани в асемблито, в което е дефиниран дадения.

protected

Членове, видими само от наследниците на дадения тип.

private

Капсулирани членове, видими единствено в рамките на типа.

Член-променливи

Данните, с които инстанцията на класа работи, се съхраняват в член-променливи (или още полета). Те се дефинират в тялото на класа и могат да се достъпват от други видове членове – методи, конструктори, индексатори, свойства. В следващия пример ще покажем няколко декларации на член-променливи, за които в последствие ще дадем обяснения.

class Student

{

private string mFirstName;

private string mLastName;

private string mStudentId;

private int mCourse = 1;

private string mSpeciality;

private Course[] mCoursesTaken;

// Avoid missing the visibility modifier

string mRemarks = "(няма забележки)";

}

Дефиниране на ниво на видимост

Дефиницията на всяко поле започва с ниво на видимост. Допустими са всички по-горе изброени нива на видимост, но в примера са използвани само private, защото скриването на полетата от използващите класа, т.е. указването на видимост private или protected, е утвърдена практика в ООП. Когато искаме да предоставим данните на класа на околния свят в .NET е прието вместо полета с ниво на достъп "public" да се използват свойства, на които ще се спрем малко по-късно. Степента на видимост може и да не бъде определена явно, както е в последния ред за полето mRemarks от примера и в този случай се подразбира private. Тази практика не се препоръчва, защото води до по-неясен код.

Дефиниране на тип

Следващият елемент от дефиницията на член-променлива е типът, който се указва задължително. Може да бъде произволен .NET тип от CTS или дефиниран от потребителя.

Задаване на име

След типа следва името на дефинираното поле, чрез което се обръщаме към него. То представлява идентификатор, т. е. последователност от unicode символи – главни и малки букви, цифри, -(тире) и _(подчертаващо тире), незапочваща с цифра или тире.

Имената на полетата и въобще на членовете в .NET Framework могат да бъдат идентични със съществуващи имена на типове или пространства от имена (на тях ще се спрем в края на темата). Например класът Student може да има свойство със същото име Student. Могат да бъдат и запазени думи, но само ако бъдат предшествани от @. Допуска се и използването на нелатински букви в имената, но не се препоръчва.

Задаване на стойност

При дефиницията на поле можем да му зададем стойност, както в примера това е направено за mCourse и mRemarks. Ако началната стойност бъде пропусната, на член-променливата се задава стойност по подразбиране. За референтните типове това е null, а за стойностните типовете е 0 или неин еквивалент (например false за boolean). В .NET Framework всички членове и променливи се инициализират автоматично. Това намалява грешките, възникващи заради използването на неинициализирани променливи.

Константни полета

Константните полета (или само константи) много приличат на обикновените полета, но имат някои особености. Нека обърнем внимание на следния пример, който показва няколко дефиниции на константи:

public class MathConstants

{

public const string PI_SYMBOL = "π";

public const double PI = 3.1415926535897932385;

public const double SQRT2 = 1.4142135623731;

}

От примера виждаме, че дефиницията на константа е дефиницията на поле с добавена ключовата дума const. Има и някои други разлики.

При декларирането на константно поле е задължително да се предостави стойност. Освен това стойността на константата не може да бъде променяна по време на работата с типа, в който е дефинирана – може само да бъде прочетена. Константите реално не съществуват като полета в типа, а съществуват само в сорс кода и се заместват със стойността им по време на компилация. Поради тази причина const декларациите в C# се наричат още compile-time константи, т. е. константи, които съществуват само по време на компилацията.

Полета само за четене

Друг специален вид полета, подобни на константите, са полетата само за четене (read-only fields). Те се различават от константните по това, че стойността им освен при дефиницията може да бъде зададена и в конструктор, но от там нататък не може да бъде променяна. Член-променлива само за четене се декларира, като се използва запазената дума readonly, като в примера:

class ReadOnlyDemo

{

private readonly int mSize;

public ReadOnlyDemo(int aSize)

{

mSize = aSize; // cannot be further modified!

}

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

Методи

Методите (или още член-функции) дефинират операции за типа, в който са дефинирани. Те могат да боравят с членовете му, независимо от степента им на видимост, да ги достъпват и променят (освен полетата обявени като константни или само за четене).

В C# функции могат да бъдат дефинирани единствено като членове на клас или структура, за разлика от други обектно-ориентирани езици, където се използват глобални функции – такива, които не са обвързани с конкретен тип и са общодостъпни. В C# функции, които се достъпват без да е нужна инстанция на даден клас, се дефинират като статични. На тях ще се спрем след малко.

Задаване на видимост

Подобно на полетата, и методите могат да имат ниво на видимост. И синтактично, и от гледна точка на стила на програмиране, на методите е допустимо да се зададе коя да е от възможните нива на видимост, тъй като те представляват действията с типа и за някои от тях е необходимо да бъдат видими за околния свят, а за други – не. Отново подразбиращото се ниво на видимост е private, но е препоръчително да се декларира изрично.

Параметри и върната стойност

Методите могат да приемат параметри и да връщат стойност. Параметрите имат тип, който може да бъде всеки валиден .NET тип. Върнатата стойност може да бъде също от всеки възможен тип, а може и да отсъства. Нека обърнем внимание на следния пример:

class MethodsDemo

{

public void SayHiGeorgi()

{

SayHi("Гошо");

}

public void SayHiPeter()

{

SayHi("Пешо");

}

private void SayHi(string aName)

{

if (aName == null || aName == "" )

{

return;

}

Console.WriteLine("Здравей, {1}", aName);

}

public int Multiply(int x, int y)

{

return x * y;

}

Първите два метода, SayHiGeorgi() и SayHiPeter(), не приемат никакви параметри и не връщат стойност. Третият, SayHi(string aName), приема един параметър от тип string и не връща стойност. Последният, Multiply(int x, int y), приема два параметъра от тип int и връща стойност също от тип int.

В дефинициите на първите три метода от примера забелязваме ключовата дума void – тя се използва при методи, които не връщат стойност. За методи, които връщат стойност, вместо ключовата дума void се указва типа на връщаната стойност.

В последния метод забелязваме как се употребява ключовата дума return за връщане на стойност. Същата ключова дума използваме и за прекратяване на изпълнението на метод, който не връща стойност, както в метода SayHi(aName).

Методи с еднакви имена

В C# е допустимо един тип да има два и повече метода с едно и също име, но с някои ограничения. Ще въведем понятие, свързано с използването на едно и също име за няколко метода. Комбинацията от името, броя и типа на параметрите на метод наричаме сигнатура. Ако два метода имат едно и също име, те задължително трябва да се различават по сигнатура. Следващият пример илюстрира дефинирането на три метода с еднакви имена:

int Sum(int a, int b)

{

return a + b;

}

int Sum(int a, int b, int c)

{

return a + b + c;

}

long Sum(long a, long b, long c) // avoid this

{

return a + b + c;

}

Горните дефиниции са напълно валидни – първите два метода се различават по броя на параметрите си, а вторият и третият – по типа.

Трябва да сме особено внимателни с дефиниции като последните две и е препоръчително да се избягват, тъй като не е очевидно кой метод ще бъде извикан при обръщение като int sumTest = sum(1,2,3). Компилаторът по никакъв начин не ни предупреждава за двусмислието. В горния пример ще бъде извикан първият метод – sum(int a, int b, int c).

Статични членове

Както вече споменахме, в C# функции, които могат да се извикват без да е нужна инстанция на клас, се реализират като статични (или общи) методи. Това става, като в дефиницията им включим ключовата дума static. Статичните членове се споделят от всички инстанции и се използват за пресъздаване на свойства и действия, които са постоянни за всички обекти от дадения клас. Достъпът до статичните членове на типа се извърша директно, а не през инстанция, както в следващия пример:

class Bulgaria

{

private static int mNumberOfCities = 267;

public static int NumberOfCities

{

get

{

return mNumberOfCities;

}

public static void AddCity(string aCityName)

{

mNumberOfCities++;

// ...

}

// ...

static void Main()

{

Console.WriteLine(

"В България има {0} града.", Bulgaria.NumberOfCities);

}

В примера видяхме дефинирането и използването на статични полета, методи и свойства. Използвахме статичните свойства без да инстанцираме класа Bulgaria никъде.

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

Статичните полета на типа много приличат на глобалните променливи в по-старите езици за програмиране като C, C++ и Pascal. Както глобалните променливи, статичните полета са достъпни от цялото приложение и имат само една инстанция.

От членовете на типа, освен полетата, свойствата и методите също и конструкторите, индексаторите и събитията могат да бъдат статични. Константите също са общи за всички инстанции на типа, но не могат да бъдат статични. Деструкторите също не могат да бъдат статични, докато операторите задължително са.

Конструктори

Конструкторите се използват при създаване на обекти и служат за инициализация, или начално установяване на състоянието на полетата на обекта. Механизмът на работа и синтаксисът за дефиниране на конструкторите в C# са подобни на други обектно-ориентирани езици, като Java и C++ с някои особености, на които ще обърнем внимание. Допуска се използването на повече от един конструктор, като конструкторите трябва да се различават по броя и/или типа на параметрите. Възможно е и да не се дефинира конструктор и в такъв случай компилаторът създава подразбиращ се – публичен, с празно тяло и без параметри.

Инициализиране на полетата

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

Инициализациите, описани в тялото на конструктора се изпълняват по време на изпълнението този конструктор – при създаване на обект от съответния клас с ключовата дума new в C#.

Инициализациите, дефинирани при декларацията на полетата се изпълня-ват директно преди конструктора. Можем да приемем, че при компилацията инициализациите на полетата се добавят в началото на всеки конструктор. Всъщност C# компилаторът прави точно това скрито от програмиста – поставя код, който инициализира всички член-променливи на типа във всички негови конструктори.

Полетата, които нямат зададена начална стойност, получават стойност по подразбиране (нулева стойност). Това поведение се изисква от спецификацията на езика C# и не зависи от конкретната имплементация на компилатора.

Конструктори – пример

Със следващия пример ще разгледаме примерни дефиниции на конструктори на базов клас с един наследник:

class Student

{

private string mName;

private int mStudentId;

private string mPosition = "Student";

public Student(string aName, int aStudentId)

{

mName = aName;

mStudentId = aStudentId;

}

public Student(string aName) : this(aName, -1)

{

}

public static void Main()

{

Student s = new Student("Бай Киро", 12345);

}

public class Kiro : Student

{

public Kiro() : base("Бай Киро", 12345)

{

}

// ...

}

Забелязваме употребата на ключовите думи this и base след дефиницията на конструкторите на класа. Те представляват съответно обръщения към друг конструктор на същия клас и към конструктор на базовия клас, като в скобите се изреждат параметрите, които се подават на извиквания конструктор. В примера е използване наследяване, на което ще с спрем в детайли след малко (класът Kiro наследява класа Student).

Изследване на MSIL кода за конструкторите в C#

В следващата демонстрация ще си послужим с инструмента IL DASM (ildasm.exe), който е част от .NET Framework SDK, за да разгледаме MSIL кода, който C# компилаторът генерира за класа Student, който дефинирахме в примера по-горе. С това упражнение не само ще се запознаем с работата с инструмента, но и ще забележим особеностите в генерирания код, свързани с полетата със зададена стойност при декларацията. Ето стъпките, които трябва да направим:

1. Отваряме Demo-1-Constructors.sln, елементарен Visual Studio .NET проект с единствен C# файл, който съдържа кода от горния пример. Компилираме проекта.

2. Стартираме командния интерпретатор към Visual Studio .NET. Не използваме стандартния cmd.exe, а този, който се намира в Start -> Programs -> Microsoft Visual Studio 2003 -> Visual Studio Tools, защото той се стартира с регистрирани пътища към .NET инструментите, които се използват от командния ред.

3. Избираме директорията, където се намира изпълнимият файл, получен при компилиране на проекта – Demo-1-Constructors.exe. Ако не сме променили настройките на Visual Studio .NET, това ще е директорията <директория на проекта>\bin\Debug.

4. Извикваме от командния ред инструмента ildasm и му подаваме като параметър компилираното приложение:

ildasm Demo-1-Constructors.exe

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

IL DASM показва дърво за асемблито, в което различаваме класа Student и членовете му. Ако се придвижим по дървото до конструкторите на класа, можем да изследваме техния IL код, както е показано на следващата картинка:

В кода, генериран за конструктора с един параметър, се вижда обръщението към този с два параметъра. Ако повторим същото действие и с втория конструктор, можем да наблюдаваме и неговия IL код (на картинката по-долу).

Забелязваме, че задаването на стойност на полетата с инициализация при декларацията реално се извършва в началото на втория конструктор. Реално тези полета се инициализират и от първия конструктор, защото той извиква втория.

Singleton клас

В този пример ще представим един популярен шаблон в обектно-ориентирания дизайн – клас, който може да има най-много една инстанция в рамките на цялото приложение. Такъв клас наричаме singleton. За реализирането на такива класове се използва следният подход:

public sealed class Singleton

{

private static Singleton mInstance = null;

private Singleton()

{

}

public static Singleton Instance

{

get

{

if (mInstance == null)

{

mInstance = new Singleton();

}

return mInstance;

}

Целта на задаването на private видимост за конструктора на класа е за да не могат да се създават инстанции освен от членове на класа, както в случая статичното свойство Instance. В дефиницията на класа е използвана ключовата дума sealed, която указва, че класът не може да бъде наследяван.

Горният пример само демонстрира използването на sealed класове и частен конструктор. В реална ситуация при реализацията на singleton шаблона трябва да се вземе предвид, че е възможно няколко нишки (threads) едновременно да се опитат да извлекат инстанцията на singleton класа и да се получи нежелано поведение. Затова обикновено реализацията на този шаблон изисква допълнителни усилия за нишково обезопасяване на работата на класа. На работата с нишки ще обърнем специално внимание в темата "Многонишково програмиране и синхронизация".

Статичен конструктор

Конструкторите, подобно на други видове членове на класа, могат да бъдат обявени за статични, с тази особеност че статичният конструктор може да бъде най-много един и не може да приема параметри и модификатори за достъп.

Извикване на статичен конструктор

Статичният конструктор се използва за инициализация на статичните членове и се извиква автоматично. Извикването на статичният конструктор се извършва "зад кулисите" от CLR. Това става по време на изпълнението на програмата и моментът на стартирането му не е точно определен. Това, което е сигурно, е че статичният конструктор е вече извикан когато се създаде първата инстанция на класа или когато се достъпи някой негов статичен член. В рамките на програмата, статичният конструктор може да бъде извикан най-много веднъж.

Статичен конструктор – пример

В следващия пример ще разгледаме класа SqrtPrecalculated, който използва статичен конструктор:

class SqrtPrecalculated

{

public const int MAX_VALUE = 10000;

private static int[] mSqrtValues; // static field

// Static constructor

static SqrtPrecalculated()

{

mSqrtValues = new int[MAX_VALUE + 1];

for (int i = 0; i <= MAX_VALUE; i++)

mSqrtValues[i] = (int) Math.Sqrt(i);

}

// Static method

public static int GetSqrt(int aValue)

{

return mSqrtValues[aValue];

}

static void Main()

{

Console.WriteLine(GetSqrt(1000));

}

Класът SqrtPrecalculated служи за бързо изчисляване на корен квадратен. Той предоставя статичния метод SqrtPrecalculated(), който връща цялата част на квадратния корен на аргумента си.

За по-голямо бързодействие всички квадратни корени на числата от 0 до 10000 се изчисляват предварително в статичния конструктор и после се използват наготово. Множеството от стойностите се съхранява в статичното поле mSqrtValues[], което се инициализира в статичния конструктор, който се изпълнява преди първия опит за достъп до класа.

Ще илюстрираме поведението на статичните конструктори в .NET Framework, като с помощта на дебъгера на VS.NET наблюдаваме как преди да започне да бъде използван даден клас се изпълнява първо статичният му конструктор.

Проследяване на изпълнението на примера

Ще използваме дебъгера на Visual Studio .NET за да проследим изпълнението на кода от горния пример, който се съдържа в приложението Demo-2-TestStaticConstructor от демонстрациите. Ще изпълним последователно следните стъпки:

Отваряме с VS.NET TestStaticConstructor.sln и го компилираме.
Слагаме точки на прекъсване (breakpoints) на първия ред на статичния конструктор (static SqrtPrecalculated()) и във функцията Main() като щракаме с мишката на равнището на тези редове в празното поле от ляво на областта за редактиране на код. След като поставим точките на прекъсване средата изглежда по следния начин:

Стартираме програмата в дебъг режим (от меню Debug -> Start или с [F5]) и проследяваме как дебъгерът на Visual Studio .NET спира първо в статичния конструктор, а след като му зададем да продължи, спира в метода Main(). Това илюстрира как функционалността от статичния конструктор се изпълнява преди първото използване на класа. Ето как изглежда средата в момента, в който програмата е спряла в статичния конструктор:

Свойства

Свойствата са членове на класовете, структурите и интерфейсите, които обикновено се използват за да контролират достъпа до полетата на типа.

Свойствата приличат на член-променливите по това, че имат име, по-което се достъпват, и стойност от някакъв предварително определен тип. От гледна точка на синтаксиса за достъп до тях, свойствата изглеждат по същият начин както полетата. Разликата се състои в това, че свойства съдържат код, който се изпълнява при обръщение към тях, т. е. извършват действия. Свойствата могат да бъдат и статични.

Прочитане и присвояване на стойност

Свойствата могат да имат два компонента (accessors):

- код за прочитане на стойността (get accessor)

- код за присвояване на стойността (set accessor)

Когато създаваме свойства можем да предоставим дефиниции на двата компонента, както и на само един от тях, но задължително трябва да е дефиниран поне единият. Според предоставените компоненти делим свойствата на три вида:

- Свойства само за чете (read only) - такива, които дефинират само код за прочитане на стойността им.

- Свойства за четене и писане (read and write) - когато имат и двата компонента.

- Свойства само за писане (write only) - когато е предоставен само код за присвояване на стойност.

Пример за свойства

Ще дефинираме класа Person за да илюстрираме дефинирането и използването на свойства:

public class Person

{

private string mName;

private DateTime mDateOfBirth;

// Property Name of type string

public string Name

{

get

{

return mName;

}

set

{

if ((value != null) && (value.Length > 0))

{

mName = value;

}

else

{

throw new ArgumentException("Invalid name!");

}

// Property DateOfBirth of type DateTime

public DateTime DateOfBirth

{

get

{

return mDateOfBirth;

}

set

{

if ((value.Year >= 1900) &&

(value.Year <= DateTime.Now.Year))

{

mDateOfBirth = value;

}

else

{

throw new ArgumentOutOfRangeException(

"Invalid date of birth!");

}

// Read-only property Age of type int

public int Age

{

get

{

DateTime now = DateTime.Now;

int yearsOld = now.Year - mDateOfBirth.Year;

DateTime birthdayThisYear =

new DateTime(now.Year, mDateOfBirth.Month,

mDateOfBirth.Day, mDateOfBirth.Hour,

mDateOfBirth.Minute, mDateOfBirth.Second);

if (DateTime.Compare(now, birthdayThisYear) < 0)

{

yearsOld--;

}

return yearsOld;

}

// Property usage example

class PropertiesDemo

{

static void Main()

{

Person person = new Person();

person.Name = "Svetlin Nakov";

person.DateOfBirth = new DateTime(1980, 6, 14);

Console.WriteLine("{0} is born on {1:dd.MM.yyyy}.",

person.Name, person.DateOfBirth);

Console.WriteLine("{0} is {1} years old.",

person.Name, person.Age);

}

В примерния клас виждаме дефинициите на две свойства за четене и писане - Name от тип string и DateOfBirth от тип DateTime, както и едно само за четене – Age от тип int.

Можем да доловим различните аспекти на употребата на свойства - едно свойство може да бъде просто обвивка около поле на типа, но може и да реализира по-сложна логика. Например свойствата Name и DateOfBirth в примера просто връщат стойността на полетата, които обвиват, или я задават след съответните проверки за валидност. Свойство може да бъде и абстракция на данни, извличането и съхранението на които би могло да бъде свързано със сложна обработка. Опростен пример за това е Age, което връща стойност, резултат от извършване на изчисления, в случая разликата между текущата дата и рождената дата на лицето.

Проследяване на изпълнението на свойствата

Ще си изясним работата със свойства като проследим хода на програмата по време на достъпа до тях. За целта ще си послужим с кода от примера, който се съдържа в приложението Demo-4-Properties от демонстрациите. Той съдържа горния пример. Нека изпълним следните стъпки:

Отваряме с VS.NET Demo-4-Properties.sln и го компилираме.
Стартираме програмата в режим на проследяване с [F11]. Програмата спира изпълнението си на първия ред, но без той да е изпълнен, ето така:

Натискаме отново [F11] при което се създава обекта person и маркерът спира на следващия ред.
Когато още веднъж натиснем [F11], забелязваме, че кодът, който следва да бъде изпълнен, е тялото на компонента за достъп до свойството Name на класа Person:

Това ни показва, че зад операцията "присвояване на стойност" на свойството стои кодът му за присвояване.

С [Shift-F11] продължаваме изпълнението на програмата до напускането на текущият блок – то спира отново на следващия ред в тялото на метода Main(…).
С [F10] продължаваме изпълнението на програмата с още една стъпка. Резултатът е същият, както при натискането на [F11] с тази разлика, че не се изпълняват стъпка по стъпка вложените блокове. Така преминаваме през изпълнението на кода за присвояване на стойност на свойството DateOfBirth на "един дъх" и маркерът се позиционира на операцията Console.WriteLine("{0} is born on {1:dd.MM.yyyy}.", person.Name, person.DateOfBirth).
Ако в този момент натиснем [F11] ставаме свидетели на изпълнението и на кода за достъп на свойството Name:

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

С [F5] продължаваме изпълнението на програмата до края и виждаме резултата от изпълнението и:

В режим на дебъгване прозорецът, в който се изпълнява приложението, се затваря веднага след приключване на изпълнението на кода и резултатът трудно може да бъде видян. Ако искаме да видим отпечатания резултат, трябва или да сложим точка на прекъсване преди края на Main() метода, или да се придвижим до последната операция стъпка по стъпка или да изпълним програмата не с [F5], а с [Ctrl-F5].

Нека изследваме с IL DASM генерирания междинен код за примерното приложение, за да си изясним вътрешното представяне на свойствата.

Като стартираме ildasm и разгледаме с него IL кода за класа Person, забелязваме нещо много интересно – в класа Person има методи с префикс set_, отговарящи на компонентите за присвояване на дефинираните от нас свойства, и методи с префикс get_, които съответстват на компонентите за връщане на стойност.

На практика след компилация get и set частите на свойствата са се превърнали в методи, а достъпът до тях се е превърнал в операции за извикване на метод. Това е начинът, по който C# компилаторът компилира свойствата – превръща ги в методи, а достъпът до тях превръща в извиквания на методи.

Ето как изглежда класът Person в инструмента IL DASM:

Индексатори

Индексаторите в C# (indexers) са членове на класовете, структурите и интерфейсите, които предоставят индексиран достъп до данни на типа, подобно на достъпа до елементите на масив.

Индексаторите по синтаксис и семантика много приличат на свойства, но получават като параметър индекс на елемент, с който да работят. На практика, те представляват свойства, приемащи параметър и дори в някои .NET езици, например VB.NET, синтаксисът на декларирането им е същият като при свойствата.

Индексатори – пример

За да си изясним най-лесно как се дефинират индексатори, да разгледаме следния пример:

private object[] mElements;

public object this[int index]

{

get

{

return mElements[index];

}

Виждаме, че дефиницията на индексатор прилича на тази на свойство, но има и някои разлики. На индексатора не се задава име, а вместо него се задава запазената дума this.

Достъпът до индексатор на обект се извършва посредством името на променливата от типа, дефиниращ индексатора, последвана от индекса в квадратни скоби, също както се извършва достъпа до елемент на масив, например myArrayList[5].

Позовавайки се на начина, по който се обръщаме към индексаторите, можем да ги разглеждаме като средство за предефиниране на оператора []. Използването на индексатори позволява интуитивен достъп до обекти, които се състоят от множество компоненти, каквито са масивите и колекциите.

Имитация на масив чрез индексатори – пример

За да илюстрираме по-пълно дефинирането и използването на индексатори, ще използваме следващия пример. Ще дефинираме клас, който имитира поведението на масив от 32 стойности, всяка от които е или 0 или 1:

struct BitArray32

{

private uint mValue;

// Indexer declaration

public int this [int index]

{

get

{

if (index >= 0 && index <= 31)

{

// Check the bit at position index

if ((mValue & (1 << index)) == 0)

return 0;

else

return 1;

}

else

{

throw new ApplicationException(String.

Format("Index {0} is invalid!", index));

}

set

{

if (index < 0 || index > 31)

throw new ApplicationException(

String.Format("Index {0} is invalid!", index));

if (value < 0 || value > 1)

throw new ApplicationException(

String.Format("Value {0} is invalid!", value));

// Clear the bit at position index

mValue &= ~((uint)(1 << index));

// Set the bit at position index to value

mValue |= (uint)(value << index);

}

class IndexerTest

{

static void Main()

{

BitArray32 arr = new BitArray32();

arr[0] = 1;

arr[5] = 1;

arr[5] = 0;

arr[25] = 1;

arr[31] = 1;

for (int i=0; i<=31; i++)

{

Console.WriteLine("arr[{0}] = {1}", i, arr[i]);

}

Класът BitArray32 представлява масив от битове с 32 елемента, който вътрешно съхранява стойностите им в едно 32-битово поле. Елементите му достъпваме посредством дефинирания индексатор по същия начин, по който достъпваме елементите на вградените в CTS масиви. На масивите в .NET Framework ще се спрем в темата "Масиви и колекции".

Виждаме компонентите за прочитане и присвояване на стойността, които извършват проверка дали индексът е в съответния диапазон, след което чрез битови операции осъществяват достъп до посочения като параметър бит. При невалидни параметри се предизвиква изключение, чрез което се уведомява извикващия код за проблема. На изключенията ще се спрем подробно в темата "Управление на изключенията в .NET".

Проследяване на работата на индексатор

За да проследим работата на индексатора ще си послужим с приложението от демонстрациите Demo-5-Indexers.sln, което съдържа кода от горния пример. Ще изпълним следните стъпки:

Отваряме приложението и го компилираме.
С [F11] стартираме изпълнение в режим на проследяване и маркерът се позиционира на първия ред от тялото на метода Main(…):

Със следващото натискане на [F11] инициализираме обекта arr с подразбиращия се конструктор и текущ ред става присвояването arr[0] = 1.
Когато продължим проследяването, виждаме как следващият код, който се изпълнява, е компонента за присвояване на стойност на индексатора:

С [Shift-F11] прескачаме останалата част от блока и преминаваме с [F10] през другите присвоявания докато достигнем до цикъла, който прочита стойностите от масива:

В този момент при натискане на [F11] се изпълнява кодът за прочитане на стойността от масива. Забелязваме, че механизмът на изпълнение на индексаторите е същият, както на свойствата.

С помощта на инструмента IL DASM можем да си обясним приликите между свойства и индексатори. Когато разгледаме генерирания за приложението MSIL код виждаме, че индексаторите, както свойствата, се реализират от двойка методи с имена get_Item и set_Item:

Индексатори с няколко параметъра

В .NET Framework се допуска дефинирането на индексатори, приемащи повече от един параметър. Примерно обръщение към такъв индексатор е конструкцията personInfo["Бай Иван", 68]. Възможно е в един тип да се дефинират и няколко индексатора с различен набор от параметри. Индексаторите не могат да бъдат статични, тъй като реализират индексиране в рамките на дадена инстанция.

Ето още един пример за индексатор, който приема два параметъра от тип символен низ и връща целочислена стойност:

class DistanceCalculator

{

public int this[string aTown1, string aTown2]

{

get

{

if (aTown1.Equals("София") && aTown2.Equals("Варна"))

return 470;

else

throw new ApplicationException("Unknown distance!");

}

class DistanceTest

{

static void Main()

{

DistanceCalculator dc = new DistanceCalculator();

Console.WriteLine("Разстоянието между {0} и {1} е {2} " +

"километра.", "София", "Варна", dc["София", "Варна"]);

}

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

Структури

Структурите в .NET Framework представляват съвкупност от полета с данни. Te приличат много на класовете, но за разлика то тях са стойностни типове. Инстанциите на структурите имат поведение като примитивните числени типове – разполагат в стека за изпълнение на програмата, предават се по стойност и се унищожават при излизане от обхват.

За разлика от структурите класовете са типове по референция и се разполагат в динамичната памет заради което създаването и унищожаването им е по-бавно. При предаване като параметри се предава само техният адрес в динамичната памет (т. нар. референция).

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

Въпреки, че синтаксисът на езика C# го допуска, не се препоръчва в структурите да има методи с логика. Структурите трябва да се използват за да съхраняват някаква структура от данни (съвкупност от полета).

При правилна употреба заместването на класове със структури може значително да увеличи производителността. Ще се спрем по-подробно на класовете и структурите в темата "Обща система от типове".

Структурите се дефинират по същия начин, както и класовете, но вместо запазената дума "class" се използва запазената дума "struct".

Структури – пример

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

struct Point

{

public int mX, mY;

}

struct Color

{

public byte mRedValue;

public byte mGreenValue;

public byte mBlueValue;

}

struct Square

{

public Point mLocation;

public int mSize;

public Color mBorderColor;

public Color mSurfaceColor;

}

Както виждаме, структурите много приличат на класове, но основното им предназначение е да съхраняват данни.

Предаване на параметрите

В C# има три различни режима на предаване на параметрите. Ще ги разгледаме накратко, след което ще се спрем по-подробно на всеки от тях и ще илюстрираме разликите между тях с примери. Параметрите при извикване на метод могат да се предават по следните начини:

- out (изходни параметри за връщане на стойност)

Параметрите могат да не бъдат инициализирани преди предаването им. Инициализацията се извършва от извиквания метод, а преди нея достъпът е само за писане и в тялото на метода, и в кода, който го извиква.

- ref (входно-изходни параметри за предаване по референция)

Промените, които методът прави по подадените му по референция параметри, изменят истинските стойности на параметрите, а не техни копия от стека, и за това са видими от кода, извикал метода.

- in (входни параметри за предаване по стойност)

Това е подразбиращият се режим на предаване на параметрите в C#. При изпълнението на метода в стека се записват стойностите на параметрите, с които методът работи и след излизането от тялото му, когато се изтрие върха на стека, промените в параметрите остават изгубени, като стойността на локална променлива, излязла от обхват.

Параметри за връщане на стойност (out)

Предаването на out параметри се задейства, като маркираме параметъра с ключовата дума out, и в дефиницията на метода, и при извикването му. Целта на тези параметри е не методът да приема като входни данни тяхната стойност, а единствено да я инициализира и да я върне като резултат от изпълнението си. По тази причина те се наричат изходни параметри.

Изходните параметри се предават по адрес в случай на стойностен тип и по адрес на референцията (двоен указател) в случай на референтен тип. Благодарение на това при промяна на стойността им в даден метод тази промяна директно се отразява на променливата, подадена от извикващия метод.

Тъй като върнатата стойност от даден метод в C# може да бъде само една, използвайки out параметри можем да върнем на кода, извикал метода, повече стойности. Нека разгледаме следния пример за да илюстрираме връщането на стойност чрез out параметри:

public struct Point

{

public int mX, mY;

public Point(int aX, int aY)

{

mX = aX;

mY = aY;

}

public struct Dimensions

{

public int mWidth, mHeight;

public Dimensions(int aWidth, int aHeight)

{

mWidth = aWidth;

mHeight = aHeight;

}

public class Rectangle

{

private int mX, mY, mWidth, mHeight;

public Rectangle(int aX,int aY, int aWidth,int aHeight)

{

mX = aX;

mY = aY;

mWidth = aWidth;

mHeight = aHeight;

}

public void GetLocationAndDimensions(

out Point aLocation, out Dimensions aDimensions)

{

aLocation = new Point(mX, mY);

aDimensions = new Dimensions(mWidth, mHeight);

}

class TestOutParameters

{

static void Main()

{

Rectangle rect = new Rectangle(5, 10, 12, 8);

Point location;

Dimensions dimensions;

// location and dimension are not previously initialized

rect.GetLocationAndDimensions(

out location, out dimensions);

Console.WriteLine("({0}, {1}, {2}, {3})",

location.mX, location.mY,

dimensions.mWidth, dimensions.mHeight);

// Result: (5, 10, 12, 8)

}

В горния пример са дефинирани структурите Point и Dimensions, които методът GetLocationAndDimensions(…) на класа Rectangle използва за да връща чрез изходните си параметри техни инстанции.

Трябва да обърнем внимание на употребата на ключовата дума out и на това, че променливите location и dimensions не са инициализирани никъде в тялото на метода Main(…). Ако параметрите не бяха указани като такива за връщане на стойност, това не би било допустимо – получава се грешка при компилация "Use of unassigned local variable".

Примерът извлича с едно извикване на метод две стойности – местоположението и размерите на даден правоъгълник, като ги записва в инстанции на структурите Point и Dimensions.

Предаване по референция (ref)

Предаването на параметрите по референция се активира като добавим ключовата дума ref към описанието на даден параметър в дефиницията на метода и при извикването му. Такива параметри се наричат входно-изходни.

При предаване на параметри по референция при стартиране на метода в стека не се записват копия на стойностите на параметрите, а указатели към адреса в паметта на оригиналните им стойности. Така извиканият метод може както да чете информация от подадените му параметри, така и да ги изменя и да връща стойности на кода, който го е извикал.

Параметрите поп референция се предават по адрес в случай на стойностен тип и по адрес на референцията (двоен указател) в случай на референтен тип. Благодарение на това при промяна на стойността им в даден метод тази промяна директно се отразява на променливата, подадена от извикващия метод. Ще илюстрираме това с пример:

public struct Point

{

internal int mX, mY;

public static void IncorrectMultiplyBy2(Point aPoint)

{

aPoint.mX *= 2; aPoint.mY *= 2;

}

public static void MultiplyBy2(ref Point aPoint)

{

aPoint.mX *= 2; aPoint.mY *= 2;

}

static void Main()

{

Point p = new Point();

p.mX = 5;

p.mY = -8;

Console.WriteLine("p=({0},{1})", p.mX, p.mY); // 5,-8

IncorrectMultiplyBy2(p);

Console.WriteLine("p=({0},{1})", p.mX, p.mY); // 5,-8

MultiplyBy2(ref p);

Console.WriteLine("p=({0},{1})", p.mX, p.mY); // 10,-16

}

При изпълнение на примера се вижда, че в тялото на метода Main(…) не се отразяват промените в предадения в подразбиращия се режим (в случая по стойност) параметър p при извикването на метода IncorrectMultiplyBy2(…). Когато, обаче, параметърът е маркиран като ref, методът MultiplyBy2(…) успява да удвои членовете му, тъй като този метод променя директно подадената стойност, а нейно копие.

Предаване по стойност (in)

В подразбиращия се режим при извикване на метод му се подават копия от стойностите на параметрите. Реално стойностните типове се предават по стойност (предава се тяхно копие), а референтните типове се предават по референция (предава се копие на тяхната адреса в динамичната памет, към който сочат).

В по-горния пример видяхме как въпреки промяната в тялото на метода IncorrectMultiplyBy2(…) предадената по стойност променлива p не измени реалната си стойност. Трябва да обърнем внимание, че p е от стойностен тип (инстанция на структурата Point). Ако p беше референтен тип, промените в членовете му щяха да бъдат видими за кода, извикал метода. Защо това е така, въпреки че предаваме параметъра по стойност? На този въпрос ще си отговорим след като разгледаме следващия пример:

public class ClassPoint

{

internal int mX, mY;

public static void MultiplyBy2(ClassPoint aPoint)

{

aPoint.mX *= 2; aPoint.mY *= 2;

}

public static void IncorrectErase(ClassPoint aPoint)

{

aPoint = null;

}

static void Main()

{

ClassPoint p = new ClassPoint();

p.mX = 5;

p.mY = -8;

Console.WriteLine("p=({0},{1})", p.mX, p.mY); // 5,-8

MultiplyBy2(p);

Console.WriteLine("p=({0},{1})", p.mX, p.mY); // 10,-16

IncorrectErase(p);

Console.WriteLine("p=({0},{1})", p.mX, p.mY); // 10,-16

}

Забелязваме, че при обръщението към метода MultiplyBy2(…) дори и без да указваме, че параметърът се предава по референция, полетата на p успешно се удвояват. Това е така, защото класът ClassPoint е референтен тип и променливата от този тип представлява указател към паметта, където е записана същинската стойност на обекта.

При извикване на метод с предаване на параметрите по стойност в стека се прави копие на подадената променлива, която в случая е указател (референция) и операциите с това копие изменят реално оригиналната стойност на променливата в динамичната памет.

При промяна на даден параметър, подаден по стойност, например при изменянето на параметъра aPoint в тялото на метода IncorrectErase(…), се изменя единствено копираният на стека указател, а не реалната стойност на обекта. Затова при излизане от метода IncorrectErase(…), въпреки че за параметъра aPoint е зададена стойност null, променливата p не е променена и сочи към обекта, който е бил подаден при извикването.

Променлив брой параметри

В C# можем да дефинираме методи с променлив брой параметри. Пример за такъв метод, който неведнъж сме ползвали в нашите примери, е Console.WriteLine(…). Предаването на променлив брой параметри в C# се реализира чрез следния синтаксис:

static int Sum(params int[] aValues)

{

int retval = 0;

foreach(int arg in aValues)

{

retval += arg;

}

return retval;

}

static void Main()

{

int sum = Sum(1, 2, 3, 4, 5);

Console.WriteLine(sum); // The result is 15

}

В горния пример дефинирахме метода Sum(…), който изчислява сумата на произволен брой цели числа от тип int. Указваме, че методът приема произволен брой параметри със служебната дума params. Тя може да се използва най-много веднъж в дефиницията на даден метод и задължително се прилага към последния изреден параметър, който трябва да бъде масив, приемащ множеството от параметрите. На метода от примера могат да бъдат подадени както произволен брой променливи от тип int, така и масив от тип int, т. е. допустими извиквания са както Sum(1,2,3), така и Sum(new Object[]{1,2,3}).

Предаване на променлив брой параметри от различен тип

В някои случаи е възможно да се нуждаем от метод, който да приема произволен брой параметри, но не задължително от един и същ тип. Например такъв би могъл да бъде методът, който изчислява сума на произволен брой целочислени параметри, включително и такива, зададени като символни низове. За този метод допустими обръщения биха били sum(1, 2, 3) както и sum(1, "2", 3).

За да реализираме такъв метод, можем да предаваме параметрите чрез масив от по-общ тип, например чрез масив от инстанции на типа System.Object, който е базов тип за всички типове в .NET Framework. Така можем да работим с произволно множество от параметри, чиито тип различаваме с помощта на оператора за принадлежност към тип is. В нашия случай за да използваме параметри от тип символен низ, първо ги конвертираме към желания целочислен тип. Ето примерна реализация на описаната идея:

int Sum(params Object[] values)

{

int retval = 0;

foreach(Object arg in values)

{

if (arg is int)

{

retval += (int)arg;

}

else if (arg is string)

{

retval += int.Parse((string)arg);

}

return retval;

}

В този вариант методът Sum(…) извлича целочислената стойност от низа, когато се натъкне на такъв. Забелязваме употребата на оператора is, който връща true ако първият му аргумент "е" от типа, подаден като втори аргумент и false в противен случай.

В примера сме използвали операциите (int)arg и (string)arg, които наричаме преобразуване на типове. На тях ще се спрем след малко, когато разглеждаме предефинирането на оператори и наследяване.

Предефиниране на оператори

Както и в други обектно-ориентирани езици (например C++), в C# някои оператори могат да бъдат предефинирани. Могат да се предефинират унарни (приемащи един аргумент) и бинарни (приемащи два аргумента) оператори, действащи върху дефинирани от потребителя типове. Предефинирането на оператори се извършва, като разработчикът предоставя собствена имплементация за действието на вградените оператори върху дефинираните от него типове.

Приоритет и асоциативност

Операторите, освен с броя на аргументите си, се характеризират с приоритет и асоциативност. Когато се съставят изрази, съдържащи прилагане на повече от един оператор, редът на прилагането им се определя от приоритета – операторите се прилагат в реда на намаляване на приоритета им. Нека например разгледаме израза a*b+c. В този случай умножението ще се извърши преди събирането, тъй като е с по-висок приоритет, т.е. ако a=1, b=2 и c=5 резултатът ще бъде 7.

Ако имаме израз, който прилага много пъти един и същ оператор, редът на прилагането на тези оператори не може да се определи с помощта на приоритета им. В такъв случай той зависи от асоциативността, която може да бъде лява и дясна. Например, ако имаме израза 1024 / 128 / 8, Резултатът от този израз е 1, тъй като операторът / е лявоасоциативен, т.е. се прилага от ляво на дясно.

В .NET Framework може да се предефинира действието на операторите върху дефинираните от потребителя типове, но не и техните приоритет и асоциативност.

Операторите в C#

По долу даден е списък с всички оператори в C#, изреден по ред на приоритета им, намаляващ от ляво надясно и отгоре надолу:

- основни: (x) x.y f(x) a[x] x++ x-- new typeof sizeof checked unchecked

- унарни: + - ! ++x --x (T)x

- мултипликативни: * / %

- адитивни: + -

- побитови (bitshift): << >>

- за сравнение: < > <= >= is as

- за равенство: == !=

- логически: & ^ |

- условни: && || c?x:y

- за присвояване: = += -= *= /= %= <<= >>= &= ^= |=

Предефинируеми оператори

Не всички оператори в C# могат да се предефинират. Предефинируеми са унарните оператори +, -, !, ~, ++, --, true и false, бинарните +, -, *, /, %, &, |, ^, <<, >>, ==, !=, >, <, >= и <=, и операторите за явно (имплицитно) и неявно (експлицитно) преобразуване на типове.

Дефиницията на предефиниран оператор в C# представлява дефиниция на статичен метод, приемащ един или два параметъра и връщащ някакъв резултат, към който е указана ключовата дума operator.

Предефиниране на оператори – пример

За да илюстрираме предефинирането на оператори ще дефинираме тип "обикновена дроб" (Fraction), който съдържа в себе си обикновена дроб (съставена от числител и знаменател). Ще предефинираме всички основни математически операции за работа с обикновени дроби (събиране, изваждане, умножение, деление и т.н.), както и някои други оператори, които улесняват работата с типа Fraction. Ето една примерна реализация:

FractionsTest.cs

public struct Fraction

{

private long mNumerator;

private long mDenominator;

public Fraction(long aNumerator, long aDenominator)

{

// Cancel the fraction and make the denominator positive

long gcd = GreatestCommonDivisor( aNumerator, aDenominator);

mNumerator = aNumerator / gcd;

mDenominator = aDenominator / gcd;

if (mDenominator < 0)

{

mNumerator = -mNumerator;

mDenominator = -mDenominator;

}

private static long GreatestCommonDivisor(

long aNumber1, long aNumber2)

{

aNumber1 = Math.Abs(aNumber1);

aNumber2 = Math.Abs(aNumber2);

while (aNumber1 > 0)

{

long newNumber1 = aNumber2 % aNumber1;

aNumber2 = aNumber1;

aNumber1 = newNumber1;

}

return aNumber2;

}

public static Fraction operator +(Fraction aF1, Fraction aF2)

{

long num = aF1.mNumerator*aF2.mDenominator +

aF2.mNumerator*aF1.mDenominator;

long denom = aF1.mDenominator*aF2.mDenominator;

return new Fraction(num, denom);

}

public static Fraction operator -(Fraction aF1, Fraction aF2)

{

long num =

aF1.mNumerator*aF2.mDenominator -

aF2.mNumerator*aF1.mDenominator;

long denom = aF1.mDenominator*aF2.mDenominator;

return new Fraction(num, denom);

}

public static Fraction operator *(Fraction aF1, Fraction aF2)

{

long num = aF1.mNumerator*aF2.mNumerator;

long denom = aF1.mDenominator*aF2.mDenominator;

return new Fraction(num, denom);

}

public static Fraction operator /(Fraction aF1, Fraction aF2)

{

long num = aF1.mNumerator*aF2.mDenominator;

long denom = aF1.mDenominator*aF2.mNumerator;

return new Fraction(num, denom);

}

// Unary minus operator

public static Fraction operator -(Fraction aFrac)

{

long num = -aFrac.mNumerator;

long denom = aFrac.mDenominator;

return new Fraction(num, denom);

}

// Explicit conversion to double operator

public static explicit operator double(Fraction aFrac)

{

return (double) aFrac.mNumerator / aFrac.mDenominator;

}

// Operator ++ (the same for prefix and postfix form)

public static Fraction operator ++(Fraction aFrac)

{

long num = aFrac.mNumerator + aFrac.mDenominator;

long denom = aFrac.mDenominator;

return new Fraction(num, denom);

}

// Operator -- (the same for prefix and postfix form)

public static Fraction operator --(Fraction aFrac)

{

long num = aFrac.mNumerator - aFrac.mDenominator;

long denom = aFrac.mDenominator;

return new Fraction(num, denom);

}

public static bool operator true(Fraction aFraction)

{

return aFraction.mNumerator != 0;

}

public static bool operator false(Fraction aFraction)

{

return aFraction.mNumerator == 0;

}

public static implicit operator Fraction(double aValue)

{

double num = aValue;

long denom = 1;

while (num - Math.Floor(num) > 0)

{

num = num * 10;

denom = denom * 10;

}

return new Fraction((long)num, denom);

}

public override string ToString()

{

if (mDenominator != 0)

{

return String.Format("{0}/{1}",

mNumerator, mDenominator);

}

else

{

return ("NaN"); // not a number

}

class FractionsTest

{

static void Main()

{

Fraction f1 = (double)1/4;

Console.WriteLine("f1 = {0}", f1);

Fraction f2 = (double)7/10;

Console.WriteLine("f2 = {0}", f2);

Console.WriteLine("-f1 = {0}", -f1);

Console.WriteLine("f1 + f2 = {0}", f1 + f2);

Console.WriteLine("f1 - f2 = {0}", f1 - f2);

Console.WriteLine("f1 * f2 = {0}", f1 * f2);

Console.WriteLine("f1 / f2 = {0}", f1 / f2);

Console.WriteLine("f1 / f2 as double = {0}",

(double)(f1 / f2));

Console.WriteLine(

"-(f1+f2)*(f1-f2/f1) = {0}", -(f1+f2)*(f1-f2/f1));

}

Горният пример дефинира клас, представляващ обвивка на обикновена дроб, или иначе казано, той моделира множеството на рационалните числа. За да могат обектите от типа Fraction действително да имат поведение като на числа, той предефинира унарните оператори -, ++, --, true, false и бинарните +, -, * и /.

Забелязваме също предефинирането на явно преобразуване от Fraction към double и имплицитно от double към Fraction. Добре е да обърнем внимание на това, че вида на преобразуването не е избран случайно. Явно преобразуване се дефинира, когато имаме конвертиране със загуба, тъй като изисква изрично упоменаване на преобразованието. В горния пример конвертирането към double е такова, защото някои рационални числа не могат да бъдат представени с плаваща запетая без загуба на точност. Ако дефинираме преобразуването към double като имплицитно би било възможно по невнимание да присвоим дроб на число с плаваща запетая, но като изискваме изрично преобразуване компилаторът не допуска потенциално опасната операция. Тъй като конвертирането на число с плаваща запетая към рационално винаги може да се извърши без загуба няма нужда да го определяме като явно.

Виждаме, че е допустимо и предефинирането на операторите true и false. Това позволява използването на инстанции от тип Fraction в булеви изрази. Най-лесно това може да се илюстрира с един прост пример. Нека разгледаме следната модифицирана версия на метода ToString() на Fraction:

public override string ToString()

{

if (this)

{

return String.Format("{0}/{1}", mNumerator, mDenominator);

}

else

{

return ("0");

}

Така промененият метод, освен че връща текстовото представяне на дробта, също и проверява дали тя е нулева дроб и стойност 0 в този случай. При изчисляването на стойността на булевият израз (this) се изпълнява тялото на предефинирания оператор true.

Проследяване на изпълнението на предефинирани оператори

Използвайки дебъгера на Visual Studio .NET ще проследим изпълнението на кода от примера. За целта:

Отваряме приложението Demo-6-Operators.sln и го компилираме.
С [F11] стартираме програмата в режим на проследяване и маркерът се позиционира на първия ред, където присвояваме стойност от тип double към обекта f1 от клас Fraction:

Когато още веднъж натиснем [F11], забелязваме, че при това присвояване по премълчаване се изпълнява предефинираният оператор за имплицитно преобразуване и ходът на изпълнение на програмата продължава в тялото на неговата дефиниция:

Продължаваме с [F11] да проследяваме изпълнението на програмата и виждаме как при изпълняването на всяка операция с обектите от тип Fraction се изпълнява кода на съответните предефинирани оператори.

Наследяване

Ще се спрем отново на понятието наследяване поради особената му важност в обектно-ориентираното програмиране. Няма да обясняваме теоретичната страна наследяването, тъй като това е извън обхвата на настоящата тема. Ще обясним само как да извършваме наследяване на класове със средствата на езика C#.

В C# синтаксиса и семантиката на наследяването са близки до тези в други езици за обектно-ориентирани езици, като C++ и Java. За да направим даден клас Derived наследник на даден друг клас Base, трябва след декларацията на класа Derived да сложим двоеточие, следвано от името на класа Base. За да илюстрираме това, ще разширим един от примерите, които разгледахме по-горе в темата:

class Student

{

private string mName;

private int mStudentId;

private string mPosition = "Student";

public Student(string aName, int aStudentId)

// ...

public Student(string aName) : this(aName, -1)

// ...

public void PrintName()

{

Console.WriteLine("Student name: {0}", mName);

}

public sealed class Kiro : Student

{

public Kiro() : base("Бай Киро", 12345)

{

}

public void Oversleep()

{

//...

}

static void Main()

{

Student tosho = new Student("Тошо", 54321);

Kiro kiro1 = new Kiro();

Student kiro2 = new Kiro();

// Kiro kiro3 = new Student("Бай Киро", 12345); // invalid!

tosho.PrintName();

kiro1.PrintName();

// kiro2.Oversleep();

((Kiro)kiro2).Oversleep();

}

Виждаме, че класът Kiro наследява класа Student, с което приема от него всички негови полета, свойства, методи и други членове. Разбира се, наследените членове са достъпни за класа Kiro, само ако не са били обявени като private в базовия клас Student.

Трябва да обърнем внимание на третия ред от метода Main(…):

Student kiro2 = new Kiro();

В него създаваме обект от тип Kiro, но го присвояваме на променлива от тип Student. Тази операция е напълно коректна, тъй като присвояването на обект от наследен тип в променлива от базов тип е позволено. Обратното, обаче, не е в сила и ако разкоментираме втория ред, приложението не би се компилирало.

Обръщението kiro1.PrintName() е също напълно валидно, тъй като класът Kiro наследява всички членове на базовия клас Student и затова съдържа дефиницията на метода PrintName().

Класове, които не могат да се наследяват (sealed)

В дефиницията на класа Kiro забелязваме употребата на ключовата дума sealed. С нея указваме, че Kiro не може да бъде наследяван от друг клас. Това е пример как чрез забраняването на наследяване можем да създаваме йерархии от класове по-близки до реалните обекти, които представяме. В конкретния пример е удачно да маркираме класа като sealed, тъй като той представлява категория, която не може повече да се конкретизира (Kiro е клас, който съответства на един конкретен обект от действителността, а не на група различни обекти).

Наследяване при структурите

В някои обектно-ориентирани езици, като например C++, се допуска наследяване на структури. В C# и в другите .NET езици това не е позволено.

Структурите в .NET Framework не могат да се наследяват по между си и не могат да наследяват и да бъдат наследявани от класове.

Нека направим един прост експеримент, за да онагледим невъзможността за наследяване на структури. Със следния код ще създадем една тривиална структура:

public struct TestStruct

{

}

Отново с помощта на инструмента ildasm получаваме MSIL кода за тази проста структура:

Забелязваме, че структурата TestStruct наследява от System.ValueType и, което в нашия случай е по-интересно, в дефиницията й фигурира модификаторът sealed. Това указва на компилатора, че този тип не може да бъде наследен. Следната ситуация, при която се опитваме да наследим структура от клас, е също недопустима и предизвиква грешка при опит за компилация:

public class TestClass

{

}

public struct AnotherTestStruct : TestClass

{

}

Конвертиране на обекти

Нека сега разгледаме конвертирането (casting) на обект от даден тип към обект от друг тип. При класове в отношение наследник-наследен можем да конвертираме нагоре по йерархията (upcasting) и надолу по йерархията (downcasting). Нека обясним тези две понятия.

Конвертиране нагоре (upcasting)

С операцията Student kiro2 = new Kiro() от по-горния пример присвояваме обект от клас Kiro на променлива от клас Student, т.е. конвертираме (преобразуваме) обекта към класа Student. В този случай използваме конвертиране нагоре (upcasting), тъй като Student е базов клас на Kiro или, иначе казано, се намира по-горе в йерархията. Тази операция е напълно допустима, тъй като kiro2 действително е студент.

В нашия пример следващият ред

Kiro kiro3 = new Student("Бай Киро", 12345);

е коментиран, тъй като операцията, която там се опитваме да извършим, е недопустима и този код не би могъл да се компилира, тъй като обектът, който конструираме посредством new Student("Бай Киро", 12345) не е инстанция на класа Kiro (въпреки че го наподобява по стойностите на полетата, той не съдържа метода Oversleep()).

Конвертиране надолу (downcasting)

С обръщението (Kiro)kiro2 разглеждаме обекта kiro2 като обект от тип Kiro. Тази операция наричаме конвертиране надолу, или downcasting. Типът на израза в скобите е Kiro и заради това можем свободно да извикаме метода Oversleep(), защото въпреки, че е сочен от променлива от тип Student, този израз фактически е инстанция на класа Kiro и съдържа имплементация на метода. На долната илюстрация виждаме, че и Visual Studio .NET разпознава типа на израза като ни предоставя членовете му в падащото меню за автоматично завършване на израза:

В C# конвертирането надолу е синтактично валидна операция, независимо дали обектът, който конвертираме, е действително от въпросния наследяващ типа. Например, закоментираното обръщение Kiro kiro3 = new Student("Бай Киро", 12345) би могло да се зададе във вида Kiro kiro3 = (Kiro)new Student("Бай Киро", 12345), което се компилира успешно от C# компилатора без дори да генерира предупреждение, тъй като по време на компилация не е известно дали типовете са съвместими. При изпълнението на този код, обаче, въпросното преобразуваме ще предизвика изключение System.InvalidCastException, тъй като конструираният обект не е от тип Kiro или съвместим с него тип.

Интерфейси

Интерфейсите описват функционалност (група методи, свойства, индексатори и събития), която се поддържа от множество обекти. Подобно на класовете и структурите те се състоят от членове, но се различават от тях по това, че дефинират само прототипите на членовете си, без конкретната им реализацията.

От интерфейсите не могат да се създават обекти чрез инстанциране. Интерфейсите се реализират от класове или структури, които имплементират всички дефинирани в тях членове. Конкретните имплементации на даден интерфейс вече могат да се инстанцират и да се присвояват на променливи от тип интерфейс.

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

Интерфейсите могат да съдържат методи, свойства, индексатори и събития. В интерфейс не могат да се дефинират конструктори, деструктори, полета и вложени типове и не могат да се предефинират оператори.

Интерфейсите в C# не могат и да съдържат и константи, за разлика от други обектно-ориентирани езици, като Java, където това е допустимо.

Към членовете на интерфейс не може да се прилагат модификатори на достъпа – по подразбиране всички членове са с глобална видимост, все едно е указан модификатор public. Интерфейс може да наследи един или повече други интерфейса, като е възможно да предефинира или скрива техните членове. За пример да разгледаме няколко дефиниции на интерфейси:

GeometryInterfaces.cs

interface IMovable

{

void Move(int aDeltaX, int aDeltaY);

}

interface IShape

{

void SetPosition(int aX, int aY);

double CalculateSurface();

}

interface IPerimeterShape : IShape

{

double CalculatePerimeter();

}

interface IResizable

{

void Resize(int aWeight);

void Resize(int aWeightX, int aWeightY);

void ResizeByX(int aWeightX);

void ResizeByY(int aWeightY);

}

interface IDrawableShape : IShape, IResizable, IMovable

{

void Delete();

Color Color

{

get;

set;

}

Дефинирахме следните интерфейси: IMovable, IShape, IPerimeterShape, IResizable и IDrawableShape. Те илюстрират дефинирането на методи и свойства в интерфейс, както и наследяването между интерфейси (което може да бъде и множествено, както е например при IDrawableShape).

Реализиране на интерфейс

Тъй като не съдържат данни и описана функционалност, интерфейсите не могат да се инстанцират, а само да се реализират (имплементират) от класове и структури, от които вече могат да се създават инстанции.

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

GeomertyImplementation.cs

public class Square : IShape

{

private int mX, mY, mSize;

public Square(int aX, int aY, int aSize)

{

mX = aX;

mY = aY;

mSize = aSize;

}

public void SetPosition(int aX, int aY) // From IShape

{

mX = aX;

mY = aY;

}

public double CalculateSurface() // Derived from IShape

{

return mSize * mSize;

}

public struct Rectangle : IShape, IMovable, IResizable

{

private int mX, mY, mWidth, mHeight;

public Rectangle(int aX, int aY, int aWidth, int aHeight)

{

mX = aX;

mY = aY;

mWidth = aWidth;

mHeight = aHeight;

}

public void SetPosition(int aX, int aY) // From IShape

{

mX = aX;

mY = aY;

}

public double CalculateSurface() // Derived from IShape

{

return mWidth * mHeight;

}

public void Move(int aDeltaX, int aDeltaY) // From IMovable

{

mX += aDeltaX;

mY += aDeltaY;

}

public void Resize(int aWeight) // Derived from IResizable

{

mWidth = mWidth * aWeight;

mHeight = mHeight * aWeight;

}

public void Resize(int aWeightX, int aWeightY) // IResizable

{

mWidth = mWidth * aWeightX;

mHeight = mHeight * aWeightY;

}

public void ResizeByX(int aWeightX) // From IResizable

{

mWidth = mWidth * aWeightX;

}

public void ResizeByY(int aWeightY) // From IResizable

{

mHeight = mHeight * aWeightY;

}

public class Circle : IPerimeterShape

{

private int mX, mY, mRadius;

public Circle(int aX, int aY, int aRadius)

{

mX = aX;

mY = aY;

mRadius = aRadius;

}

public void SetPosition(int aX, int aY) // From IShape

{

mX = aX;

mY = aY;

}

public double CalculateSurface() // From IShape

{

return Math.PI * mRadius * mRadius;

}

public double CalculatePerimeter() // From IPerimeterShape

{

return 2 * Math.PI * mRadius;

}

В този пример виждаме как класът Square реализира интерфейса IShape и как класът Rectangle реализира едновременно няколко интерфейса: IShape, IMovable и IResizable. Класът Circle реализира интерфейса IPerimeterShape, но понеже този интерфейс е наследник на IShape, това означава, че Circle на практика имплементира едновременно интерфейсите IShape и IPerimeterShape. Забележете, че всички методи от интерфейсите са декларирани като публични. Това се изисква по спецификация, защото всички методи в даден интерфейс са публични (въпреки, че нямат модификатор public). Няма да дискутираме как работят самите имплементации, защото това е извън целите на примера.

Имплементирането на интерфейс много прилича на наследяване. Можем да считаме, че то действително е особен вид наследяване, защото също задава "is-a" релация между интерфейса и типа, който го реализира. Например, в сила са твърденията че квадратът и правоъгълникът са форми, а кръгът също е форма, и освен това има периметър.

След като реализирането на интерфейс създава "is-a" релация, можем да говорим и за множество от обекти от тип интерфейс – това са инстанциите на всички класове, които реализират интерфейса пряко или косвено (реализирайки интерфейс, който го наследява), както и техните наследници.

Реализиране на интерфейс от структура

Интересно в горния пример е, че типът Rectangle не е клас, а структура. Това илюстрира една разлика между наследяването на клас и реализирането на интерфейс – второто може да се извърши и от структура.

Въпреки, че е възможно, не е препоръчителна практика структурите да реализират функционалност и да имплементират интерфейси. Структурите трябва да се използват за съхранение на проста съвкупност от полета. Ако случаят не е такъв, трябва да се използва клас.

Обекти от тип интерфейс

Чрез следващия пример ще демонстрираме създаването на обекти от тип интерфейс. Реално ще създаваме обекти от типове, които наследяват даден интерфейс:

GeometryTest.cs

class GeomertyTest

{

public static void Main()

{

Square square = new Square(0, 0, 10);

Rectangle rect = new Rectangle(0, 0, 10, 12);

Circle circle = new Circle(0, 0, 5);

if (square is IShape)

{

Console.WriteLine("{0} is IShape", square.GetType());

}

if (rect is IResizable)

{

Console.WriteLine("{0} is IResizable", rect.GetType());

}

IShape[] shapes = {square, rect, circle};

foreach (IShape shape in shapes)

{

shape.SetPosition(5, 5);

if (shape is IPerimeterShape)

{

Console.WriteLine("{0} is IPerimeterShape", shape);

}

В горния пример създадохме масив от обекти от тип IShape и към всички приложихме действието SetPosition(…) полиморфно, т. е. без да се интересуваме от точния им тип – единствено знаем, че обектите поддържат методите от интерфейса. Кодът от примера се компилира и изпълнява без грешка и отпечатва следния резултат:

Square is IShape

Rectangle is IResizable

Circle is IPerimeterShape

Виждаме, че макар и да не можем директно (с конструктор) да създадем обект от тип интерфейс, можем през променлива от този тип да достъпваме обекти от класовете, които го реализират.

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

Запазената дума is

Отново ще обърнем внимание на запазената дума is, която представихме при разглеждането на предаването на произволен брой параметри. Обръщението <обект> is <тип> връща true ако обектът е от дадения тип и false в противен случай. Трябва да имаме предвид, че обектите от тип-наследник са обекти и от базовия тип, за това <обект> is <базов_тип> винаги връща true.

В горния пример това обръщение се среща три пъти, като при първите два от тях по време на компилация получаваме предупреждение "The given expression is always of the provided type" – съобщение, с което сме напълно съгласни. Действително, типът на обектите circle и rect се определя по време на компилация и още тогава е известно, че проверяваното условие е винаги истина.

За обръщението в тялото на цикъла не получаваме предупреждение и в този случай на употреба виждаме истинската мощ на оператора is – проверка за типа на обект, който не е известен в момента на компилация.

Явна имплементация на интерфейс

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

public interface I1

{

void Test();

}

public interface I2

{

void Test();

void AnotherTest();

}

public class TestImplementation : I1, I2

{

public void Test()

{

Console.WriteLine("Test() called");

}

Горният код е допустим в C#, но използването му не се препоръчва. То създава затруднения, от една страна, защото не е ясно в кой интерфейс е дефиниран методът Test() в класа TestImplementation, и от друга, защото няма възможност да предостави различни имплементации за метода от различните интерфейси.

За да се справим с описания проблем можем да използваме явната имплементация на интерфейси (explicit interface implementation). В C# можем да дефинираме в един тип два метода с еднаква сигнатура, стига поне единият от тях да е явна имплементация на метод от интерфейс. Явна имплементация се задава, като изрично се укаже на кой интерфейс принадлежи имплементираният член, както в примера:

public class TestExplicit : I1, I2

{

void I1.Test()

{

Console.WriteLine("I1.Test() called");

}

void I2.Test()

{

Console.WriteLine("I2.Test called");

}

void I2.AnotherTest()

{

Console.WriteLine("I2.AnotherTest called");

}

public void Test()

{

Console.WriteLine("TestExplicit.Test() called");

}

public static void Main()

{

TestExplicit t = new TestExplicit();

t.Test();

// Prints: TestExplicit.Test() called

I1 i1 = (I1) t;

i1.Test();

// Prints: I1.Test() called

I2 i2 = (I2) t;

i2.Test();

// Prints: I2.Test() called

}

Виждаме как при явна имплементация на интерфейс трябва да укажем името на интерфейса в дефиницията на реализирания член, а за да го достъпим трябва да преобразуваме обекта към интерфейса. Методите, принадлежащи на явно имплементирани интерфейс, не могат да бъдат публични или да имат друг модификатор за достъп. Те винаги private.

Не е позволено да имплементираме явно само някои членове от един интерфейс. В горния пример ако променим дефиницията на метода I2.AnotherTest() на public void AnotherTest(), компилаторът ще съобщи за грешка.

При изпълнение на примерния код се получава следният резултат:

TestExplicit.Test() called

I1.Test() called

I2.Test called

Абстрактни класове

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

За пример нека разгледаме следния абстрактен клас:

AbstractTest.cs

public abstract class Car

{

public void Move()

{

// Move the car

}

abstract public int TopSpeed

{

// Retrieve the top speed in Kmph

get;

}

public abstract string BrandName

{

get;

}

Дефинирахме клас, който реализира само един от членовете си – метода Move() и дефинира други два, без да ги реализира – свойствата BrandName и TopSpeed.

Абстрактните класове, подобно на интерфейсите, ни помагат по-адекватно да моделираме зависимости от реалният свят, защото чрез тях могат да се представят абстрактни същности. В нашия пример невъзможността за инстанциране на класа Car има смисъл, тъй като и в реалността не можем да имаме кола с неопределена марка.

Абстрактни членове

Ключовата дума abstract в декларацията на класа го определя като абстрактен. Виждаме, че тя може да се приложи и към член. Абстрактни могат да бъдат методите, свойствата, индексаторите и събитията.

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

Ако в един клас е дефиниран абстрактен член, класът задължително трябва да бъде обявен за абстрактен. В противен случай получаваме грешка при компилация. Обратното не е задължително – допустимо е да имаме абстрактен клас, на който всички членове са дефинирани.

Наследяване на абстрактни класове

Тъй като абстрактните класове са класове, те имат същата структура - същият набор от членове (полета, константи, вложени типове и т. н.), същите модификатори на видимостта и дори същите механизми за наследяване, но с някои особености. Нека разширим предходния пример:

AbstractTest.cs

public class Trabant : Car

{

public override int TopSpeed

{

get

{

return 120;

}

public override string BrandName

{

get

{

return "Trabant";

}

public class Porsche : Car

{

public override int TopSpeed

{

get

{

return 250;

}

public override string BrandName

{

get

{

return "Porsche";

}

public class AbstractTest

{

static void Main()

{

Car[] cars = new Car[] {new Trabant(), new Porsche()};

foreach (Car car in cars)

{

Console.WriteLine("A {0} can go {1} Kmph",

car.BrandName, car.TopSpeed);

}

При изпълнението на този код получаваме следния резултат:

A Trabant can go 120 Kmph

A Porsche can go 250 Kmph

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

В примера ползвахме ключовата дума override, с която указваме, че даден метод в класа наследник припокрива (замества) оригиналния наследен метод от базовия си клас. В случая базовия клас не предоставя имплементация за припокритите методи, така че припокриването е задължително. Ще разгледаме ключовата дума override и нейното действие след малко. Нека сега продължим с абстрактните класове.

Частично реализиране на абстрактните членове

Възможно е абстрактен клас, съдържащ абстрактни членове, да бъде наследен, без всичките му абстрактни членове да бъдат реализирани. Възможно е също клас, който имплементира абстрактните членове на абстрактния си родител, да дефинира допълнително и свои членове, също абстрактни. В този случай класът-наследник също трябва да бъде деклариран като абстрактен, защото съдържа абстрактни членове.

Тези възможности правят още по-гъвкав инструментариума за създаване на йерархии от класове и моделиране на реалния свят. Ще илюстрираме тази възможност със следното разширение на предходния пример:

AbstractTest.cs

abstract public class TurboCar : Car

{

protected Boolean mTurboEnabled = false;

public void EnableTurbo()

{

mTurboEnabled = true;

}

public void DisableTurbo()

{

mTurboEnabled = false;

}

public class TrabantTurbo : TurboCar

{

override public int TopSpeed

{

get

{

return mTurboEnabled ? 220 : 120;

}

override public string BrandName

{

get

{

return "Trabant Turbo";

}

public class AbstractTest

{

static void Main()

{

TurboCar turboCar = new TrabantTurbo();

Console.WriteLine("A {0} can go {1} Kmph",

turboCar.BrandName, turboCar.TopSpeed);

turboCar.EnableTurbo();

Console.WriteLine(

"A {0} can go {1} Kmph with turbo enabled",

turboCar.BrandName, turboCar.TopSpeed);

}

Създадохме класа TrabantTurbo, който реализира абстрактните свойства, индиректно наследени от класа TurboCar. Класът TurboCar е разширение на класа Car, който също като него е абстрактен, но предоставя допълнителна функционалност за включване на режим "турбо".

Ако един клас наследи от абстрактен и не предостави дефиниции за всички негови абстрактни членове, той трябва задължително също да бъде обявен за абстрактен.

След изпълнението на примера получаваме следния резултат:

A Trabant Turbo can go 120 Kmph

A Trabant Turbo can go 220 Kmph with turbo enabled

Виртуални членове

В дефинициите на членовете в горните примери забелязваме употребата на запазената дума override. Без нея те не биха могли да бъдат компилирани. Това е така, защото въпросните членове са виртуални.

Виртуалните членове са един по-особен вид членове, без които полиморфизмът би бил неосъществим. Тяхната особеност проличава при наследяване – на наследяващите класове се дава възможност вместо изцяло да пресъздадат даден наследен виртуален метод, просто да предоставят своя имплементация на същия. Така, ако работим с обект от наследения клас през референция към базовия, той ще разполага с имплементациите, които наследникът е предоставил. Ще си изясним този механизъм при разглеждането на предефиниране и скриване на виртуални членове.

Виртуални членове се дефинират, като в дефиницията им се укаже ключовата дума virtual. Всички абстрактни членове, включително и тези, дефинирани в интерфейсите (и те са абстрактни, тъй като нямат имплементация), са винаги виртуални. Поради тази причина в някои обектно-ориентирани езици за програмиране (например в C++) абстрактните членове се наричат още "чисто виртуални".

Предефиниране и скриване

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

Когато се използва ключовата дума override, се реализира предефиниране на виртуалния член, а когато се използва ключовата дума new – скриване, което е и опцията, която се подразбира когато не се укаже никаква ключова дума.

Когато в наследен клас се предефинира виртуален член на базовия, този член е виртуален и в наследения клас.

Най-лесно ще доловим разликата между скриването и предефинирането на членове, като първо обърнем внимание на следната модификация на по-горния пример. В нея вместо абстрактен сме използвали нормален, конкретен клас, който съдържа дефиниции на свойствата, връщащи подразбиращи се стойности и вместо override сме използвали new:

NonAbstractTest.cs

public class Car

{

public virtual int TopSpeed

{

// Retrieve the top speed in Kmph

get

{

return -1; // Default value

}

public virtual string BrandName

{

get

{

return "unknown"; // Default value

}

public class Trabant : Car

{

new public int TopSpeed

{

get

{

return 120;

}

new public string BrandName

{

get

{

return "Trabant";

}

public class Porsche : Car

{

new public int TopSpeed

{

get

{

return 250;

}

new public string BrandName

{

get

{

return "Porsche";

}

public class NonAbstractTest

{

static void Main()

{

Car[] cars = new Car[] {new Trabant(), new Porsche()};

foreach (Car car in cars)

{

Console.WriteLine("A {0} can go {1} Kmph",

car.BrandName, car.TopSpeed);

}

При изпълнението на този код получаваме следния, донякъде разочароващ, резултат:

A unknown can go -1 Kmph

Причината резултатът да се разминава с очакванията ни е, че при скриването на членовете наследяващият клас не предоставя своята дефиниция на базовия. Така, когато достъпваме обект от наследен клас през референция към обект от базовия, разполагаме само с неговите собствени реализации (на базовия клас). Поради това не можем да използваме полиморфизъм – когато достъпваме обект от базов клас, независимо от специфичният му тип, винаги ще ползваме имплементацията, дефинирана в базовия, т. е. той може приеме само една форма.

Трябва да отбележим, че ако пропуснем запазената дума new, поведението на кода ще бъде същото, но ще получим предупреждение от компилатора "The keyword new is required on '<method_name>' because it hides inherited member".

Ако в горния пример заменим new с override, ще задействаме механизма на полиморфизма и резултатът ще бъде следния:

A Trabant can go 120 Kmph

A Porsche can go 250 Kmph

Ако в горния пример пропуснем да обявим членовете TopSpeed и BrandName като виртуални, ще получим същия разочароващ резултат, както и преди:

A unknown can go -1 Kmph

Виждаме, че при използването на полиморфизъм има много варианти да сбъркаме и да получим неправилно поведение. Затова можем да запомним следното правило:

За да действа полиморфизмът, трябва полиморфният метод в базовия тип да е виртуален (да е обявен като virtual, abstract или да е член на интерфейс) и в класа наследник да е имплементиран с override.

Клас диаграми

Клас диаграмите са стандартно графично средство за изобразяване на йерархии от типове, предоставено ни от езика за моделиране UML (Unified Modeling Language). Ще се запознаем съвсем накратко с клас диаграмите без да претендираме за изчерпателност, тъй като моделирането с UML е необятна тема, на която са посветени хиляди страници и тази материя е извън обхвата на настоящата тема.

При многократно наследяване е възможно да се получат йерархии, които са големи и сложни и по тази причина са трудни за възприемане. Чрез клас диаграмите се създава визуална представа за взаимовръзките между типовете и така се улеснява възприемането им. С помощта на клас диаграмите можем да погледнем системата, която разработваме "от птичи поглед", което ни помага да си създадем значително по-ясна представа за нея, отколкото ако преглеждаме множество файлове със сорс код.

Изобразяване на типовете и връзките между тях

В UML клас диаграмите типовете се изобразяват като правоъгълници, в които са изписани членовете им, евентуално с отбелязана степен на видимост пред името: + за public, # за protected и - за private. Ето един пример (класът Rectangle):

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

Наследяване

Наследяването на клас и имплементирането на интерфейс се изобразява със затворена стрелка (), като стрелките, обозначаващи наследяване и имплементиране се различават по това, че първите обикновено са плътни, а вторите – пунктирани:

В примера класът FilledRectangle наследява класа Rectangle, а класът Square имплементира интерфейса ISurfaceCalculatable, а.

Асоциация, агрегация, композиция

Връзките между типовете се изобразяват с отворена стрелка (). Тези връзки се наричат още асоциациационни връзки (association links).

Асоциационните връзки могат да бъдат три вида (асоциация, агрегация, композиция). Асоциация е просто някаква връзка между два типа, примерно даден студент използва даден компютър (асоциацията е между студента и компютъра). Агрегация означава че даден клас съдържа много инстанции на даден друг клас, но вторият може да съществува отделно и без първия, примерно една учебна група се състои от много студенти, но студентите могат да съществуват и самостоятелно, без да са в дадена учебна група. Композиция между два класа означава, че един клас се използва като съставна част от друг и не може да съществува без него, примерно един правоъгълник се състои от 4 страни, но страните не могат да съществуват самостоятелно без правоъгълника.

Множественост на връзките

Връзките композиция и агрегация могат да имат множественост, например "1 към 1", "1 към много" и т.н. Пример за множественост на връзка е връзката между студент и учебна дисциплина (например "1 към много" – 1 студент изучава много учебни дисциплини).

Клас диаграми – пример

Следният пример представлява проста диаграма и илюстрира основните елементи, които ни предоставя UML нотацията за изграждане на клас диаграми:

По затворените стрелки разбираме, че класовете Square и Rectangle наследяват Shape и имплементират интерфейса ISurfaceCalculatable, а те от своя страна са наследени съответно от FilledSquare и FilledRectangle.

Виждаме също как с отворени стрелки е изобразена връзката "тип съдържа инстанция на друг тип като свой член", както например класът FilledRectangle съдържа инстанция на структурата Color.

Пространства от имена (namespaces)

Пространствата от имена (namespaces) са средство за организиране на кода в софтуерните проекти. Те съдържат дефиниции на класове, структури, изброени типове и други пространства от имена, като по този начин осигуряват логическо групиране на множества от типове. Пространствата от имена не могат да съдържат дефиниции на функции и данни, тъй като езиците от .NET Framework са строго обектно-ориентирани и такива дефиниции се допускат само в тялото на типовете.

Дефиниране

Пространства от имена в C# се дефинират и използват подобно на пространствата от имена в C++ и на пакетите в Java. Задават се с ключовата дума namespace последвана от името на пространството и множеството от дефиниции на типове, оградено във фигурни скоби, както е показано на примера по-долу:

namespace SofiaUniversity

{

// Type definitions ...

}

Тази дефиниция може да присъства в повече от един файл, като по този начин се създава пространство, което е физически разпределено в различните файлове.

Достъп до типовете

Достъпът до дефинираните в тялото на пространство типове се осъществява по два начина – чрез използване на пълно име на типа и с използването на ключовата дума using.

Пълно име на тип

Пълно име наричаме името на типа предшествано от името на пространството, в което се намира, разделени с точка. Например ако класът AdministrationSystem е дефиниран в пространството SofiaUniversity, тогава пълното му име е AdministrationSystem.SofiaUniversity. По този начин се обръщаме към имена на типове, дефинирани в пространства, различни от текущото.

Използването на пространства от имена позволява дефинирането на типове с едно и също име, стига те да са в различни пространства. Посредством използването на пълни имена се разрешават конфликтите, породени от еднаквите имена на типовете. Например клас с име Config може да е дефиниран както в пространството SofiaUniversity. DataAccess, така и в SofiaUniversity.InternetUtilities. Ако е необходимо в даден клас да бъдат използвани едновременно и двата класа, те се достъпват с пълните си имена: SofiaUniversity.DataAccess.Config и SofiaUniversity.InternetUtilities.Config.

Ключовата дума using

Директивата using <namespace_name>, поставена в началото на файла, позволява директно използване на всички типове от указаното пространство само чрез краткото им име. Пример за това е следният фрагмент от кода, който се генерира автоматично от Visual Studio .NET при създаването на нов файл:

using System;

Това обръщение прави достъпно за програмата основното пространство от имена на .NET Framework – System, което съдържа някои типове, които се използват постоянно – Object, String, Int32 и др.

Подпространства

Както вече споменахме, пространствата от имена могат да съдържат и дефиниции на други пространства. По този начин можем да създаваме йерархии от пространства от имена, в които да разполагаме типовете, които дефинираме.

Подпространства могат да бъдат дефинирани в тялото на пространството родител, но могат да бъдат създадени и в отделен файл. В такъв случай се използва пълно име на пространство от имена. То представлява собственото име на пространството предшествано от родителите му, разделени с точки, както например System.Windows.Forms. Пълното име на тип, дефиниран в подпространство, трябва да съдържа пълното му име, например System.Windows.Forms.Form.

Следва да илюстрираме дефинирането на една простра структура от пространства от имена:

namespace SofiaUniversity.Data

{

public struct Faculty

{

// ...

}

public class Student

{

// ...

}

public class Professor

{

// ...

}

public enum Specialty

{

// ...

}

namespace SofiaUniversity.UI

{

public class StudentAdminForm : System.Windows.Forms.Form

{

// ...

}

public class ProfessorAdminForm : System.Windows.Forms.Form

{

// ...

}

namespace SofiaUniversity

{

public class AdministrationSystem

{

public static void Main()

{

// ...

}

В примера по-горе виждаме дефинициите на основното пространство SofiaUniversity и подпространствата му SofiaUniversity.Data и SofiaUniversity.UI, в които сме дефинирали нашите потребителски типове, например класовете SofiaUniversity.AdministrationSystem и SofiaUniversity.UI.StudentAdminForm, и структурата SofiaUniversity. Data.Faculty.

Използвайки директивата using можем да включваме пространства, зададени с пълното им име. Тази директива включва единствено това пространство, което споменаваме изрично, но не и неговите подпространства. Например, ако укажем using System.Windows няма да имаме директен достъп до класа System.Windows.Forms.Form.

Използвайки ключовата дума using можем да задаваме също и псевдоними на пълните имена на пространствата, както например:

using WinForms = System.Windows.Forms;

namespace SofiaUniversity.UI

{

public class StudentAdminForm : WinForms.Form

{

// ...

}

// ...

}

Как да организираме пространствата?

Основната цел на използването на пространства от имена е създаването на добре организирани и структурирани софтуерни системи. За целта трябва да разделяме типовете, които дефинираме, в пространства, чиято структура отговаря на логическата организация на обектите с които работим. Ако се придържаме към някои прости принципи при изграждането на структури от пространства и типове, можем да създадем значително по-ясни и интуитивни за възприемане проекти без да рискуваме вместо това допълнително да си усложним живота.

Логическа организация

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

Физическа организация

Добре е логическата организация в системите, които разработваме, да отговаря на физическата – публичните типове да създаваме във файлове, носещи тяхното име, а за пространствата – директории с тяхното име, в които да се поместват типовете им. Когато създаваме вложени пространства, е добре да ги създаваме като поддиректории на тези на родителите им пространства. Така само с един поглед на структурата на проекта в Solution Explorer на Visual Studio .NET добиваме представа за нея.

За проекта от примера по-горе е удачно да организираме типовете във файлове по следния начин:

Виждаме, че класът Student от пространството SofiaUniversity.Data е разположен във файла Student.cs от поддиректорията Data на директория SofiaUniversity от нашия проект. По същия принцип класът ProfessorAdminForm се намира във файла SofiaUniversity/UI/ ProfessorAdminForm.cs.

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

Принципи при обектно-ориентирания дизайн

Ще разгледаме няколко много важни принципа за ефективно проектиране на типове, които всеки добър софтуерен разработчик трябва да познава и прилага. Тези принципи не се отнасят само за езика C#, а са важни концепции при проектирането и изграждането на софтуер. Те намират приложение дори не само в софтуерното инженерство, но и във всички инженерни дисциплини като цяло.

Когато създаваме софтуерни системи целим да опростим работата по разработването, поддържането и развиването им. Това постигаме като се придържаме към ясна и разбираема структура на системата, близка до проблемната област, към която е ориентирана тази система. Добре направеният обектно-ориентиран дизайн намалява значително усилията за изучаване на системата при извършването на промени. За да го постигнем, е необходимо да се съобразяваме с няколко основни принципа, които ще разгледаме сега.

Функционална независимост (loose coupling)

Когато създаваме типове, които минимално зависят един от друг, можем да променяме всеки от тях без да е необходимо задълбочено познаване на цялата система. Към този принцип за функционална независимост трябва да се придържаме и когато дефинираме членовете на един тип. Ако минимизираме взаимозависимостите в системите, които разработваме, ще можем много по-лесно да използваме вече създадените модули, типове и методи в други проекти.

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

Трябва да се стремим типовете да издават възможно най-малко тайни за това как са имплементирани вътрешно. Потребителите на даден тип трябва да виждат като публични само свойствата и методите, които ги засягат, а останалите трябва да са скрити. Това намалява сложността на системата, защото намалява общия брой детайли, за които потребителят на даден тип трябва да мисли, когато иска да го използва. Скриването на имплементационните детайли (чрез капсулация) позволява промяната в имплементацията на даден тип без да се променя никой от типовете, който го използва.

Тъй като клас диаграмите показват връзките между типовете, те ни помагат да идентифицираме нивото на независимост между тях. Използвайки клас диаграми можем чисто визуално да преценим дали типовете, които използваме, имат прекалено много зависимости помежду си.

Силна логическа свързаност (strong cohesion)

Действията, които даден метод или клас извършва, трябва да бъдат логически свързани, да са насочени към решаването на една обща задача (не няколко логически несвързани задачи). Това свойство, е известно още като модулност. За да имаме ефективна модуларизация в проекта, който разработваме, трябва всички типове да предоставят ясен интерфейс, който е възможно най-прост и не съдържа излишни методи и свойства. Необходимо е още всички методи в типовете да са свързани логически и да имат имена, които ясно подсказват за какво служат. Не трябва да имаме типове, които имат няколко несвързани логически отговорности и изпълняват разнородни задачи. Това е признак на лош дизайн и води до много проблеми при поддръжката на системата.

Препоръчително е всеки тип, с който работим, както и всеки негов метод, да е свързан с решаването на обща задача и всяко действие, което се извършва да е стъпка или елемент от решаването й. Така системите които изграждаме, ще бъдат много по-разбираеми, и от там лесни за разширяване и поддръжка. Силната свързаност намалява сложността в проектите като спомага за ефективното разделяне на отговорностите в системата.

Упражнения

1. Формулирайте основните принципи на обектно-ориентираното програмиране. Дефинирайте понятията клас, обект, атрибут, метод, енкапсулация на данните, абстракция на данните и действията, наследяване, полиморфизъм.

2. Дефинирайте клас Student, който съдържа като private полета данните за един студент – трите имена, ЕГН, адрес (постоянен и временен), телефон (стационарен и мобилен), e-mail, курс, специалност, ВУЗ, факултет и т.н. Използвайте изброен тип (enumeration) за специалностите, ВУЗ-овете и факултетите. Дефинирайте свойства за достъп до полетата на класа.

3. Дефинирайте няколко конструктора за класа Student, които приемат различни параметри (пълните данни за студента или само част от тях). Неизвестните данни запълвайте с 0 или null.

4. Добавете в класа Student статично поле, което съдържа количеството инстанции, създадени от този клас от стартирането на програмата до момента. За целта променете по подходящ начин конструкторите на класа, така че да следят броя създадени инстанции.

5. Направете класа Student структура. Какви са разликите между клас и структура?

6. Направете нов клас StudentsTest, който има статичен метод за отпечатване на информацията за един или няколко студента. Методът трябва да приема променлив брой параметри.

7. Добавете към класа StudentsTest няколко статични полета от тип Student и статичен конструктор, който създава няколко инстанции на структурата Student с някакви примерни данни и ги записва в съответните статични полета.

8. Създайте интерфейс IAnimal, който моделира животните от реалния свят. Добавете към него метод Talk(), който отпечатва на конзолата специфичен за животното писък, булево свойство Predator, което връща дали животното е хищник и булев метод CouldEat(IAnimal), който връща дали животното се храни с посоченото друго животно. За проверка на типа животно използвайте оператора is.

9. Създайте класове, които имплементират интерфейса IAnimal и моделират животните "куче" и "жаба".

10. Създайте абстрактен клас Cat за животното "котка", който имплементира частично интерфейса IAnimal.

11. Създайте класове Kitten и Tomcat за животните "малко котенце" и "стар котарак", които наследяват абстрактния клас Cat и имплементират неговите абстрактни методи

12. Създайте клас CrazyCat, наследник на класа Tomcat за животното "луда котка", което издава кучешки звуци при извикване на виртуалния метод Talk().

13. Реализирайте клас със статичен метод, който инстанцира по един обект от всеки от класовете, поддържащи интерфейса IAnimal, и им извиква виртуалния метод Talk() през интерфейса IAnimal. Съответстват ли си животинските писъци на животните, които ги издават?

14. Направете всички полета на структурата Student с видимост private. Добавете дефиниции на свойства за четене и писане за всички полета.

15. Направете свойството за достъп до ЕГН полето от структурата Student само за четене. Направете и полето за ЕГН само за четене. Не забравяйте задължително да го инициализирате от всички конструктори на структурата.

16. Напишете клас, който представя комплексни числа и реализира основните операции с тях. Класът трябва да съдържа като private полета реална и имагинерна част за комплексното число и да предефинира операторите за събиране, изваждане, умножение и деление. Реализирайте виртуалния метод ToString() за улеснение при отпечатването на комплексни числа.

17. Реализирайте допълнителни оператори за имплицитно преобразуване на double в комплексно число и експлицитно преобразуване на комплексно число в double.

18. Добавете индексатор в класа за комплексни числа, който по индекс 0 връща реалната част, а по индекс 1 връща имагинерната част на дадено комплексно число.

19. Организирайте всички дефинирани типове в няколко пространства от имена.

20. Направете конструкторите на структурата Student да подава изключения при некоректно зададени данни за студент.

21. Добавете предизвикване на изключения в класа за комплексни числа, където е необходимо.

Използвана литература

1. Светлин Наков, Обектно-ориентирано програмиране в .NET – http://www.nakov.com/dotnet/lectures/Lecture-3-Object-Oriented-Concepts-v1.0.ppt

2. Jeffrey Richter, Applied Microsoft .NET Framework Programming, Microsoft Press, 2002, ISBN 0735614229

3. Tom Archer, Andrew Whitechapel, Inside C#, 2-nd Edition, Microsoft Press, 2002, ISBN 0735616485

4. Erika Ehrli Cabral, OOPs Concepts in .NET Framework – http://www.c-sharpcorner.com/Code/2005/June/OOPSand.NET1.asp

5. MSDN Training, Programming C# (MOC 2124C), Module 5: Methods and Parameters

6. MSDN Training, Programming C# (MOC 2124C), Module 7: Essentials of Object-Oriented Programming

7. MSDN Training, Programming C# (MOC 2124C), Module 9: Creating and Destroying Objects

8. MSDN Training, Programming C# (MOC 2124C), Module 10: Inheritance in C#

9. MSDN Training, Programming C# (MOC 2124C), Module 12: Operators, Delegates, and Events

10. MSDN Training, Programming C# (MOC 2124C), Module 13: Properties and Indexers

11. MSDN Library – http://msdn.microsoft.com/

12. Visual Case Tool – UML Tutorial, The Class Diagram – http://www. visualcase.com/tutorials/class-diagram.htm

13. Steve McConnell, Code Complete, 2nd Edition, Microsoft Press, 2004, ISBN 0735619670


Национална академия по разработка на софтуер
Лекторите » *Светлин Наков* е автор на десетки технически публикации и няколко книги, свързани с разработката на софтуер, заради което е търсен лектор и консултант. Той е разработчик с дългогодишен опит, работил по разнообразни проекти, реализирани с различни технологии (.NET, Java, Oracle, PKI и др.) и преподавател по съвременни софтуерни технологии в СУ "Св. Климент Охридски". През 2004 г. е носител на наградата "Джон Атанасов" на президента на България Георги Първанов. Светлин Наков ръководи обучението по Java технологии в Академията. » *Мартин Кулов* е софтуерен инженер и консултант с дългогодишен опит в изграждането на решения с платформите на Microsoft. Мартин е опитен инструктор и сертифициран от Майкрософт разработчик по програмите MCSD, MCSD.NET, MCPD и MVP и международен лектор в световната организация на .NET потребителските групи INETA. Мартин Кулов ръководи обучението по .NET технологии в Академията.	Академията » Национална академия по разработка на софтуер (НАРС) е център за професионално обучение на софтуерни специалисти. » НАРС провежда БЕЗПЛАТНО курсове по разработка на софтуер и съвременни софтуерни технологии в София и други градове. » Предлагани специалности: § Въведение в програмирането (с езиците C# и Java) § Core .NET Developer § Core Java Developer » Качествено обучение с много практически проекти и индивидуално внимание за всеки. » Гарантирана работа! Трудов договор при постъпване в Академията. » БЕЗПЛАТНО! Учите безплатно във въведителните курсове и по стипендии от работодателите в следващите нива.
http://academy.devbg.org

Глава 4. Управление на изключенията в .NET

Необходими знания

- Базови познания за архитектурата на .NET Framework

- Базови познания за езика C#

Съдържание

- Какво е изключение в .NET?

- Прихващане

- Свойства

- Йерархия и видове

- Предизвикване (хвърляне)

- Дефиниране на собствени

- Препоръчвани практики

В тази тема ...

В настоящата тема ще разгледаме изключенията в .NET Framework като утвърден механизъм за управление на грешки и непредвидени ситуации. Ще обясним как се прихващат и обработват. Ще разгледаме начините за хвърляне на изключение. Ще се запознаем накратко с различните видове изключения в .NET Framework. Ще дадем примери за дефиниране на собствени (потребителски) изключения.

Изключенията в ООП

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

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

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

В ООП се препоръчва чрез изключения да се управлява всяко състояние на грешка или неочаквано поведение, възникнало по време на изпълнението на една програма.

Изключенията в .NET Framework

Изключенията в .NET са класическа имплементация на изключенията от ООП, макар че притежават и допълнителни възможности, произтичащи най-вече от предимствата на управлявания код.

В .NET Framework управлението на грешките се осъществява предимно чрез изключения. Всички операции от стандартната библиотека на .NET (Framework Class Library) сигнализират за грешки посредством хвърляне (throw, raise) на изключение. .NET програмистите трябва да се съобразяват с изключенията, които биха могли да възникнат и да предвидят код за тяхната обработка в някой от извикващите методи.

Изключение може да възникне поради грешка в нашия код или в код който извикваме (примерно библиотечни функции), при изчерпване на ресурс на операционната система, при неочаквано поведение в .NET средата (примерно невъзможност за верификация на даден код) и в много други ситуации.

В повечето случаи едно приложение е възможно да се върне към нормалната си работа след обработка на възникнало изключение, но има и ситуации в които това е невъзможно. Такъв е случаят при възникване на някои runtime изключения. Пример за подобна изключителна ситуация е, когато една програма изчерпа наличната работна памет. Тогава CLR хвърля изключение, което сигнализира за настъпилия проблем, но програмата не може да продължи нормалната си работа и единствено може да запише състоянието на данните, с които работи (за да минимизира загубите), и след това да прекрати изпълнението си.

Всички изключения в .NET Framework са обекти, наследници на класа System.Exception, който ще разгледаме в детайли след малко. Всъщност, съществуват и изключения, които не отговарят на това изискване, но те са нестандартни и възникват рядко. Тези изключения не са съвместими със CLS (Common Language Specification) и не могат да се предизвикат от .NET езиците (C#, VB.NET и т. н.), но могат да възникнат при изпълнение на неуправляван код.

Изключенията носят в себе си информация за настъпилите грешки или необичайни ситуации. Тази информация може да се извлича от тях и е много полезна за идентифицирането на настъпилия проблем. В .NET Framework изключенията пазят в себе си името на класа и метода, в който е възникнал проблемът, а ако асемблито е компилирано с дебъг информация, изключенията пазят и името на файла и номера на реда от сорс кода, където е възникнал проблемът.

Когато възникне изключение, изпълнението на програмата спира. CLR средата запазва състоянието на стека и търси блока от кода, отговорен за прихващане и обработка на възникналото изключение. Ако не го намери в границите на текущия метод, го търси в извикващия го метод. Ако и в него не го намери, го търси в неговия извикващ и т. н. Ако никой от извикващите методи не прихване изключението, то се прихваща от CLR, който показва на потребителя информация за възникналия проблем.

Изключенията улесняват писането и поддръжката на надежден програмен код, като дават възможност за обработката на проблемните ситуации на много нива. В .NET Framework се позволява хвърляне и прихващане на изключения дори извън границите на текущия процес.

Прихващане на изключения

Работата с изключения включва две основни операции – прихващане на изключения и предизвикване (хвърляне) на изключения. Нека разгледаме първо прихващането на изключения в езика C#.

Програмна конструкция try-catch

В C# изключенията се прихващат с програмната конструкция try-catch:

try

{

// Do some work that can raise an exception

}

catch (SomeExceptionClass)

{

// Handle the caught exception

}

Кодът, който може да предизвика изключение, се поставя в try блока, а кодът, отговорен за обработка му – в catch блока.

Catch блокът може да посочи т. нар. филтър за прихващане на изключения или да го пропусне. Филтърът представлява име на клас, поставен в скобки като параметър на catch оператора. В горния пример филтърът задава прихващане на изключения от класа SomeExceptionClass и всички класове, негови наследници. Ако филтърът бъде пропуснат, се прихващат всички изключения, независимо от типа им:

try

{

// Do some work that can raise an exception

}

catch

{

// Any exception is caught here

}

Изразът catch може да присъства няколко пъти съответно за различните типове изключения, които трябва да бъдат прихванати, например:

try

{

// Do some work that can raise an exception

}

catch (SomeExceptionClass)

{

// Handle the SomeExceptionClass and its descendants

}

catch (OtherExceptionClass)

{

// Handle the OtherExceptionClass and its descendants

}

Как CLR търси обработчик за изключенията?

Когато възникне изключение, CLR търси "най-близкия" catch блок, който може да обработи типа на възникналото изключение. Първо се претърсва try-catch блокът от текущия метод, към който принадлежи изпълняваният в момента код (ако има такъв блок). Последователно се обхождат асоциираните с него catch блокове, докато се намери този, чийто филтър съответства на типа на възникналото изключение.

Ако това претърсване пропадне, се извършва същото претърсване за следващия try-catch блок, ограждащ текущия (ако има такъв). Този блок може да се намира в текущия метод, в извикващия го метод или в някой от методите, които са извикали него. Ако търсенето отново пропадне, се търси следващия try-catch блок и се проверяват неговите филтри дали улавят възникналото изключение. Търсенето продължава докато се намери първият подходящ обработчик на възникналото изключение или се установи, че няма изобщо такъв.

Търсенето може да обходи целия стек на извикване на методите и да не успее да намери catch блок, който да обработи изключението. В такъв случай изключението се обработва от CLR (появява се съобщение за грешка).

Прихващане на изключения – пример

Нека разгледаме един прост пример:

static void Main()

{

string s = Console.ReadLine();

try

{

Int32.Parse(s);

Console.WriteLine("You entered valid Int32 number {0}", s);

}

catch (FormatException)

{

Console.WriteLine("Invalid integer number!");

}

catch (OverflowException)

{

Console.WriteLine("Number too big to fit in Int32!");

}

В този пример програма очаква да се въведе цяло число. Ако потребителят въведе нещо различно, ще възникне изключение.

Извикването на метода Int32.Parse(s) може да предизвика различни изключения и затова е поставено в try блок, към който са асоциирани няколко catch блока.

Ако вместо число се подаде някаква произволна комбинация от символи, при извикването на метода Int32.Parse(s) ще възникне изключението System.FormatException, което ще бъде прихванато и обработено от първия catch блок.

Ако потребителят въведе число, по-голямо от максималната стойност за типа System.Int32, при извикването на Int32.Parse(s) ще възникне System.OverflowException, чиято обработка се извършва от втория catch блок.

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

catch (OverflowException ex)

{

// Handle the caught exception

}

Тук посредством от променливата еx, която е инстанция на класа System.OverflowException, можем да извлечем допълнителна информация за възникналото изключение.

Прихващане на изключения на нива – пример

Нека сега разгледаме един по-сложен пример за прихващане на изключения – прихващане на изключения на няколко нива:

static void Main()

{

try

{

int result = Calc(100000, 100000, 1);

Console.WriteLine(result);

}

catch (ArithmeticException)

{

Console.WriteLine("Calculation failed!");

}

static int Calc(int a, int b, int c)

{

int result;

try

{

checked

{

result = a*b/c;

}

catch (DivideByZeroException)

{

result = -1;

}

return result;

}

В този пример изключенията се прихващат на 2 нива – в try-catch блок в метода Calc(…) и в try-catch блок в метода Main(), извикващ Calc(…).

Ако методът Calc(…) бъде извикан с параметри (0, 0, 0), ще се получи деление на 0 и изключението DivideByZeroException ще бъде прихванато и обработено в try-catch блока на Calc(…) метода и съответно ще се получи стойност -1.

Ако, обаче, методът Calc(…) бъде извикан с параметри (100000, 100000, 1), ще се получи препълване на типа int, което в checked блок ще предизвика ArithmeticOverflowException. Това изключение няма да бъде хванато от catch филтъра в Calc(…) метода и CLR ще провери следващия catch филтър. Това е try-catch блокът в метода Main(), от който е извикан методът Calc(…). CLR ще открие в него е подходящ обработчик за изключението (catch филтърът за класа ArithmeticException, на който класът ArithmeticOverflowException е наследник) и ще го изпълни. Резултатът ще е отпечатване на съобщението "Calculcation failed!".

Възможно е по някаква причина в Calc(…) метода да възникне изключение, което не е наследник на ArithmeticException (например OutOfMemoryException). В такъв случай то няма да бъде прихванато от никой от catch филтрите и ще се обработи от CLR.

Свойства на изключенията

Изключенията в .NET Framework са обекти. Класът System.Exception е базов клас за всички изключения в CLR. Той дефинира свойства, общи за всички .NET изключения, които съдържат информация за настъпилата грешка или необичайна ситуация.

Ето и някои често използвани свойства:

- Message – текстово описание на грешката.

- StackTrace – текстова визуализация на състоянието на стека в момента на възникване на изключението. Дава информация за това в кой метод в кой файл и на кой ред във файла е възникнало изключението. Имената на файловете и редовете са налични само при компилиране в дебъг режим.

- InnerException – изключение, което е причина за възникване на текущото изключение (ако има такова). Например имаме метод който чете от файл и после форматира прочетените данни. Ако по време на четенето възникне изключение то може да бъде прихванато и да се хвърли ново изключение от друг, собствено дефиниран тип, като прихванатото изключение се присвои на свойството InnerException. Целта е обработчикът на изключението да получи информация както за възникналия проблем, така и за неговия първопричинител. Чрез свойството InnerException изключенията могат да се свързват във верига, която съдържа последователно всички изключения, които са причинили изключението в нейното начало.

Ще илюстрираме употребата на свойствата с един пример:

using System;

class ExceptionsTest

{

public static void CauseFormatException()

{

string s = "an invalid number";

Int32.Parse(s);

}

static void Main(string[] args)

{

try

{

CauseFormatException();

}

catch (FormatException fe)

{

Console.Error.WriteLine(

"Exception caught: {0}\n{1}",

fe.Message, fe.StackTrace);

}

Свойството StackTrace е изключително полезно при идентифициране на причината за изключението. Резултатът от примера е информация за прихванатото в Main() метода изключение, отпечатана върху стандартния изход за грешки:

Exception caught: Input string was not in a correct format.

at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)

at System.Int32.Parse(String s)

at ExceptionsTest.CauseFormatException() in c:\consoleapplication1\exceptionstest.cs:line 8

at ExceptionsTest.Main(String[] args) in c:\consoleapplication1\exceptionstest.cs:line 15

Имената на файловете и номерата на редовете са достъпни само ако сме компилирали с дебъг информация. Ако компилираме по-горния пример в Release режим, ще получим много по-бедна информация от свойството StackTrace:

Exception caught: Input string was not in a correct format.

at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)

at ExceptionsTest.Main(String[] args)

Превключването между Debug и Release на компилация става много лесно от лентата с инструменти за компилация във VS.NET:

Йерархия на изключенията

Изключенията са класове и като такива могат да се наследяват и да образуват йерархии. Както вече знаем, всички изключения в .NET Framework наследяват класа System.Exception. Този клас има няколко важни наследника, от които обектната йерархия продължава в няколко посоки. Това се вижда от следната диаграма:

Някои изключения директно наследяват System.Exception, например класовете System.SystemException и System.ApplicationException.

Системните изключения, които се използват от стандартните библиотеки на .NET и вътрешно от CLR, наследяват класа System.SystemException. Ето някои от тях:

- System.ArithmeticException – грешка при изпълнението на аритметична операция, например деление на 0, препълване на целочислен тип и др.

- System.ArgumentException – невалиден аргумент при извикване на метод.

- System.NullReferenceException – опит за достъп до обект, който има стойност null.

- System.OutOfMemoryException – паметта е свършила.

- System.StackOverflowException – препълване на стека. Обикновено възниква при настъпване на безкрайна рекурсия.

- System.IndexOutOfRangeException – опит за излизане от границите на масив.

Изключенията дефинирани от потребителя трябва да наследяват класа System.ApplicationException. Така потребителските програми ще предизвикват изключения само от този тип или негови наследници. Това дава възможност да се разбере дали проблемът е на ниво потребителски код или е свързан със системна грешка. Възможно е потребителски-дефинирано изключение да наследи и директно System.Exception, а не System. ApplicationException, но има много спорове дали това е добра практика. Някои експерти твърдят, че наследяването на ApplicationException усложнява излишно йерархията, докато други смятат, че е по-важно да се разграничават системните от потребителските изключения.

Подредбата на catch блоковете

Както вече знаем, при прихващане на изключения от даден клас се прихващат и изключенията от всички негови наследници. Затова е важна подредбата на catch блоковете. Например конструкцията:

try

{

// Do some works that can raise an exception

}

catch (System.ArithmeticException)

{

// Handle the caught arithmetic exception

}

прихваща освен ArithmeticException и изключенията OverflowException и DivideByZeroException. В този пример всичко е наред, но нека разгледаме следния код:

static void Main()

{

string s = Console.ReadLine();

try

{

Int32.Parse(s);

}

catch (Exception) // Трябва да е най-накрая

{

Console.WriteLine("Can not parse the number!");

}

catch (FormatException) // Този код е недостижим

{

Console.WriteLine("Invalid integer number!");

}

catch (OverflowException) // Този код е недостижим

{

Console.WriteLine("The number is too big!");

}

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

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

Изключения и неуправляван код

Управлявания .NET код може да предизвика само изключения, наследници на System.Exception. Неуправляваният код може да предизвика и други изключения. За прихващане на всички изключения в C# се използва следната конструкция:

try

{

// Do some work that can raise an exception

}

catch

{

// Handle the caught exception

}

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

Предизвикване (хвърляне) на изключения

Досега разгледахме как се прихващат изключения, които са предизвикани от някой друг. Нека сега разгледаме как ние можем да предизвикваме изключения, които някой друг да прихваща.

Предизвикването (хвърляне) на изключения (throwing, raising exceptions) има за цел да уведоми извикващия код за възникването на даден проблем. Тази техника се използва при настъпване на грешка или необичайна ситуация в даден програмен фрагмент. Под "необичайна ситуация" се има предвид ситуация, която разработчикът е предвидил като евентуално възможна, но която не се случва при нормалната работа, примерно опит за намиране на корен квадратен от отрицателно число.

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

За да се хвърли изключение, с което да се уведоми извикващият код за даден проблем в C# се използва оператора throw, на който се подава инстанция на класа на изключението. Най-често се изисква създаване на обект от някой наследник на класа System.Exception, в който се поставя описание на възникналия проблем. Ето един пример, в който се хвърля изключение ArgumentException:

throw new ArgumentException("Invalid argument!");

Обикновено преди да бъде хвърлено изключение, то се създава чрез извикване на конструктора на класа, на който то принадлежи. Почти всички изключения дефинират следните два конструктора:

Exception(string message);

Exception(string message, Exception InnerException);

Първият конструктор приема текстово съобщение, което описва възникналият проблем, а вторият приема и изключение, причинител на възникналия проблем.

При хвърляне на изключение CLR прекратява изпълнението на програмата и обхожда стека до достигане на catch блок за съответното изключение (целият процес беше описан подробно преди малко).

Хвърляне и прихващане на изключения – пример

Ето един пример за хвърляне и прихващане на изключение:

public static double Sqrt(double aValue)

{

if (aValue < 0)

{

throw new System.ArgumentOutOfRangeException(

"Sqrt for negative numbers is undefined!");

}

return Math.Sqrt(aValue);

}

static void Main()

{

try

{

Sqrt(-1);

}

catch (ArgumentOutOfRangeException ex)

{

Console.Error.WriteLine("Error: " + ex.Message);

}

В него е дефиниран метод, който извлича корен квадратен от реално число с двойна точност. При подаване на отрицателен аргумент методът хвърля ArgumentException. В Main() метода изключението се прихваща и се отпечатва грешка.

Хвърляне на прихванато изключение – пример

В catch блокове прихванатите изключения могат да се хвърлят отново. Пример за такова поведение е следният програмен фрагмент:

public static int Calculate(int a, int b)

{

try

{

return a/b;

}

catch (DivideByZeroException)

{

Console.WriteLine("Calculation failed!");

throw;

}

static void Main()

{

try

{

Calculate(1, 0);

}

catch (Exception ex)

{

Console.WriteLine(ex);

}

В метода Calculate(…) прихванатото аритметично изключение се обработва като се отпечатва на конзолата "Calculation failed!" и след това се хвърля отново (чрез израза throw;). В резултат същото изключение се прихваща и от try-catch блока в Main() метода.

Собствени изключения

В .NET Framework програмистите могат да дефинират собствени класове за изключения и да създават класови йерархии с тях. Това осигурява много голяма гъвкавост при управлението на грешки и необичайни ситуации. В по-големите приложения изключенията се разделят в логически в категории и за всяка категория се дефинира по един базов клас, а за конкретните представители на категориите се дефинира по един клас-наследник. Ето един пример:

В примера се създава по един абстрактен базов клас за категорията изключения, свързани с клиентите (CustomerException) и за категорията изключения, свързани с поръчките (OrderException). Наследниците на OrderException и CustomerException също могат да се подреждат в класова йерархия и да дефинират собствени подкатегории.

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

Добре е да се спазва правилото, че йерархиите трябва да са широки и плитки, т.е. класовете на изключения трябва да са производни на тип, който се намира близо до System.Exception, и трябва да бъдат не повече от две или три нива надълбоко. Ако дефинираме тип за изключение, който няма да бъде базов за други типове, маркираме го като sealed, а ако не искаме да бъде инстанциран директно, го правим абстрактен.

Дефиниране на собствени изключения

За дефинирането на собствени изключения се наследява класът System. ApplicationException и му се създават подходящи конструктори и евентуално му се добавят и допълнителни свойства, даващи специфична информация за проблема. Препоръчва се винаги да се дефинират поне следните два конструктора:

MyException(string message);

MyException(string message, Exception InnerException);

Въпреки, че не е задължително, силно се препоръчва имената на изключенията да завършват на "Exception", например OrderException, CustomerNotFoundException, InvalidCredentialsException и т. н.

Веднъж дефинирани, собствените класове за изключения могат да се ползват по същия начин, както и системните изключения.

Собствени изключения – пример

Ще даден един пример за собствено изключение, което се използва при парсването на текстов файл. То съдържа в себе си специфична информация за проблем, възникнал при парсването – име на файла, номер на ред, съобщение за грешка и изключение-причинител на проблема:

class ParseFileException : ApplicationException

{

private string mFileName;

private long mLineNumber;

public string FileName

{

get

{

return mFileName;

}

public long LineNumber

{

get

{

return mLineNumber;

}

public ParseFileException(string aMessage, string aFileName,

long aLineNumber, Exception aCauseException) : base(

aMessage, aCauseException)

{

mFileName = aFileName;

mLineNumber = aLineNumber;

}

public ParseFileException(string aMessage, string aFileName,

Exception aCauseException) : this(

aMessage, aFileName, 0, aCauseException)

{

}

public ParseFileException(string aMessage, string aFileName) :

this(aMessage, aFileName, null)

{

}

В класа ParseFileException няма нищо сложно. Той наследява System. Exception и дефинира две полета (име на файл и номер на ред), две свойства за достъп до тях и няколко конструктора за инициализация на класа по различен набор от параметри.

Понеже всички инстанции на ParseFileException се създават чрез извикване (директно или индиректно) на базовия конструктор на класа ApplicationException, то при подаване на изключение-причинител, то ще бъде записано в свойството InnerException, което се наследява от класа System.Exception. По същия начин подаденото текстово описание на проблема ще се запише в наследеното свойство Message.

Ето как изключението ParseFileException може да бъде използвано в програма, която по даден текстов файл, съдържащ цели числа (по 1 на ред), намира тяхната сума:

static long CalculateSumOfLines(string aFileName)

{

StreamReader inF;

try

{

inF = File.OpenText(aFileName);

}

catch (IOException ioe)

{

throw new ParseFileException(String.Format(

"Can not open the file {0} for reading.",

aFileName), aFileName, ioe);

}

try

{

long sum = 0;

long lineNumber = 0;

while (true)

{

lineNumber++;

string line;

try

{

line = inF.ReadLine();

}

catch (IOException ioe)

{

throw new ParseFileException(

"Error reading from file.",

aFileName, lineNumber, ioe);

}

if (line == null)

break; // end of file reached

try

{

sum += Int32.Parse(line);

}

catch (SystemException se)

{

throw new ParseFileException(String.Format(

"Error parsing line '{0}'.", line),

aFileName, lineNumber, se);

}

return sum;

}

finally

{

inF.Close();

}

static void Main()

{

try

{

long sumOfLines = CalculateSumOfLines(@"c:\test.txt");

Console.WriteLine("The sum of lines={0}", sumOfLines);

}

catch (ParseFileException pfe)

{

Console.WriteLine("File name: {0}", pfe.FileName);

Console.WriteLine("Line number: {0}", pfe.LineNumber);

Console.WriteLine("Exception: {0}", pfe);

}

В кода са използвани класове за работа с текстови файлове и потоци от пространството с имена System.IO, които ще разгледаме подробно в темата "Вход и изход". Засега нека се съсредоточим върху използването на изключения, а не върху работата с файлове.

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

Ако стартираме приложението в момент, в който файлът c:\test.txt липсва, ще получим следния резултат:

File name: c:\test.txt

Line number: 0

Exception: ParseFileException: Can not open the file c:\test.txt for reading. ---> System.IO.FileNotFoundException: Could not find file "c:\test.txt". File name: "c:\test.txt"

at System.IO.__Error.WinIOError(Int32 errorCode, String str)

at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean useAsync, String msgPath, Boolean bFromProxy)

at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)

at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize)

at System.IO.StreamReader..ctor(String path)

at System.IO.File.OpenText(String path)

at Test.CalculateSumOfLines(String aFileName) in c:\demos\ParseFileExceptionDemo.cs:line 52

--- End of inner exception stack trace ---

at Test.CalculateSumOfLines(String aFileName) in c:\demos\ParseFileExceptionDemo.cs:line 56

at Test.Main() in c:\demos\ParseFileExceptionDemo.cs:line 106

Както се вижда, възникнало е изключение ParseFileException, а причината за него е изключението System.IO.FileNotFoundException.

Съхраняването на началната причина за възникване на изключението при подаване на изключение от по-високо ниво на абстракция (както в горния пример) е добра практика, защото дава на разработчика по-богата информация за възникналия проблем.

В примера изключението ParseFileException е от по-високо ниво на абстракция, отколкото FileNotFoundException и дава по-богата информация на разработчика.

Конструкцията try–finally

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

StreamReader reader = File.OpenText("example.txt");

string fileContents = reader.ReadToEnd();

reader.Close();

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

Къде е проблемът?

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

Решението

Проблемът може да бъде решен чрез програмната конструкция try-finally в C#:

try

{

// Do some work that can raise an exception

}

finally

{

// This block will always execute

}

Тя осигурява гарантирано изпълнение на зададен програмен блок независимо дали в блока преди него възникне изключение или не. Конструкцията има следното поведение:

- Ако в try блока не възникне изключение, след завършването на изпълнението му, се изпълнява веднага след него и finally блокът.

- Ако в try блока възникне изключение, изпълнението на try блока ще се прекъсне и CLR ще започне да търси обработчик за възникналото изключение. В този случай има две възможности:

o CLR намира обработчик за изключението. Тогава първо ще се изпълни finally блокът и едва след това намереният от CLR обработчик.

o CLR не намира подходящ обработчик. Тогава първо CLR ще обработи изключението (ще даде някакво съобщение за грешка) и след това ще изпълни finally блока.

Може да изглежда сложно, но всъщност не е. Важното нещо, което трябва да запомним е, че finally блокът се изпълнява винаги, независимо от това какво се е случило в try блока. Останалите детайли не са чак толкова важни.

Конструкцията try-catch-finally

Конструкцията try-finally може да се комбинира с конструкцията try-catch. Така се получава try-catch-finally конструкцията, която работи по следния начин:

- Ако в try блока не възникне изключение, се изпълняват последователно try и finally блоковете.

- Ако в try блока възникне изключение, което може да се улови от catch филтрите на try-catch-finally конструкцията, първо се изпълнява съответният catch блок, а след него се изпълнява и finally блокът.

- Ако в try блока възникне изключение, което не отговаря на catch филтрите от try-catch-finally конструкцията, CLR търси подходящ catch филтър в стека за изпълнение на програмата за да обработи изключението. Отново има две възможности:

За повече яснота да разгледаме един пример:

try

{

int a = 0;

int b = 1/a;

}

catch (ArithmeticException)

{

Console.WriteLine("ArithmeticException caught.");

}

finally

{

Console.WriteLine("Finally block executed.");

}

В примера в try блока възниква аритметично изключение заради делението на 0, то се обработва веднага от catch блока и накрая се изпълнява finally блокът. При изпълнението на примера се получава следният резултат:

Нека сега разгледаме пример, в който възниква изключение, което не се прихваща никъде в програмата:

try

{

int a = 0;

int b = 1/a;

}

finally

{

Console.WriteLine("Finally block executed.");

}

В случая CLR вътрешно ще прихване изключението, ще отпечата съобщение за грешка и едва след това ще изпълни finally блока:

Да разгледаме и още един пример:

try

{

try

{

int a = 0;

int b = 1/a;

}

finally

{

Console.WriteLine("Finally block executed.");

}

catch (ArithmeticException)

{

Console.WriteLine("ArithmeticException caught.");

}

При неговото изпълнение ще настъпи аритметично изключение в try блока от try-finally конструкцията. CLR ще потърси и ще намери подходящ обработчик за него в try-catch конструкцията. Понеже CLR е намерил обработчик, първо ще бъде изпълнен finally блока, а след това обработчикът на изключението. Резултатът ще бъде следния:

try-finally за освобождаване на ресурси

В блока, който се изпълнява задължително (finally блока), може да се съдържа код за освобождаване на ресурси, който трябва да се изпълни винаги. Така се осигурява почистване след всяка успешно започната операция, преди да се върне управлението на извикващия блок или да продължи да се изпълнява кодът след finally блока. Ето един пример:

/// <summary>

/// Returns the # of first line from the given text file

/// that contains given pattern or -1 if such line is not found

/// </summary>

static int FindInTextFile(string aPattern, string aFileName)

{

int lineNumber = 0;

StreamReader inF = File.OpenText(aFileName);

try

{

while (true)

{

string line = inF.ReadLine();

if (line == null)

break; // end of file reached

lineNumber++;

if (line.IndexOf(aPattern) != -1)

return lineNumber;

}

return -1;

}

finally

{

inF.Close(); // The file will never remain opened

}

В примера е реализиран метод, който търси даден текст в даден текстов файл и връща номера на реда, в който е намерен текстът. Понеже е използвана конструкцията try-finally след отварянето на файла, каквото и да се случи по време на търсенето, файлът накрая ще бъде затворен.

Ако не възникне изключение по време на търсенето, след изпълнението на return оператора, ще бъде изпълнен finally блокът.

Ако при работата с файла възникне изключение, ще се изпълни първо finally блокът и методът няма да върне стойност, а ще завърши с изключение, което ще бъде обработено след това.

Ако при търсенето възникне изключение, но то не бъде прихванато, то ще се обработи от CLR и finally блокът ще бъде изпълнен едва след това. Методът няма да върне стойност и програмата ще приключи аварийно.

Препоръчвани практики

Изключенията са много мощен механизъм за обработка на грешки, но ако се използват неправилно, могат да доведат до много трудни за откриване проблеми. Затова ще посочим някои препоръчвани практики при работата с изключения:

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

- Всеки catch блок трябва да прихваща само изключенията, които очаква (и знае как да обработва), а не всички. Лоша практика е да се прихващат всички изключения тъй като различните видове изключения изискват различна обработка и специфични действия за справяне с възникналата проблемна ситуация. Избягвайте конструкциите catch (Exception) {…} или просто catch {…}.

- При дефиниране на собствени изключения трябва да се наследява System.ApplicationException, а не директно System.Exception. По този начин може да се направи разграничение на това дали изключението е от .NET Framework или е от приложението.

- Имената на класовете на всички изключения трябва завършват на Exception, например OrderException, InvalidAccountException и т. н. Това прави кода по-разбираем и по-лесен за поддръжка.

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

- Изключенията могат да намалят значително производителността на приложението, понеже всяко хвърлено изключение инстанцира клас (това отнема време), инициализира членовете му (това също отнема време), извършва търсене в стека за подходящ catch блок (и това отнема време) и накрая след като инстанцията стане неизползваема, тя се унищожава от garbage collector (и това също отнема време). Затова, когато е възможно се препоръчва да се прави проверка дали е възможно дадено действие, а не да се разчита на обработката на възникналото изключение. Прекомерното използване на изключенията се отразява на производителността.

- Някои изключения могат да възникват по всяко време без да ги очакваме (например System.OutOfMemoryException). Добра практика е да се централизира прихващането на този тип изключения на най-високо ниво например в Main() метода на програма и да се направи елегантно прекратяване на изпълнението на програмата.

- Изключенията трябва да бъдат хвърляни само при ситуации, които наистина са изключителни и трябва да се обработят. В нормалния ход на програмата (когато не възникват проблеми) не трябва да се хвърлят изключения.

Упражнения

1. Обяснете какво представлява изключенията, кои са силните им страни и кога се препоръчва да се използват.

2. Реализирайте структура от данни Student, която съдържа информация за студент - име, адрес, курс, специалност, изучавани предмети, оценки и т. н. Добавете подходящи конструктори и свойства за достъп до данните от класа. Сложете проверка за валидност на данните за студента в конструкторите и в свойствата за достъп. При невалидни данни хвърляйте изключение. Дефинирайте подходящи собствени класове за изключенията, свързани с класа Student.

Използвана литература

1. Светлин Наков, Обектно-ориентирано програмиране в .NET – http://www.nakov.com/dotnet/lectures/Lecture-3-Object-Oriented-Concepts-v1.0.ppt

2. Jeffrey Richter, Applied Microsoft .NET Framework Programming, Microsoft Press, 2002, ISBN 0735614229

3. Suprotim Agarwal, Getting Started with Exception Handling in C# - http://www.c-sharpcorner.com/Code/2004/July/ GettingStartedWithExceptionHandling.asp

4. Steve McConnell, Code Complete, 2nd Edition, Microsoft Press, 2004, ISBN 0735619670

5. MSDN Library – http://msdn.microsoft.com

Глава 5. Обща система от типове
(Common Type System)

Необходими знания

- Базови познания за архитектурата на .NET Framework

- Базови познания за езика C#

Съдържание

- Какво е CTS?

- Йерархията на типовете в .NET

- Стойностни и референтни типове

- Типът System.Object

- Предефиниране на стандартните методи на System.Object

- Операторите is и as

- Клониране на обекти

- Опаковане и разопаковане на обекти

- Интерфейсите IComparable, IEnumerable и IEnumerator

В тази тема ...

В настоящата тема ще разгледаме общата система от типове в .NET Framework. Ще обясним разликата между стойностни и референтни типове, ще разгледаме основополагащия тип System.Object и йерархията на типовете, произлизаща от него. Ще се запознаем накратко и с някои операции при работа с типове – преобразуване към друг тип, проверка на тип, клониране, опаковане, разопаковане и др.

Какво е CTS?

CLR поддържа много езици за програмиране. За да се осигури съвместимост на данните между различните езици е разработена общата система от типове (Common Type System – CTS). CTS дефинира поддържаните от CLR типове данни и операциите над тях.

CTS и езиците за програмиране в .NET

Всички .NET езици използват типовете от CTS. За всеки тип в даден .NET език има някакво съответствие в CTS, макар че понякога това съответствие не е директно. Обратното не е вярно – съществуват CTS типове, които не се поддържат от някои .NET езици.

CTS e обектно-ориентирана

По идея всички езици в .NET Framework са обектно-ориентирани. Common Type System също се придържа към идеите на обектно-ориентираното програмиране (ООП) и по тази причина описва освен стандартните типове (числа, символи, низове, структури, масиви) и някои типове данни свързани с ООП (например класове и интерфейси).

CTS описва .NET типовете

Типовете данни в CTS биват най-разнообразни:

- примитивни типове (primitive types – int, float, bool, char, …)

- изброени типове (enums)

- класове (classes)

- структури (structs)

- интерфейси (interfaces)

- делегати (delegates)

- масиви (arrays)

- указатели (pointers)

Всички тези типове повече или по-малко вече са ни познати от езика C#, но всъщност те са част от CTS. Езикът C# и другите .NET езици използват CTS типовете и им съпоставят запазени думи съгласно своя синтаксис. Например типът System.Int32 от CTS съответства на типа int в C#, а типът System.String – на типа string.

Стойностни и референтни типове

В CTS се поддържат две основни категории типове: стойностни типове (value types) и референтни типове (reference types). Стойностните типове съдържат директно стойността си в стека за изпълнение на програмата, докато референтните типове съдържат строго типизиран указател (референция) към стойността, която се намира в динамичната памет. По-нататък ще разгледаме подробно разликите между стойностните и референтните типове и особеностите при тяхното използване.

Къде са ми указателите?

По принцип в .NET има класически указатели, но те не се използват масово, както при езиците C и C++. Указателите в .NET се поддържат най-вече заради съвместимост с Win32 платформата и се използват в много специални случаи. В силно типизираните езици като C# и VB.NET за достъп до обекти в динамичната памет се използват т. нар. референции (references), които са строго типизирани указатели, подобни на псевдонимите в C++.

С въвеждането на референтните типове в .NET отпада нуждата от класически указатели. На практика реферетните типове са типово-обезопасени указатели, защитени от неправилно преобразуване към друг тип, а сочената от тях динамична памет се управлява автоматично.

Йерархията на типовете

CTS дефинира строга йерархия на типовете данни, които се поддържат в .NET Framework:

В основата на йерархията стои системният тип System.Object. Той е общ предшественик (базов тип) за всички останали типове в CTS. Неговите преки наследници са стойностните и референтните типове (които ще дискутираме в детайли по-късно в тази тема).

Стойностните типове биват примитивни (int, float, bool и др.), структури (struct в C#) и изброени типове (enum в C#).

Референтните типове са всички останали – указателите, класовете, интерфейсите, делегатите, масивите и опакованите стойностни типове.

В предходните теми вече се запознахме с някои от CTS типовете. В тази и в следващите теми ще се запознаем и с останалите (опаковани стойностни типове, масиви, делегати).

Типът System.Object

В CTS всички типове наследяват системния тип System.Object. Не правят изключение дори примитивните типове (int, float, char, ...) и масивите. Всеки тип е наследник на System.Object и имплементира методите, включени в него. Като резултат значително се улеснява работата с типове, защото променлива от произволен тип може да се присвои на променлива от базовия тип System.Object (object в C#). Самият System.Object е референтен тип.

Стойностни типове (value types)

Стойностни типове (типове по стойност) са повечето примитивни типове (int, float, bool, char и др.), структурите (struct в C#) и изброените типове (enum в C#).

Стойностните типове директно съдържат стойността си и се съхраняват физически в работния стек за изпълнение на програмата. Tе не могат да приемат стойност null, защото реално не са указатели.

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

Стойностните типове заемат необходимата им памет в стека в момента на декларирането им и я освобождават в момента на излизане от обхват (при достигане на края на програмния блок, в който са декларирани). Заделянето и освобождаване на памет за стойностен тип реално се извършва чрез единично преместване на указателя на стека и следователно става много бързо.

Горното обяснение е малко опростено. Всъщност ако стойностен тип има за член-данни само стойностни типове, при инстанциране целият тип ще се задели в стека. Ако, обаче, стойностен тип (например структура) съдържа като член-данни референтни типове, стойностите им ще се запишат в динамичната памет.

Стойностните типове наследяват System.ValueType

CLR се грижи всички стойностни типове да наследяват системния тип System.ValueType. Всички типове, които не наследяват ValueType са референтни типове, т.е. реално са указатели към динамичната памет (адреси в паметта).

Предаване на стойностни типове

При извикване на метод стойностните типове се подават по стойност, т.е. предава се копие от тях. При подготовка на извикването на метод CLR копира подаваните като параметри стойностни типове от оригиналното им местоположение в стека на ново място в стека и подава на извиквания метод направените копия. Ако извикваният метод промени стойността на подадения му по стойност параметър, при връщане от извикването промяната се губи. Това поведение важи, разбира се, само ако параметрите се подават по подразбиране, без да се използват ключовите думи в C# ref и out, които ще разгледаме по-нататък в следващите теми.

Референтни типове (reference types)

Референтни типове (типове по референция) са указателите, класовете, интерфейсите, делегатите, масивите и опакованите стойностни типове. Физически референтните типове представляват указател към стойност в динамичната памет, но за CLR те не са обикновени указатели, а специални типово-обезопасени указатели. Това означава, че CLR не допуска на един референтен тип да се присвои стойност от друг референтен тип, който не е съвместим с него (т.е. не е същия тип или негов наследник). В резултат на това в .NET езиците грешките от неправилна работа с типове са силно намалени.

Референтните типове и паметта

Всички референтни типове се съхраняват в динамичната памет (т. нар. managed heap), която се контролира от системата за почистване на паметта (garbage collector). Динамичната памет е специално място от паметта, заделено от CLR за съхранение на данни, които се създават динамично по време на изпълнението на програмата. Такива данни са инстанциите на всички референтни типове.

Когато инстанция на референтен тип престане да бъде необходима на програмата, тя се унищожава от системата за почистване на паметта (т. нар. garbage collector).

Когато инстанцираме референтен тип с оператора new, CLR заделя място в динамичната памет, където ще стоят данните и един указател в стека, който съдържа адреса на заделеното място. Веднага след това заделената памет се занулява (освен ако програмистът не инициализира заделената променлива, например чрез извикване на подходящ конструктор).

Ако референтен тип (например клас) съдържа член-данни от стойностен тип, те се съхраняват в динамичната памет. Ако референтен тип съдържа член-данни от референтен тип, в динамичната памет се заделят указатели (референции) за тях, а техните стойности (ако не са null) също се заделят също в динамичната памет, но като отделни обекти.

Референтните типове и производителността

Понякога се приема, че заделянето на динамична памет е бърза операция, защото в текущата реализация (.NET Framework 1.1) физически се имплементира чрез преместване на един указател. Освобождаването на памет, обаче, е сложна и времеотнемаща операция, която се извършва от време на време от системата за почистване на паметта (garbage collector).

Ако изчислим средното време, необходимо за заделяне и освобождаване на динамична памет, се оказва, че заделянето и освобождаване на стойностните типове е значително по-бързо от референтните типове. Когато производителността е важна за нашата система, трябва да се съобразяваме с особеностите на стойностните и референтните типове и начина, по който те заделят и освобождават памет.

Глобално погледнато, нещата около управлението на динамичната памет в .NET Framework са доста комплексни, но в тази тема няма да се спираме на тях. По-нататък, в темата за управление на паметта и ресурсите, ще им обърнем специално внимание.

Стойностни срещу референтни типове

Стойностните и референтните типове в .NET Framework се различават съществено. Стойностните типове се разполагат в стека за изпълнение на програмата, докато референтните типове са строго типизирани указатели към динамичната памет, където се съдържа самата им стойност.

Следват някои по-съществени разлики между тях:

- Стойностните типове наследяват системния тип System.ValueType, а референтните наследяват директно System.Object.

- При създаване на променлива от стойностен тип тя се заделя в стека, а при референтните типове – в динамичната памет.

- При присвояване на стойностни типове се копира самата им стойност, а при референтни типове – само референцията (указателя).

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

- Стойностните типове не могат да приемат стойност null, защото не са указатели, докато референтните могат.

- Стойностните типове се унищожават при излизане от обхват, докато референтните се унищожават от системата за почистване на паметта (garbage collector) в някой момент, в който се установи, че вече не са необходими за работата на програмата.

- Променливи от стойностен тип могат да се съхраняват в променливи от референтен тип чрез т.нар. "опаковане" (boxing), което ще разгледаме след малко.

Стойностни и референтни типове – пример

В настоящия пример се демонстрира използването на стойностни и референтни типове и се илюстрира разликата между тях:

using System;

// SomeClass is reference type

class SomeClass

{

public int mValue;

}

// SomeStruct is value type

struct SomeStruct

{

public int mValue;

}

class TestValueAndReferenceTypes

{

static void Main()

{

SomeClass class1 = new SomeClass();

class1.mValue = 100;

SomeClass class2 = class1; // Копира се референцията

class2.mValue = 200; // Променя се и class1.mValue

Console.WriteLine(class1.mValue); // Отпечатва се 200

SomeStruct struct1 = new SomeStruct();

struct1.mValue = 100;

SomeStruct struct2 = struct1; // Копира се стойността

struct2.mValue = 200; // Променя се копираната стойност

Console.WriteLine(struct1.mValue); // Отпечатва се 100

}

След като се изпълни примерът, се получава следния резултат:

Как работи примерът?

В началото на примера се създава инстанция на класа SomeClass, в нея се записва числото 100 и след това тя се присвоява на две променливи. Аналогично се създава инстанция на структурата SomeStruct, в нея също се записва 100 и след това тя се присвоява на две променливи.

При присвояването на инстанциите на класа, понеже той е референтен тип, се присвоява само референцията и стойността реално не се копира, а остава обща. При присвояването на инстанцията на структурата, понеже тя е стойностен тип, се присвоява самата стойност (нейно копие). Поради тази причина в резултат от изпълнението на програмата на конзолата се отпечатват различни стойности.

По-долу са показани схематично стекът за изпълнение на програмата и динамичната памет в момента преди приключване на програмата. Данните са взети от дебъгера на Visual Studio .NET поради което са много близки до истинското разположение на паметта по време на изпълнение на примерната програма:

Стекът расте отгоре надолу (от големите адреси към адрес 0), защото програмата е изпълнена върху Intel-съвместима архитектура, при която това поведение е нормално.

Проследяване на примера с VS.NET

За да проследим как се изпълнява горният пример стъпка по стъпка, можем да използваме проекта Demo-1-Value-And-Reference-Types от демонстрациите:

1. Отваряме с VS.NET проекта Demo-1-Value-And-Reference-Types.sln.

2. Слагаме точка на прекъсване на последния ред от Main() метода на основния клас.

3. Стартираме приложението с [F5].

4. След като дебъгерът спре в точката на прекъсване, показваме Disassembly и Registers прозорците. От менюто на VS.NET избираме Debug | Windows | Disassembly и Debug | Windows | Registers. Ето как изглежда VS.NET в този момент:

5. Можем да разгледаме асемблерния код, получен след компилиране на програмата и след превръщането на MSIL кода в чист Win32 код за процесор Intel x86.

Повечето компилатори за Intel-базирани процесори генерират код, който използва в тялото на методите регистър EBP като указател към върха на стека. Адресиране от типа на dword ptr [ebp-14h] най-често реферира стойност в стека – локална променлива или параметър.

Спомнете си за разликите между класове и структури (референтни и стойностни типове). Стойностните типове съхраняват стойността си директно в стека. Референтните типове съхраняват в стека само 4-байтов адрес, който указва мястото на променливата в динамичната памет.

Често пъти, с цел оптимизация на производителността, компилаторът вместо някаква област от стека използва регистри за съхранение на локални променливи. В случая в EBX се съхранява референцията class2, а в EDI – референцията class1.

6. Да разгледаме асемблерния код, генериран за операцията присвояване class2=class1. В него се присвоява на регистър EBX стойността на регистър EDI, т.е. на референцията class2 се присвоява референцията class1. Обърнете внимание, че се копира референцията, а не самата стойност.

7. Да разгледаме асемблерния код, генериран за операцията присвояване struct2=struct1. В него се присвоява на регистър EAX стойността от стека, съответстваща на struct1 и след това стойността от EAX се записва обратно в стека, в променливата struct2. На практика се копира самата стойност на структурата, като се използва за работна променлива регистърът EAX.

Защита от неинициализирани променливи

Когато декларираме променлива в кода, C# компилаторът ни задължава да й зададем стойност преди първото й използване. Ако се опитаме да използване неинициализирана променлива (независимо дали е от стойностен или референтен тип), C# компилаторът дава грешка и отказва да компилира кода. Ето един пример:

int someVariable;

Console.WriteLine(someVariable);

При опит за компилация ще възникне грешката "Use of unassigned local variable someVariable".

Автоматична инициализация на променливите

При създаване на обект от даден тип с оператора new CLR автоматично инициализира декларираната променлива с неутрална (нулева) стойност. Ето един пример:

int i = new int();

Console.WriteLine(i);

Горният код се компилира успешно и отпечатва като резултат 0. Това се дължи на автоматичната инициализация, която операторът new извършва.

Когато заделяме структура или клас, се изпълнява и съответният конструктор и всички член-променливи на новия обект се инициализират с нулеви стойности. Това предпазва разработчиците от проблеми свързани с неинициализирани член-данни, които могат да бъдат много досадни, защото се проявяват само от време на време.

Ако само дефинираме променлива, без да създадем инстанция за нея с оператора new, ще получим грешка по време на компилация, защото променливата ще остане неинициализирана. Ето пример:

int i;

Console.WriteLine(i); // Use of unassigned local variable 'i'

Типът System.Object

Типът System.Object е базов за всички типове в .NET Framework. Както референтните, така и стойностните типове произлизат от System.Object или от негов наследник. Това улеснява програмиста и в много ситуации му спестява писане на излишен код.

В .NET Framework можем да напишем следния код:

string s = 5.ToString();

Този код извиква виртуалния метод ToString() от класа System.Object. Това е възможно, защото числото 5 е инстанция на типа System.Int32, който е наследник на System.Object.

Понеже всички типове са съвместими със System.Object (object в C#), защото са негови наследници, можем на инстанция на System.Object да присвояваме както референтни, така и стойностни типове:

object obj = 5;

object obj2 = new SomeClass();

Забележка: Ако не е указано друго, в C# целите числа по подразбиране са инстанции на типа System.Int32.

Защо стойностните типове наследяват референтния тип System.Object?

Ако си спомним, че System.Object е референтен тип, изглежда малко странно че стойностните типове също го наследяват. Сякаш има някакво противоречие: Как така стойностните типове, които не са указатели, произлизат от тип, който е указател?

Всъщност противоречие няма, защото архитектите на .NET Framework по изкуствен начин са направили съвместими всички стойностни типове със System.Object. За удобство в CLR всички стойностни типове могат да се преобразуват към референтни чрез операцията "опаковане". Опаковането и обратната му операция "разопаковане" преобразуват стойностни типове в опаковани стойностни типове и обратното. При опаковане стойностните типове се копират в динамичната памет и се получава указател (референция) към тях. При разопаковане стойността от динамичната памет, сочена от съответната референция, се копира в стека.

По късно в настоящата тема ще дискутираме в детайли опаковането и разопаковането на стойностни типове.

Потребителските типове скрито наследяват System.Object

При дефиниране на какъвто и да е тип, скрито от нас се наследява System.Object. Например структурата:

struct Point

{

int x, y;

}

е наследник на System.Object, макар това да не се вижда непосредствено от декларацията й.

Методите на System.Object

Като базов тип за всички .NET типове System.Object дефинира обща за всички тях функционалност. Тази функционалност се реализира в няколко метода, някои от които са виртуални и могат да бъдат припокрити:

- bool Equals(object) – виртуален метод, който сравнява текущия обект с друг обект. Методът има и статична версия Equals(object, object), която сравнява два обекта, подадени като параметри. Обектите се сравняват не по адрес, а по съдържание. Методът често пъти се припокрива, за да се даде възможност за сравнение на потребителски обекти.

- string ToString() – виртуален метод, който представя обекта във вид на символен низ. Имплементацията по подразбиране на ToString() отпечатва името самия тип.

- int GetHashCode() – виртуален метод за изчисляване на хеш-код. Използва се при реализацията на някои структури от данни, например хеш-таблици. По-нататък, в темата за масиви и колекции, ще разгледаме този метод по-детайлно.

- Finalize() – виртуален метод за имплементиране на почистващи операции при унищожаване на обект. В C# не може да се дефинира директно, а се имплементира чрез деструктора на типа. Ще разгледаме подробности за т. нар. "финализация на обекти" в темата за управление на паметта и ресурсите.

- Type GetType() – връща метаданни за типа на обекта във вид на инстанция на System.Type. Имплементиран е вътрешно от CLR.

- object MemberwiseClone() – копира двоичното представяне на обекта в нов обект, т. е. извършва плитко копиране. При референтни типове създава нова референция към същия обект. При стойностни типове копира стойността на подадения обект.

- bool ReferenceEquals() – сравнява два обекта по референция. При референтни типове се сравнява дали обектите сочат на едно и също място в динамичната памет. При стойностни типове връща false.

Предефиниране на сравнението на типове

Когато дефинираме собствен тип, често пъти се налага да се имплементира функционалност за сравнение на негови инстанции. В .NET Framework се препоръчва такава функционалност да се реализира чрез имплементиране на предвидените за целта методи в System.Object.

Препоръчва се методите Equals(object), operator ==, operator != и GetHashCode() да се имплементират заедно в комплект. Тази практика спестява някои доста досадни проблеми. Например ако Equals(object) е имплементиран, а операторът == не е имплементиран, потребителите на типа могат да се подведат и да извършват некоректно сравнение с ==, което по подразбиране връща резултата от метода ReferenceEquals().

Предефиниране на сравнението – пример

В настоящия пример се дефинира клас Student, който съдържа 2 информационни полета (име и възраст), след което се дефинират методите за сравнение на студенти. Счита се, че два студента са един и същ, ако имат еднакви имена и възраст. Предефинират се виртуалните методи Equals(object), operator ==, operator !=, GetHashCode() и ToString() от System.Object. С цел илюстриране как се използва предефинираното сравнение в края на примера се създават няколко инстанции на Student и се сравняват една с друга.

using System;

public class Student

{

public string mName;

public int mAge;

public override bool Equals(object aObject)

{

// If the cast is invalid, the result will be null

Student student = aObject as Student;

// Check if we have valid not null Student object

if (student == null)

{

return false;

}

// Compare the reference type member fields

if (! Object.Equals(this.mName, student.mName))

{

return false;

}

// Compare the value type member fields

if (this.mAge != student.mAge)

{

return false;

}

return true;

}

public static bool operator == (Student aStudent1,

Student aStudent2)

{

return Student.Equals(aStudent1, aStudent2);

}

public static bool operator != (Student aStudent1,

Student aStudent2)

{

return ! (Student.Equals(aStudent1, aStudent2));

}

public override int GetHashCode()

{

// Return the hash code of the mName field

return mName.GetHashCode();

}

public override string ToString()

{

return String.Format(

"Student(Name: {0}, Age: {1})", mName, mAge);

}

static void Main()

{

Student st1 = new Student();

st1.mName = "Бай Иван";

st1.mAge = 68;

Console.WriteLine(st1); // Student.ToString() is called

Student st2 = new Student();

if (st1 != st2) // it is true

{

Console.WriteLine("{0} != {1}", st1, st2);

}

st2.mName = "Бай Иван";

st2.mAge = 68;

if (st1 == st2) // it is true

{

Console.WriteLine("{0} == {1}", st1, st2);

}

st2.mAge = 70;

if (st1 != st2) // it is true

{

Console.WriteLine("{0} != {1}", st1, st2);

}

if (st1 != null) // it is true

{

Console.WriteLine("{0} is not null", st1);

}

След като се изпълни примерът, се получава следния резултат:

Как работи примерът?

Методът Equals(object) е реализиран на няколко стъпки. Първо се проверява дали е подаден обект от тип Student, който не е null. Това е необходимо условие, за да е възможно равенството на подадения студент с текущия студент. След това се сравняват имената на студентите и ако съвпаднат се сравняват и годините им. Истина се връща, само ако и двете сравнения установят равенство.

Операторите == и != се имплементират чрез извикване на Equals( object).

Методът GetHashCode() връща хеш-кода на името на студента, което ще върши работа в повечето случаи. По-подробно на този метод ще се спрем в темата "Масиви и колекции".

Методът ToString() връща символен низ, съдържащ името и възрастта на студента в лесно четим формат.

В главната програма (Main() метода) се извършват серия сравнения, които демонстрират правилната работа на имплементираните методи.

Оператори за работа с типове в C#

В C# има няколко служебни оператора за работа с типове – is и as и typeof.

Оператор is

Операторът is проверява дали зададеният обект е инстанция на даден тип. Пример:

int value = 5;

if (value is System.Object) // it is true

{

Console.WriteLine("{0} is instance of System.Object.", value);

}

Оператор as

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

int i = 5;

object obj = i;

string str = (string) obj; // System.InvalidCastException

Операторът as преобразува типове, без да предизвиква изключение:

int i = 5;

object obj = i;

string str = obj as string; // str == null

Оператор typeof

Операторът typeof извлича отражението на даден тип във вид на инстанция на System.Type. Пример:

Type intType = typeof(int);

В темата "Отражение на типовете" ще обърнем повече внимание на типа System.Type и на оператора typeof.

Оператори is и as – пример

В следващия пример се илюстрира използването на операторите is и as:

using System;

class Base

{

}

class Derived : Base

{

}

class TestOperatorsIsAndAs

{

static void Main()

{

Object objBase = new Base();

if (objBase is Base)

{

Console.WriteLine("objBase is Base");

}

// Result: objBase is Base

if (! (objBase is Derived))

{

Console.WriteLine("objBase is not Derived");

}

// Result: objBase is not Derived

if (objBase is System.Object)

{

Console.WriteLine("objBase is System.Object");

}

// Result: objBase is System.Object

Base b = objBase as Base;

Console.WriteLine("b = {0}", b);

// Result: b = Base

Derived d = objBase as Derived;

if (d == null)

{

Console.WriteLine("d is null");

}

// Result: d is null

Object o = objBase as Object;

Console.WriteLine("o = {0}", o);

// Result: o = Base

Derived der = new Derived();

Base bas = der as Base;

Console.WriteLine("bas = {0}", bas);

// Result: bas = Derived

}

Примерът декларира два класа – Base и негов наследник Derived, след което създава няколко инстанции от тези класове и ги преобразува една към друга. Работата на операторите is и as се илюстрира чрез няколко преобразувания и проверки на типовете. Резултатът от изпълнението на примерната програма е следния:

Клониране на обекти

Клонирането (копирането) на обекти е операция, която създава идентично копие на даден обект. При клонирането се създават копия на всички информационни полета (член-променливи) на типа. Съществуват 2 типа клониране – плитко и дълбоко.

Плитко клониране

При плитко клониране всички стойностни типове се копират, а всички референции се дублицират (копират се адресите). На практика се създава копие на обекта, което може да има общи (споделени) части с оригиналния обект (това са всички полета на оригиналния обект, които са от референтен тип). Плитко клониране се извършва от метода MemberwiseClone() на типа System.Object.

Дълбоко клониране

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

Плитки срещу дълбоки копия

В програмирането използването на плитки копия на обектите често води до проблеми и затова не е препоръчвана практика. Когато трябва да се клонира даден обект, обикновено е необходимо да се създаде негово пълно копие, а не само нова референция, сочеща към оригиналния обект.

В някои редки случаи, от съображения за производителност и пестене на ресурси, се налага да се ползват плитки или частични копия на обектите. Ако се прилагат такива техники, това трябва да се прави много внимателно, за да не се получават странни проблеми, като синдромът "ама това вчера работеше".

Интерфейсът ICloneable

В .NET Framework под клониране се подразбира "дълбоко клониране". Всички типове, които позволяват клониране, трябва да имплементират интерфейса System.ICloneable.

ICloneable дефинира метод Clone() който връща идентично копие на обекта. Clone() методът трябва да връща дълбоко копие на оригиналния обект. Ако даден обект съдържа като член-данни други обекти, тези обекти трябва също да имплементират ICloneable и да бъдат клонирани посредством Clone() метода им. Ако това не бъде изпълнено, има вероятност клонирането да не работи правилно и да се получат споделени данни между оригиналния обект и копието.

Клониране на обекти в .NET Framework

Клонирането като цяло е проблем, при който често възникват грешки, но за щастие рядко се налага да бъде имплементирано ръчно.

Голяма част от често използваните стандартни типове в .NET Framework имат имплементация на ICloneable – масивите, колекциите, символните низове и др. Примитивните стойностни типове (int, float, double, byte, char и т. н.) могат да бъдат клонирани чрез просто присвояване, защото не съдържат вложени членове от референтен тип. При тях на практика всяко клониране е дълбоко.

Имплементиране на ICloneable – пример

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

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

using System;

using System.Text;

class LinkedList : ICloneable

{

public string mValue;

protected LinkedList mNextNode;

public LinkedList(string aValue, LinkedList aNextNode)

{

mValue = aValue;

mNextNode = aNextNode;

}

public LinkedList(string aValue) : this(aValue, null)

{

}

// Explicit implementation of ICloneable.Clone()

object ICloneable.Clone()

{

return this.Clone();

}

// This method is not ICloneable.Clone()

public LinkedList Clone()

{

// Clone the first element

LinkedList original = this;

string value = original.mValue;

LinkedList result = new LinkedList(value);

LinkedList copy = result;

original = original.mNextNode;

// Clone the rest of the list

while (original != null)

{

value = original.mValue;

copy.mNextNode = new LinkedList(value);

original = original.mNextNode;

copy = copy.mNextNode;

}

return result;

}

public override string ToString()

{

LinkedList currentNode = this;

StringBuilder sb = new StringBuilder("(");

while (currentNode != null)

{

sb.Append(currentNode.mValue);

currentNode = currentNode.mNextNode;

if (currentNode != null)

{

sb.Append(", ");

}

sb.Append(")");

return sb.ToString();

}

class TestClone

{

static void Main()

{

LinkedList list1 =

new LinkedList("Бай Иван",

new LinkedList("Баба Яга",

new LinkedList("Цар Киро")));

Console.WriteLine("list1 = {0}", list1);

// Result: list1 = (Бай Иван, Баба Яга, Цар Киро)

LinkedList list2 = list1.Clone();

list2.mValue = "1st changed";

Console.WriteLine("list2 = {0}", list2);

// Result: list2 = (1st changed, Баба Яга, Цар Киро)

Console.WriteLine("list1 = {0}", list1);

// Result: list1 = (Бай Иван, Баба Яга, Цар Киро)

}

В примерната реализация е дефиниран свързан списък от символни низове. Методът ICloneable.Clone() е реализиран експлицитно (явно). Допълнително за удобство е дефиниран метод Clone(). Разликата между двата метода е във връщания тип. Имплементацията на интерфейса ICloneable (методът ICloneable.Clone()) връща object и ако се използва, трябва да се извършва преобразуване. Методът Clone() връща директно правилния тип и ни спестява преобразуването.

Методът ToString() използва специалния клас StringBuilder за по-ефективно сглобяване на резултатния низ. Класът StringBuilder и причините за използването му ще бъдат разгледани подробно в темата за работа със символни низове.

Главната програма създава списък list1, съдържащ 3 елемента, и го отпечатва. След това го клонира в променливата list2 и променя първия му елемент. Тъй като оригиналният списък и неговото копие не съдържат споделени данни, оригиналният списък не се променя и това ясно личи от изведения резултат:

Опаковане (boxing) и разопаковане (unboxing) на стойностни типове

Вече обяснихме, че стойностните типове се съхраняват в стека на приложението и не могат да приемат стойност null, докато референтните типове съдържат указател (референция) към стойност в динамичната памет и могат да бъдат null.

Понякога се налага на референтен тип да се присвои обект от стойностен тип. Например може да се наложи в System.Object инстанция да се запише System.Int32 стойност. CLR позволява това благодарение на т. нар. "опаковане" на стойностните типове (boxing).

В .NET Framework стойностните типове могат да се използват без преобразуване навсякъде, където се изискват референтни типове. При нужда CLR опакова и разопакова стойностните типове автоматично. Това спестява дефинирането на обвиващи (wrapper) класове за примитивните типове, структурите и изброените типове, но разбира се, може да доведе и до някои проблеми, които ще дискутираме по-късно.

Опаковане (boxing) на стойностни типове

Опаковането (boxing) е действие, което преобразува стойностен тип в референция към опакована стойност. То се извършва, когато е необходимо да се преобразува стойностен тип към референтен тип, например при преобразуване на Int32 към Object:

int i = 5;

object obj = i; // i се опакова

Всяка инстанция на стойностен тип може да бъде опакована чрез просто преобразуване до System.Object. Ако един тип е вече опакован, той не може да бъде опакован втори път и при преобразуване към System.Object си остава опакован само веднъж.

CLR извършва опаковането по следния начин:

1. Заделя динамична памет за създаване на копие на обекта от стойностния тип.

2. Копира съдържанието на стойностната променливата от стека в заделената динамична памет.

3. Връща референция към създадения обект в динамичната памет.

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

Разопаковане (unboxing) на опаковани типове

Разопаковането (unboxing) е процесът на извличане на опакована стойност от динамичната памет. Разопаковане се извършва при преобразуване на опакована стойност обратно към инстанция на стойностен тип, например при преобразуване на Object към Int32:

object obj = 5; // 5 се опакова

int value = (int) obj; // стойността на obj се разопакова

CLR извършва разопаковането по следния начин:

1. Ако референцията е null се предизвиква NullReferenceException.

2. Ако референцията не сочи към валидна опакована стойност от съответния тип, се предизвиква изключение InvalidCastException.

3. Ако референцията е валидна опакована стойност от правилния тип, стойността се извлича от динамичната памет и се записва в стека.

За разлика от опаковането, разопаковането невинаги е успешна операция (и това трябва да се съобразява, когато се работи с опаковани стойности).

Особености при опаковането и разопаковането

При използване на автоматично опаковане и разопаковане на стойности трябва да се имат предвид някои особености:

- Опаковането и разопаковането намаляват производителността. За оптимална производителност трябва да се намали броят на опакованите и разопакованите обекти.

- Опакованите типове са копия на оригиналните стойности, поради което, ако променяме оригиналния неопакован тип, опакованото копие не се променя.

Как работят опаковането и разопаковането?

Нека имаме следния код:

int i = 5;

object obj = i; // boxing

int i2;

i2 = (int) obj; // unboxing

На картинката по-долу схематично е показано как работят опаковането и разопаковането на стойностни типове в .NET Framework:

При опаковане стойността от стека се копира в динамичната памет, а при разопаковане стойността от динамичната памет се копира в обратно в стека.

Опакованите стойности се държат като останалите референтни типове – разполагат се в динамичната памет, унищожават се от garbage collector, когато не са необходими на програмата, и при подаване като параметър при извикване на метод се пренасят по адрес.

Пример за опаковане и разопаковане

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

using System;

class TestBoxingUnboxing

{

static void Main()

{

int value1 = 1;

object obj = value1; // извършва се опаковане

value1 = 12345; // променя се само стойността в стека

int value2 = (int)obj; // извършва се разопаковане

Console.WriteLine(value2); // отпечатва се 1

long value3 = (long) (int) obj; // разопаковане

long value4 = (long) obj; // InvalidCastException

}

От примера се вижда, че разопаковане на Int32 стойност не може да се извърши чрез директно преобразуване към Int64. Необходимо е първо да се извлече Int32 стойността от опакования обект и след това да се извърши преобразуване до Int64.

Аномалии при опаковане и разопаковане

При работа с опаковани обекти трябва да се внимава, защото ако не бъдат съобразени някои особености, може да се наблюдава странно поведение на програмата. Ето един такъв пример:

using System;

interface IMovable

{

void Move(int aX, int aY);

}

/// <summary>

/// Много лоша практика! Структурите не бива

/// да съдържат логика, а само данни!

/// </summary>

struct Point : IMovable

{

public int mX, mY;

public void Move(int aX, int aY)

{

mX += aX;

mY += aY;

}

public override string ToString()

{

return String.Format("({0},{1})", mX, mY);

}

class TestPoint

{

static void Main()

{

Point p1 = new Point();

Console.WriteLine("p1={0}", p1); // p1=(0,0)

IMovable p1mov = (IMovable) p1; // p1 се опакова

IMovable p2mov = // p1mov не се опакова втори

(IMovable) p1mov; // път, защото е вече опакован

Point p2 = (Point) p2mov; // p2mov се разопакова

p1.Move(-100,-100);

p2mov.Move(5,5);

p2.Move(100,100);

Console.WriteLine("p1={0}", p1); // p1=(-100,-100)

Console.WriteLine("p1mov={0}", p1mov); // p1mov=(5,5)

Console.WriteLine("p2mov={0}", p2mov); // p2mov=(5,5)

Console.WriteLine("p2={0}", p2); // p2=(100,100)

}

Резултатът от изпълнение на примера е следният:

Основната причина за този резултат е фактът, че при преобразуване към интерфейс структурите се опаковат и съответно се създава копие на данните, намиращи се в тях. Опаковането е съвсем в реда на нещата, като се има предвид, че структурите са стойностни типове, а интерфейсите са референтни типове.

Препоръчва се, когато се използват структури в C#, те да съдържат само данни. Лоша практика е в структура да се дефинират методи с логика, както и структура да имплементира интерфейс.

Как работи примерът?

Да разгледаме как работи примерът. Ако съобразим разположението на стойностните и референтните променливи в паметта, можем да си обясним какво се случва:

Променливите p1 и p2 са от стойностен тип и се разполагат директно в стека (и заемат по 8 байта от него).

Променливите p1mov и p2mov са от референтен тип и се разполагат в динамичната памет. В стека за тях се пазят по 4 байта, които съдържат адреса на стойността им.

С помощта на дебъгера на VS.NET можем да проследим точното разположение и стойностите на тези променливи. В горната таблица е показано състоянието им точно преди завършване на програмата.

Напомняме, че при Intel архитектурата стекът расте надолу и свършва на адрес 0x00000000.

Интерфейсът IComparable

Често пъти освен за равенство е необходимо обектите да се сравняват спрямо някаква подредба (например лексикографска за низове или по големина за числови типове). В .NET Framework типовете, които могат да бъдат сравнявани един с друг, трябва да имплементират интерфейса System.IComparable.

Интерфейсът дефинира един-единствен метод – CompareTo(object). Този метод трябва да реализира сравняването и да връща:

- число < 0 – ако подаденият обект е по-голям от this инстанцията

- 0 – ако подаденият обект е равен на this инстанцията

- число > 0 – ако подаденият обект е по-малък от this инстанцията

IComparable се използва от .NET Framework при сортиране на масиви и колекции и при някои други операции, изискващи сравнение по големина.

Системни имплементации на IComparable

IComparable е имплементиран от много системни .NET типове, като например от примитивните стойностни типове System.Char, System.Int32, System.Single, System.Double, от символните низове (System.String) и от изброените типове (System.Enum). Това улеснява разработчиците при всекидневната им работа и често пъти им спестява излишни усилия.

Имплементиране на IComparable – пример

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

using System;

class Student : IComparable

{

private string mFirstName;

private string mLastName;

public Student(string aFirstName, string aLastName)

{

mFirstName = aFirstName;

mLastName = aLastName;

}

public int CompareTo(object aObject)

{

if (! (aObject is Student))

{

throw new ArgumentException(

"The object is not Student.");

}

Student student = (Student) aObject;

int firstNameCompareResult =

String.Compare(this.mFirstName, student.mFirstName);

if (firstNameCompareResult != 0)

{

return firstNameCompareResult;

}

else

{

int lastNameCompareResult =

String.Compare(this.mLastName, student.mLastName);

return lastNameCompareResult;

}

class TestIComparable

{

static void Main()

{

Student st1 = new Student("Бате", "Киро");

Student st2 = new Student("Кака", "Мара");

Console.WriteLine(

"st1.CompareTo(st2) = {0}", st1.CompareTo(st2));

// Result: -1

Console.WriteLine(

"st1.CompareTo(st1) = {0}", st1.CompareTo(st1));

// Result: 0

Console.WriteLine(

"st1.CompareTo(42) = {0}", st1.CompareTo(42));

// Result: System.ArgumentException

}

В примера се дефинира клас Student, който съдържа две информационни полета – име и фамилия. Имплементацията на CompareTo() извършва лексикографско сравнение на студенти – първо по име, а след това по фамилия при еднакви имена. Ето как изглежда изходът от примера:

Интерфейсите IEnumerable и IEnumerator

В програмирането се срещат типове, които съдържат много на брой инстанции на други типове. Такива типове се наричат контейнери или още колекции. Колекции например са масивите, защото съдържат много на брой еднакви елементи.

Често пъти се налага да се обходят всички елементи на даденa колекция. За да става това по стандартен начин, в .NET Framework са дефинирани интерфейсите IEnumerable и IEnumerator.

Интерфейсът IEnumerable

Интерфейсът System.IEnumerable се имплементира от колекции и други типове, които поддържат операцията "обхождане на елементите им в някакъв ред". Този интерфейс дефинира само един метод – методът GetEnumerator(). Той връща итератор (инстанция на IEnumerator) за обхождане на елементите на дадения обект.

Обектите, поддържащи IEnumerable интерфейса, могат да се използват от конструкцията foreach в C# за обхождане на всичките им елементи.

Интерфейсът IEnumerable е реализиран от много системни .NET типове, като System.Array, System.String, ArrayList, Hashtable, Stack, Queue, SortedList и др. с цел да се улесни работата с тях.

Интерфейсът IEnumerator

Интерфейсът System.IEnumerator имплементира обхождане на всички елементи на колекции и други типове. Той реализира прост итератор чрез следните методи и свойства:

- Свойство Current – връща текущия елемент.

- Метод bool MoveNext() – преминава към следващия елемент и връща true, ако той е валиден.

- Метод Reset() – премества итератора непосредствено преди първия елемент (установява го в начално състояние).

Имплементиране на IEnumerable и IEnumerator

Следващият пример илюстрира как могат да бъдат имплементирани интерфейсите IEnumerable и IEnumerator, след което да бъдат използвани във foreach конструкция в C#:

using System;

using System.Collections;

class BitSet32 : IEnumerable

{

private uint mBits = 0;

public void Set(int aIndex, bool aValue)

{

if (aIndex<0 || aIndex>31)

{

throw new ArgumentException("Invalid index!");

}

uint bitMask = (uint) 1 << aIndex;

// Set bit aIndex to 0

mBits = mBits & (~bitMask);

if (aValue)

{

// Set bit aIndex to 1

mBits = mBits | bitMask;

}

public bool Get(int aIndex)

{

if (aIndex<0 || aIndex>31)

{

throw new ArgumentException("Invalid index!");

}

uint bitMask = (uint) 1 << aIndex;

bool value = ((mBits & bitMask) != 0);

return value;

}

public IEnumerator GetEnumerator()

{

return new BitSet32Enumerator(this);

}

class BitSet32Enumerator : IEnumerator

{

private BitSet32 mBitSet32;

private int mCurrentIndex = -1;

public BitSet32Enumerator(BitSet32 aBitSet32)

{

mBitSet32 = aBitSet32;

}

public bool MoveNext()

{

mCurrentIndex++;

bool valid = (mCurrentIndex < 32);

return valid;

}

public void Reset()

{

mCurrentIndex = -1;

}

public object Current

{

get

{

return mBitSet32.Get(mCurrentIndex);

}

class TestBitSet32

{

static void Main()

{

BitSet32 set = new BitSet32();

set.Set(0, true);

set.Set(31, true);

set.Set(5, true);

set.Set(5, false);

set.Set(10, true);

int index = 0;

foreach (bool value in set)

{

Console.WriteLine("set[{0}] = {1}", index, value);

index++;

}

Резултатът от изпълнение на примера е следният:

Как работи примерът?

Класът BitSet32 представлява множество от 32 булеви стойности. Той съхранява стойностите си в UInt32 поле като комбинация от битове – по 1 бит за всяка от тях. Методът Set(index, value) изчислява битова маска за зададения индекс, нулира съответния бит и ако е зададена стойност true, го установява след това в единица. Методът Get(index) изчислява битова маска за зададения индекс и връща стойността на съответния бит.

Класът BitSet32 имплементира интерфейса IEnumerable като в метода му GetEnumerator() създава и връща инстанция на специален вътрешен клас BitSet32Enumerator, инициализирана по текущия BitSet32 обект.

Класът BitSet32Enumerator е имплементация на интерфейса IEnumerator. Той съхранява текущия индекс от обхождането на BitSet32 обекта във вътрешна променлива mCurrentIndex. Методът MoveNext() увеличава текущия индекс и ако не е достигнат краят, връща true. Методът Reset() задава стойност -1 за текущия индекс (това е елементът преди първия). Свойството Current връща елемента от текущата позиция.

Главната програма демонстрира правилната работа на класа BitSet32 и имплементацията на интерфейсите IEnumerable и IEnumerator. Тя създава инстанция на BitSet32, променя някои от битовете и отпечатва всички стойности с цикъл foreach.

Упражнения

1. Избройте основните разлики между стойностните и референтните типове. Кои от следните типове са стойностни и кои референтни?

- int, char, string, float, изброени типове, класове, структури, интерфейси, делегати, масиви, указатели, опаковани стойностни типове

2. Дефинирайте клас Student, който съдържа данните за един студент: трите му имена, ЕГН, местоживеене (постоянен и временен адрес), телефон (стационарен и мобилен), e-mail, курс, специалност, ВУЗ, факултет и т.н. Използвайте изброен тип (enumeration) за специалностите, ВУЗ-овете и факултетите. Реализирайте стандартните методи, наследени от System.Object: Equals(object), ToString(), GetHashCode() и операторите == и !=.

3. Добавете имплементация на интерфейса ICloneable за класа Student. Методът Clone() трябва да копира в нов обект всяко от полетата на класа Student.

4. Дефинирайте структурата от данни двоично наредено дърво за претърсване (binary search tree) с операции "добавяне на елемент", "търсене на елемент" и "изтриване на елемент". Не е необходимо да поддържате дървото балансирано (това ще ви спести много усилия). Имплементирайте виртуалните методи ToString(), Equals(object), GetHashCode() от System.Object и операторите за сравнение == и !=. Добавете и реализация на интерфейса ICloneable за дълбоко копиране на дървото.

Упътване: За да улесните работата си, използвайте два типа – клас BinarySearchTree (за самото дърво) и клас TreeNode (за елементите на дървото).

5. Дефинирайте клас ComplexNumber, който съдържа комплексно число. Имплементирайте за него интерфейса IComparable.

6. Дефинирайте клас BitSet256, който представлява масив от 256 булеви стойности и се съхранява вътрешно като 4 на брой 64-битови полета (UInt64). Реализирайте методи Get(int index), Set(int index, bool value) и индексатор за достъп. Имплементирайте и интерфейса IEnumerable, като за целта използвате вътрешен клас, който имплементира IEnumerator.

Използвана литература

1. Светлин Наков, Обща система от типове (Common Type System) – http://www.nakov.com/dotnet/lectures/Lecture-4-Common-Type-System-v1.0.ppt

2. Jeffrey Richter, Applied Microsoft .NET Framework Programming, Microsoft Press, 2002, ISBN 0735614229

3. Tom Archer, Andrew Whitechapel, Inside C#, 2-nd Edition, Microsoft Press, 2002, ISBN 0735616485

4. MSDN Training, Programming with the MSicrosoft® .NET Framework (MOC 2349B), Module 5: Common Type System

5. Svetlin Nakov, .NET Framework Overview – http://www.nakov.com/ publications/Nakov-DotNET-Framework-Overview-english.ppt

6. MSDN Library – http://msdn.microsoft.com

Глава 8. Масиви и колекции

Необходими знания

- Базови познания по структури от данни

- Базови познания за общата система от типове в .NET (Common Type System)

- Базови познания за езика C#

Съдържание

- Масиви в .NET Framework

- Многомерни масиви. Масиви от масиви

- Типът System.Array

- Сортиране на масиви и двоично търсене

- Колекции в .NET Framework

- IList, ArrayList, Queue и Stack

- IDictionary и Hashtable. Собствени хеш-функции

- Класът SortedList

В тази тема ...

В настоящата тема ще се спрем на масивите и колекциите в .NET Framework. Ще разгледаме видовете масиви: едномерни, многомерни и масиви от масиви (т. нар. назъбени масиви), както и базовия тип за всички масиви System.Array. Ще се запознаем с начините за сортиране на масиви и търсене в тях. Ще разгледаме с колекциите и тяхната реализация в .NET Framework: класовете ArrayList, Queue, Stack, Hashtable и SortedList, както и интерфейсите, които те имплементират.

Какво e масив?

Масивите са наредени последователности от еднакви по тип елементи. Те представляват механизми, който ни позволяват да третираме тези последователности като едно цяло.

Деклариране на масиви

Масиви в C# декларираме по следния начин:

int[] myArray;

В случая сме декларирали масив с име myArray от целочислен тип (System.Int32). В началото myArray има стойност null, тъй като не е заделена памет за елементите на масива.

Заделяне на масиви

Със следния код заделяме (алокираме) масив в C#:

myArray = new int[5];

В примера се заделя масив с размер 5 елемента от целочислен тип.

При заделяне на масив CLR автоматично инициализира всички негови елементи с неутрална стойност (0 или null). В нашия пример всеки от тези 5 елемента е със стойност 0, за разлика от други неуправлявани среди, където стойностите ще са произволни (C, C++). Адресът на блока памет, заделен за този масив се записва в променливата myArray.

Масивите в .NET Framework

Всички масиви в .NET Framework наследяват типа System.Array, което означава, че те винаги са референтни типове и се разполагат в блокове от динамичната памет (т. нар. managed heap).

От своят страна типът System.Array имплементира следните интерфейси: ICloneable, IList, IEnumerable и ICollection, които позволят масивите да се използват лесно в различни ситуации. Ще разгледаме тези интерфейси малко по-късно в настоящата тема.

Тъй като са референтни типове масивите винаги се предават по референция (т.е. по адрес, а не по стойност). Ако искаме да подадем даден масив като параметър, но да защитим от промяна стойностите на неговите елементи, трябва да подадем негово копие. Копие на масив можем да направим чрез статичния метод Array.Copy(…). Обърнете внимание, че този статичен метод прави плитки копия на елементите на масива.

Елементи на масивите

Достъпът до елементите на масивите е пряк, по индекс (пореден номер на елемента). Масивите обикновено са нулево-базирани, т.е. номерацията на елементите започва от 0. В .NET Framework обаче могат да се създадат и масиви с ненулева долна граница. Елементите на масивите са достъпни както за четене така и за писане.

Достъпът до елементите на масивите е проверен, т.е не се допуска излизане извън границите и размерностите на масив и при всеки достъп CLR проверява дали индексът е валиден и ако не е, се подава изключение System.IndexOutOfRangeException. Естествено тази проверка си има и своята цена и това е производителността. CLR обаче ни предоставя възможността да я изключим, като използваме ключовата дума unsafe. Тя се използва винаги, когато искаме да извършваме операции свързани с указатели. С unsafe трябва да обозначим метода, който ще извършва тези операции. Ето пример:

unsafe static void FastArrayAccess(int[] myArray)

{

// Acess the array elements here with no checks

}

При компилация на код, който използва unsafe трябва да укажем опцията на компилатора, че кодът има unsafe блокове. Ето как става това:

csc.exe /unsafe UnsafeArrayAccess.cs

Ако за нашето приложение бързодействието е от най-голямо значение можем да използваме unsafe код. Не трябва да забравяме обаче, че кодът, който пишем, вече няма да е управляван (managed) и CLR няма да се грижи за неговата обезопасеност.

Видове масиви

В .NET Framework се подържат едномерни, многомерни и масиви от масиви ("назъбени" масиви). Всеки от тези видове пази в себе си информация за броя на размерностите си (т. нар. ранг), както и границите на всяка от тях. CLR е оптимизиран за работа с едномерни, нулево-базирани масиви, затова се препоръчва тяхното използване, когато е възможно. Масивите могат да се инициализират при деклариране.

Масиви – пример

Ще илюстрираме работата с масиви със следния пример:

int[] primes = {2, 3, 5, 7, 11, 13, 17, 19};

foreach (int p in primes)

{

Console.Write("{0} ", p);

}

Console.WriteLine();

// Output: 2 3 5 7 11 13 17 19

for (int i = 0; i < primes.Length; i++)

{

primes[i] = primes[i] * primes[i];

}

foreach (int p in primes)

{

Console.Write("{0} ",p);

}

Console.WriteLine();

// Output: 4 9 25 49 121 169 289 361

В горния пример първоначално създаваме едномерен масив от тип System.Int32, инициализираме го с първите 8 прости числа, след което го извеждаме в конзолата.

След това на всеки елемент му се присвоява за стойност неговия квадрат. Забележете, че се използва свойството Length, което връща броя на елементите на масива. В .NET Framework всеки масив знае своята дължина.

Най-накрая новополучените стойности отново извеждаме на екрана чрез цикъл, реализиран с конструкцията foreach. Използването на foreach е възможно, защото масивите реализират интерфейса IEnumerable.

Прости числа – пример

В следващия пример ще използваме масиви за да реализираме един от най-старите алгоритми – решето на Ератостен:

using System;

class PrimeNumbersDemo

{

static void Main()

{

const int COUNT = 100;

bool[] prime = new bool[COUNT+1]; // array [0..100]

for (int i = 2; i <= COUNT; i++)

{

prime[i] = true;

}

for (int p = 2; p <= COUNT; p++)

{

if (prime[p])

{

Console.Write("{0} ", p);

for (int i = 2*p; i <= COUNT; i += p)

{

prime[i] = false;

}

Console.WriteLine();

}

Резултатът от изпълнението на програмата е следният:

Как работи примерът?

Алгоритъмът на Ератостен работи по следния начин: записваме числата от 2 до n (в нашия случай 100) в редица. Първоначално всички числа са незачертани. Намираме първото незачертано число – в началото това е 2, маркираме го като просто и зачертаваме всяко кратно на 2 число в редицата. Продължаваме по същия начин със следващото незачертано число – 3. Процесът продължава докато не остане нито едно незачертано число. Тогава всички маркирани числа са прости.

Сега да се спрем по-подробно на конкретната реализация на C#. За маркирането и зачертаването на елементите ще използваме масив от тип System.Boolean. Понеже CLR инициализира по подразбиране булевите стойности с false, първият цикъл в кода им задава стойност true, като по този начин маркираме всички числа като прости. След това започваме цикъл по дължината на масива (COUNT) и за всяка негова итерация проверяваме дали текущото число е маркирано, ако е извеждаме го и зачертаваме неговите кратни. В крайна сметка ако елемент на масива prime има стойност true, неговият индекс е просто число.

Забележка: първият цикъл започва от 2, защото както знаем 1 не е просто число.

Масиви от референтни типове – пример

Със следващия пример ще илюстрираме използването на масив, чиито елементи са референтни типове, в частност – инстанции на класове дефинирани от нас.

using System;

class Animal

{

public virtual void Eat()

{

Console.WriteLine("Animals eat food");

}

class Tiger : Animal

{

public override void Eat()

{

Console.WriteLine("Tigers eat meat");

}

class Cow : Animal

{

public override void Eat()

{

Console.WriteLine("Cows eat grass");

}

class ArrayTest

{

static void Main()

{

Animal[] animals = new Animal[3];

animals[0] = new Animal();

animals[1] = new Tiger();

animals[2] = new Cow();

foreach (Animal animal in animals)

{

animal.Eat();

}

В примера се дефинира клас Animal, който има виртуален метод Eat(). Класът Animal се наследява от други два класа – Tiger и Cow, които от своя страна припокриват (override) този виртуален метод. В Main() метода създаваме масив от обекти от тип Animal. След създаването на масива animals, всеки един от неговите елементи е инициализиран със стойност null, защото Animal е референтен тип и се създават само нулеви референции към него, а действителните обекти се създават на следващите 3 реда. Обърнете внимание, че в масива можем да записваме инстанции не само към Animal, а и към всички класове, които са негови наследници. Накрая за всеки елемент на масива извикваме метода Eat(). Благодарение на полиморфизма резултатът от изпълнението на програмата е следният:

Многомерни масиви

Освен вече разгледаните едномерни масиви, .NET Framework поддържа и многомерни такива (масиви с няколко размерности). Декларирането на многомерен масив е почти същото, както при едномерните, но само с една разлика – трябва да поставим запетая между размерностите му:

int[,] matrix = new int[3,3];

char[,,] box = new char[2,5,10];

Инициализиране и достъп до елементите

Ако искаме да инициализираме многомерен масив още при декларация трябва да спазим следното правило, а именно че трябва да поставим всяко измерение в отделни "къдрави скоби". Ето и пример:

int[,] matrix = { {1, 2, 3} , {4, 5, 6} , {7, 8, 9} };

Достъпът до елементите отново е по индекс, само че в многомерния вариант отново трябва да поставим запетая между индексите на отделните размерности:

int elem = matrix[3,3];

box[1,2,3] = 'a';

Разположение в паметта

Многомерните масиви разполагат елементите си последователно – един след друг в линейни блокове от динамичната памет. Ето как би изглеждало това за вече декларирания и инициализиран с естествените числа от 1 до 9 двумерен масив matrix:

Многомерни масиви – пример

В следващия пример ще използваме двумерни масиви за да реализираме умножение на матрици:

using System;

class MatrixMultiplicationDemo

{

static void PrintMatrix(int[,] aMatrix)

{

for (int row = 0; row < aMatrix.GetLength(0); row++)

{

for (int col = 0; col < aMatrix.GetLength(1); col++)

{

Console.Write("{0} ", aMatrix[row, col]);

}

Console.WriteLine();

}

Console.WriteLine();

}

static int[,] Mult(int[,] aMatrix1, int[,] aMatrix2)

{

int width1 = aMatrix1.GetLength(1);

int height1 = aMatrix1.GetLength(0);

int width2 = aMatrix2.GetLength(1);

int height2 = aMatrix2.GetLength(0);

if (width1 != height2)

{

throw new ArgumentException("Invalid dimensions!");

}

int[,] resultMatrix = new int[height1, width2];

for (int row = 0; row < height1; row++)

{

for (int col = 0; col < width2; col++)

{

resultMatrix[row, col] = 0;

for (int i = 0; i < width1; i++)

{

resultMatrix[row, col] +=

aMatrix1[row, i] * aMatrix2[i, col];

}

return resultMatrix;

}

static void Main()

{

int[,] m1 = new int[4,2]

{

{1,2},

{3,4},

{5,6},

{7,8}

};

PrintMatrix(m1);

int[,] m2 = new int[2,3]

{

{1,2,3},

{4,5,6}

};

PrintMatrix(m2);

int[,] m3 = Mult(m1, m2);

PrintMatrix(m3);

}

Как работи примерът?

Условието, на което трябва да отговарят две матрици за да можем да ги умножим е: броят на стълбовете на първата матрица да е равен на броя на редовете на втората матрица. Ако това не е изпълнено подаваме ArgumentException. След умножението новополучената матрица ще има следните размери: брой редове – броят на редовете на първата матрица, брой стълбове – броят на стълбовете на втората.

Самото умножение става така: всеки ред на първата матрица се умножава с всеки стълб на втората, т. е. първият елемент от реда с първия от стълба, вторият с втория и т. н. Получените произведения сумираме и това е стойността на елемента, който ще запишем в новополучената матрица на ред текущия ред от първата матрица и стълб – текущият от втората.

Ето и изхода от примера:

Масиви от масиви

В .NET Framework могат да се използват още и масиви от масиви или т. нар. назъбени (jagged) масиви. Може би се чудите от къде идва това име? След следващите редове ще ви се изясни.

Назъбеният масив представлява масив от масиви, т. е. всеки негов ред на практика е масив, който може да има различна дължина от останалите в назъбения масив, но не може да има различна размерност. Със следващия код декларираме масив от масиви:

int[][] jaggedArray;

Единственото по-особено е, че нямаме само една двойка скоби, както при обикновените масиви, а имаме вече две двойки такива. По следния начин заделяме назъбен масив:

jaggedArray = new int[2][];

jaggedArray[0] = new int[5];

jaggedArray[1] = new int[3];

Възможно е и декларирането, заделянето и инициализацията на един масив от масиви да се извършва в един израз. Ето пример:

int[][] myJaggedArray = {

new int[] {1,3,5,7,9},

new int[] {17,23},

new int[] {0,2,4,6}

};

Инициализиране и достъп до елементите

Достъпът до елементите на масивите, който са част от назъбения, отново е по индекс. Ето пример за достъп до елемента с индекс 3 от масива, който има индекс 0 в по-горе дефинирания назъбен масив jaggedArray:

jaggedArray[0][3] = 12345;

Както споменахме, елементите на назъбения масив може и да са не само едномерни масиви, но и многомерни такива. В следващия код създаваме назъбен масив от двумерни масиви:

int[][,] jaggedOfMulti = new int [3][,] ;

jaggedOfMulti[0] = new int[,] { {9,27}, {10,20} };

Разположение в паметта

Ако все още не ви си е изяснило защо наричаме масивите от масиви – назъбени, може би тази следващата картинка ще ви помогне. На нея може да видим вече дефинирания назъбен масив myJaggedArray и по точно неговото разположение в паметта. Както се вижда, самият назъбен масив съдържа само референции към масивите, а не самите тях. Тъй като не знае каква ще е размерността на всеки от масивите, CLR заделя само референцията за тях. Чак след като се задели памет за някой от масивите елементи на назъбения, тогава се насочва указателя към новосъздадения блок динамична памет.

Триъгълник на Паскал – пример

В следващия пример ще използваме назъбен масив за да генерираме и визуализираме триъгълника на Паскал. Както знаем от математиката, всяко число от триъгълника се образува като се съберат горните две над него. Естествено, това не важи за първото число в триъгълника – 1. Триъгълникът на Паскал има широко приложение в комбинаториката.

using System;

class PascalTriangle

{

static void Main()

{

const int HEIGHT = 12;

// Allocate the array in a triangle form

long [][] triangle = new long[HEIGHT+1][];

for (int row = 0; row <= HEIGHT; row++)

{

triangle[row] = new long[row+1];

}

// Calculate the Pascal's triangle

triangle[0][0] = 1;

for (int row = 0; row < HEIGHT; row++)

{

for (int col = 0; col <= row; col++)

{

triangle[row+1][col] += triangle[row][col];

triangle[row+1][col+1] += triangle[row][col];

}

// Print the Pascal's triangle

for (int row = 0; row <= HEIGHT; row++)

{

Console.Write("".PadLeft((HEIGHT-row)*2));

for (int col = 0; col <= row; col++)

{

Console.Write("{0,3} ", triangle[row][col]);

}

Console.WriteLine();

}

Ето и резултата от изпълнението на програмата:

Типът System.Array

Всички масиви в .NET Framework наследяват типа System.Array. Това наследяване става неявно и се извършва от CLR. Абстрактният тип System.Array предлага няколко метода и свойства, който също се наследяват от всички масиви. В следващите таблици ще разгледаме по-важните методи и свойства на System.Array.

Свойства

Свойство	Описание
Rank	Връща броя на размерностите (измеренията) на масива.
Length	Връща цяло число от тип System.Int32, което представлява общия брой на елементите (от всички размерности) на масива.
LongLength	Връща цяло число от тип System.Int64, което представлява общия брой на елементите (от всички размерности) на масива.

Забележка: Изброените свойства са достъпни само за четене.

Методи

Метод	Описание
GetLength(…)	Връща броя на елементите по дадена размерност.
GetEnumerator()	Връща имплементация на интерфейса IEnumerator за елементите на масива. Това дава възможност да се използва конструкцията foreach(…), чрез която може да се обходят всички елементи на масива. Обхождането за многомерни масиви става отляво на дясно по размерностите, т.е. най-дясното измерение се сменя най-бързо.
Reverse(…)	Статичен метод на System.Array. Обръща елементите на даден едномерен масив в обратен ред. Ако масивът не е едномерен се подава RankException.
Clear(…)	Статичен метод на System.Array. Задава стойност 0 (null за референтни типове) на елементите в зададен интервал.
Sort(…)	Статичен метод на System.Array. Сортира елементите на даден масив по големина.
BinarySearch(…)	Статичен метод на System.Array. Търси за даден елемент в даден масив чрез метода на двоичното търсене. Методът предполага, че елементите на масива се подредени по големина предварително.
IndexOf(…)	Статичен метод на System.Array. Връща индекса на първото срещане на дадена стойност в даден едномерен масив. Ако елементът не се среща в масива, връща -1. Ако масивът не е едномерен, се подава RankException.
LastIndexOf(…)	Статичен метод на System.Array. Връща индекса на последното срещане на дадена стойност в даден едномерен масив. Ако елементът не се среща в масива връща -1. Ако масивът не е едномерен се подава RankException.
CreateInstance(…)	Статичен метод на System.Array. Създава динамично (по време на изпълнение) инстанция на типа System.Array, като може да се зададе тип на елементите, брой размерности, долна граница и брой елементи за всяка размерност.
Copy(…)	Статичен метод на System.Array. Копира елементите на един масив (или част от тях) в друг масив. Този метод извършва, ако е необходимо, преобразуване на типовете на масивите.

Имплементирани интерфейси

Типът System.Array имплементира следните интерфейси: ICloneable, IList, IEnumerable и ICollection. Тези интерфейси (методите, свойствата и индексаторите, които предлагат) улесняват използването на масивите в множество и разнообразни ситуации.

Ще разгледаме малко по-подробно всеки един от имплементираните интерфейси:

- ICloneable – предоставя метод Clone(), който се използва за клониране на масив. По подразбиране масивите се копират плитко (shallow copy). Това означава, че ако копираме масив от референтни типове, елементите на новия масив ще сочат към същото място в паметта, към което са сочили съответно елементите от стария масив.

- IList – предоставя директен (пряк) достъп до елементите на масива. Типът System.Array експлицитно (явно) имплементира всеки един от методите на IList.

- IEnumerable – предоставя метода GetEnumerator(), чрез който могат да се обходят всички елементи на масива (виж таблицата с методите на класа System.Array).

- ICollection – осигурява свойството Count (размер) и средства за синхронизация на достъпа до елементите. ICollection от своя страна имплементира IEnumerable.

Създаване на ненулево-базиран масив – пример

В следващия пример ще илюстрираме как е възможно създаването на масив в .NET Framework, чиято долна граница не е 0:

using System;

class NonZeroBasedArray

{

static void Main()

{

int[] lowerBounds = { 2, 3 };

int[] lengths = { 5, 3 };

int[,] myArray = (int[,]) Array.CreateInstance(

typeof(int), lengths, lowerBounds);

myArray[3,3] = 10;

myArray[6,4] = 20;

// myArray[0,0] = 40; will throw IndexOutOfRangeException

for( int i=myArray.GetLowerBound(0); i<=myArray.GetUpperBound(0); i++ )

{

for( int j=myArray.GetLowerBound(1); j<=myArray.GetUpperBound(1); j++ )

{

Console.WriteLine("[{0},{1}]={2}", i, j, myArray[i,j]);

}

Console.WriteLine();

}

Ето резултатът от изпълнението на програмата:

В примера използваме вече разгледания статичен метод Array. CreateInstance(…), който приема като параметри типа на масива, който се създава, както и два масива от тип System.Int32 – първият с дължините на всяка размерност, а вторият – с долните граници за всяка от размерностите. Използваме още и методите GetLowerBound(…) и GetUpperBound(…), които връщат съответно долната и горната граница за дадена размерност.

За удобство върнатият от метода CreateInstance(…) обект може да се преобразува към очаквания тип. В горния пример това е типът int[,].

Странно, но факт е, че в .NET Framework това преобразуване не може да стане, ако очакваният масив е едномерен и първият елемент на масива не е 0 (CLR подава InvalidCastException). Ето един такъв пример:

int[] lowerBounds = { 2 };

int[] lengths = { 5 };

int[] arr = (int[]) Array.CreateInstance(

typeof(int), lengths, lowerBounds);

// System.InvalidCastException is thrown

Ако искаме да ползваме едномерни масиви, трябва да ползваме методите на System.Array: GetValue(…) и SetValue(…), които ни дават достъп до елементите на масива. Следният код демонстрира това:

int [] lengths = {6};

int [] bounds = {5};

Array array = Array.CreateInstance(

typeof(double), lengths, bounds);

for (int i=array.GetLowerBound(0); i<=array.GetUpperBound(0); i++)

{

array.SetValue(7, i);

}

Сортиране на масиви

За да сортираме елементите на даден масив в .NET Framework използваме статичния метод Sort(…) на типа System.Array. Алгоритъмът, чрез който се извършва сортирането, е бързото сортиране на Хоор (QuickSort), който има сложност Θ( n log(n) ) в средния случай.

Забележка: QuickSort не е "устойчив" алгоритъм за сортиране, т.е. ако два елемента са равни, не е сигурно дали тяхната подредба ще се запази. Методът Sort(…) има няколко предефиниции. Ще разгледаме по-важните от тях:

- Sort(Array) – сортира елементите на зададения едномерен масив, като очаква те да имплементират интерфейса IComparable. Той е имплементиран от много стандартни типове – Int32, Float, Double, Decimal, String, DateTime и др. Ако сме си дефинирали наш тип (клас) и искаме да сортираме масив от такива елементи, трябва имплементираме IComparable и по-точно неговия виртуален метод CompareTo(…).

- Sort(Array, IComparer) – сортира елементите на дадения едномерен масив по зададена схема за сравнение (имплементирана в интерфейса IComparer).

- Sort(Array, index, length) – сортира част от елементите на масива – в интервала [index, index + length).

- Sort(Array, Array) – сортира елементите на двата масива като използва елементите на първия масив като ключове, по които да сортира масивите.

Сортиране на масиви – пример

Със следващия пример ще покажем колко е лесно сортирането на даден масив в .NET Framework:

static void Main()

{

String[] beers = {"Загорка", "Ариана", "Шуменско", "Астика",

"Каменица", "Болярка", "Амстел"};

Console.WriteLine("Unsorted: {0}",

String.Join(", ", beers));

// Result: Unsorted: Загорка, Ариана, Шуменско,

// Астика, Каменица, Болярка, Амстел

// Elements of the array beers are of type String,

// so they implement IComparable

Array.Sort(beers);

Console.WriteLine("Sorted: {0}",

String.Join(", ", beers));

// Result: Sorted: Амстел, Ариана, Астика,

// Болярка, Загорка, Каменица, Шуменско

}

Сортиране с IComparer – пример

В следващия пример ще покажем как можем да сортираме масиви като подаваме на метода Array.Sort(…) като параметър тип, който имплементира интерфейса IComparer. За целта сме дефинирали клас Student и клас StudentAgeComparer, който имплементира IComparer и в метода си Compare(…) сравнява студентите по техните години. Забележете, че ако някой от двата обекта, които се подават като параметри на Compare(…), не е Student, подаваме ArgumentException, защото няма как да ги сравним.

using System;

using System.Collections;

class Student

{

internal string mName;

internal int mAge;

public Student(string aName, int aAge)

{

mName = aName;

mAge = aAge;

}

public override string ToString()

{

return String.Format("({0} : {1})", mName, mAge);

}

class StudentAgeComparer : IComparer

{

public int Compare(object aEl1, object aEl2)

{

Student student1 = aEl1 as Student;

if (student1 == null)

{

throw new ArgumentException(

"Argument 1 is not Student or is null");

}

Student student2 = aEl2 as Student;

if (student2 == null)

{

throw new ArgumentException(

"Argument 2 is not Student or is null");

}

return student1.mAge.CompareTo(student2.mAge);

}

class CompareStudentsDemo

{

static void Main()

{

Student[] students =

{

new Student("Бай Иван", 73),

new Student("Дядо Мраз", 644),

new Student("Баба Яга", 412),

new Student("Кака Мара", 27),

new Student("Кольо Пияндето", 32)

};

Array.Sort(students, new StudentAgeComparer());

Console.WriteLine("Students sorted by age:");

foreach (Student student in students)

{

Console.WriteLine(student);

}

Ето и изходът от примера:

Двоично търсене

Когато искаме многократно да търсим различни елементи в даден масив, е по-добре първо да го сортираме и после да използваме метода на двоичното търсене. Това е бърз метод за претърсване на вече сортиран масив. Сложността, с която претърсва масив от n елемента, е Θ( log(n) ).

В .NET Framework двоичното търсене е реализирано в статичния метод Array.BinarySearch(Array, object). Ако елементът бъде намерен, методът връща неговия индекс, а в противен случай връща отрицателно число, което е побитово отрицание на индекса на първия елемент, който е по-голям от търсения или побитово отрицание на индекса на последния елемент + 1, ако търсената стойност е по-голяма от всички елементи в масива. Методът Array.BinarySearch(…) има същите изисквания като Array.Sort(…) – или елементите на масива трябва да имплементират IComparable или трябва да се подаде инстанция на IComparer.

Двоично търсене – пример

Със следващия пример ще покажем използването на статичния метод Array.BinarySearch(…) за да претърсим масива за дадени елементи. Ще използваме и оператора за побитово отрицание ~ за да видим на коя позиция е следващия по-големина елемент, ако елементът, който търсим не бъде намерен в масива.

static void Main()

{

String[] beers = {"Загорка", "Ариана", "Шуменско", "Астика",

"Каменица", "Болярка", "Амстел"};

Array.Sort(beers);

string target = "Астика";

int index = Array.BinarySearch(beers, target);

Console.WriteLine("{0} is found at index {1}.",

target, index);

// Result: Астика is found at index 2.

target = "Мастика";

index = Array.BinarySearch(beers, target);

Console.WriteLine("{0} is not found. The next larger element is at index {1}.", target, ~index);

// Result: Мастика is not found. The next larger element is

at index 6.

}

Съвети за работа с масиви

Ето няколко съвета, които ще ви помогнат да се справите с по-често срещаните грешки, възникващи при работа с масиви:

- Когато даден метод връща масив и трябва да върнете празен масив, връщайте масив с 0 елемента, а не null. Когато използвате този метод ще очаквате да се върне масив, макар и с 0 елемента, а не стойност null, ако няма елементи.

- Не забравяйте, че масивите се предават по референция и затова ако искате да сте сигурни, че даден метод няма да промени даден масив, подавайте на метода копие от масива.

- Методът Clone() връща плитко копие на масива. Ако елементите на масива са референтни типове, трябва да реализирате собствено дълбоко клониране.

- При копиране на даден масив в друг използвайте метода Copy(…), а не Clone(). Статичният метод Copy(…) е по-удачен, защото когато е необходимо извършва съответните преобразувания (опаковане и разопаковане) на типовете на елементите на масивите. Ако масивът е от референтни типове, имайте предвид, че Copy(…) създава плитко копие на референциите.

- Не използвайте метода Array.BinarySearch(…) върху масив, който не е сортиран. Резултатите, които ще върне методът, ако масивът не е сортиран, са трудно предвидими.

- Когато е възможно използвайте само едномерни, нулево-базирани масиви. CLR е оптимизиран за работа с тях и производителността на вашето приложение ще е много по-добра.

Какво е колекция?

Колекции наричаме класовете, които съдържат в себе си съвкупност от елементи, най-често от един и същи тип. Колекциите са известни още като "контейнер класове" или "контейнери".

Колекциите могат да бъдат с фиксиран размер (такива са например масивите) или с променлив размер (такива са например свързаните списъци). Те могат да бъдат само за четене или да позволяват и промени.

Колекциите са абстрактни типове данни и могат да бъдат имплементирани по различен начин, например: чрез масив, чрез свързан списък, чрез различни видове дървета, чрез пирамида, чрез хеш-таблица и т. н.

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

Колекциите в .NET Framework

В .NET Framework класовете, имплементиращи колекции, се намират в пространството от имена System.Collections. Пример за колекция от System.Collections е типът Hashtable. Той имплементира хеш-таблици, които се характеризират с изключително бърз достъп по ключ до съдържаните елементи. Друг пример е ArrayList, който реализира масиви с променлива дължина. Използването на тези и други типове, дефинирани в System.Collections, ни позволява да прекарваме повече време, пишейки код, реализиращ същината на нашето приложение, вместо да си губим времето в опити да реализираме често срещани структури.

Списъчни и речникови колекции

Колекциите в C# са два вида – списъчни и речникови. Списъчните се характеризират с това, че имплементират интерфейсите IList и ICollection. Такива са например ArrayList, Queue, Stack, BitArray и StringCollection. Речниковите колекции имплементират интерфейса IDictionary и по-точно представляват колекция от двойки (ключ, стойност). Примери за такива колекции са класовете Hashtable, SortedList и StringDictionary.

Колекциите са слабо типизирани

Основна характеристика на всички колекции от System.Collections (с изключение на BitArray, който съдържа булеви стойности) е, че те са слабо типизирани – елементите им са от тип System.Object. Слабата типизация позволява на колекциите да съдържат фактически всякакъв тип данни, защото всеки тип данни в .NET Framework наследява System. Object. Ето един пример:

ArrayList list = new ArrayList();

list.Add("beer"); // string inherits System.Object

string s = (string) list[0];

За съжаление слабата типизация означава още, че трябва всеки път при достъп до елемент от колекцията да се прави преобразуване на типовете. Както е показано в горния пример за да се достъпи string от ArrayList е необходимо преобразуване.

При съхранение на стойностни типове в колекции се наблюдава намалена производителност, тъй като те се преобразуват в референтни и се прави "опаковане" (boxing) и при преобразуването им обратно към стойностни, съответно – "разопаковане" (unboxing).

За да се избегне преобразуването на типове, може да се използват класовете от System.Collections – CollectionBase и DictionaryBase като базови за силно типизирани потребителски колекции.

В .NET Framework 2.0 ще има типизирани колекции (базирани на т. нар. generics). Те ще наподобяват така наречените шаблони (templates) в C++ и се очаква до голяма степен да решат проблема с намалената производителност и липсата на типизация.

Интерфейсите за колекции

Всички колекции в .NET Framework имплементират един или няколко от интерфейсите IEnumerable, ICollection, IDictionary и IList. На фигурата по-долу е показана клас-диаграма, изобразяваща нагледно йерархията на тези интерфейси:

Нека първо разгледаме интерфейсите IEnumerable и ICollection и обясним за какво служат. На останалите два (IList и IDictionary) ще се спрем малко по-късно.

Интерфейсът IEnumerable

Интерфейсът IEnumerable е базов за всички типове в .NET Framework, които поддържат операцията "обхождане на всичките им елементи". Той дефинира само един метод – методът GetEnumerator(), който връща итератор (инстанция на интерфейса IEnumerator), с който се извършва самото обхождане.

Интерфейсът IEnumerator дефинира методи и свойства за извличане на текущия елемент и за преминаване към следващия (ако има такъв).

Интерфейсът ICollection

Интерфейсът ICollection е базов за всички колекции в .NET Framework. Той разширява IEnumerable и добавя към него свойството Count, което връща общия брой елементи в дадена колекция.

Списъчни колекции

Нека първо разгледаме списъчните колекции в .NET Framework, тъй като те за по-прости от речниковите и работата с тях е по-интуитивна.

Интерфейсът IList

Всеки клас, който имплементира интерфейса IList, поддържа множество от стандартни операции за работа с индексиран списък: достъп до елементите по индекс, добавяне на елемент (Add(…)), вмъкване на елемент (Insert(…)), търсене на елемент (IndexOf(…)), изтриване по индекс или по стойност (RemoveAt(…), Remove(…)) и др.

Класът ArrayList

Класът ArrayList имплементира интерфейса IList чрез масив, чийто размер се променя динамично при нужда. Всяка инстанция на този клас предварително заделя буферна памет (Capacity) за елементите, които предстои да бъдат добавени. При запълване на буферната памет се заделя нова памет, като най-често капацитетът се удвоява.

ArrayList – пример

Следният пример демонстрира работата с ArrayList и начина на употреба на най-честите операции, прилагани върху него:

static void Main()

{

ArrayList list = new ArrayList();

for (int i = 1; i <= 10; i++)

{

list.Add(i); // Adds i at the end of the ArrayList

}

list.Insert(3, 123); // Inserts 123 element number 3

list.RemoveAt(7); // Removes element with the index 7

list.Remove(2); // Removes element with value 2

list[1] = 500; // Changes element with index 1

list.Sort(); // Sorting in ascending order

int[] arr = (int[])list.ToArray(typeof(int));

foreach(int i in arr)

{

Console.Write("{0} ",i);

}

Console.WriteLine();

// Result: 1 4 5 6 8 9 10 123 500

}

В горния пример използвахме някои от методите на класа ArrayList. Използвахме конструктора по подразбиране за да създадем списъка list.

Капацитет на ArrayList

Ако предварително се знае приблизителният брой елементи, които ще се добавят в ArrayList, е препоръчително да се укаже този брой още при създаването му. Това намалява броя на операциите по промяна на размера, което значително подобрява производителността.

Преоразмеряването е бавна и неефективна операция, защото е свързана със заделяне на нова памет за елементите на масива и преместване на всички стойности от старата в новата памет.

Следващият код създава ArrayList съдържащ 100 000 цели числа:

ArrayList list = new ArrayList();

for (int i=0; i<100000; i++)

{

list.Add(i);

}

За сравнение следния код прави същото, но за два пъти по кратко време:

ArrayList list = new ArrayList(100000);

for (int i=0; i<100000; i++)

{

list.Add(i);

}

Премахване и добавяне на елементи от ArrayList

За да се премахнат елементи от ArrayList се използват методите Remove(…), RemoveAt(…), RemoveRange(…) или Clear(). Когато се премахнат елементи, останалите, които са с по-големи индекси, автоматично се изместват наляво за да заемат мястото на вече премахнатите. Примерно, ако премахнете елемент с индекс 5, елементът с индекс 6 става с индекс 5, елементът с индекс 7 става с индекс 6 и т.н.

За да се вмъкнат елементи в ArrayList се използват методите Insert(…) и InsertRange(…), като им се подава като аргумент позицията, на която се вмъкват елементите. Тъй като при вмъкване и изтриване на елемент от ArrayList се налага преместване на елементите от списъка и евентуално заделяне на памет, тези операции са бавни (работят с линейна сложност).

Както вече отбелязахме, всяка инстанция на ArrayList автоматично заделя памет за новите елементи. Тя обаче не се грижи за автоматичното освобождаване на тази памет при премахване на елементи от колекцията. За да намалите размера на ArrayList до настоящия брой елементи се използва метода TrimToSize(). Следващият пример добавя 1000 цели числа в ArrayList, изтрива първите 500 и след това намалява размера на колекцията до размера, нужен за останалите 500:

ArrayList list = new ArrayList (1000);

for (int i=0; i<1000; i++) // Add items

{

list.Add(i);

}

list.RemoveRange(0, 500); // Remove first 500 items

list.TrimToSize(); // Resize the capacity of ArrayList

Други списъчни колекции

Освен ArrayList в .NET Framework стандартно са имплементирани и някои други списъчни колекции, като опашки и стекове.

Опашка – Queue

В .NET Framework освен ArrayList са дефинирани и други списъчни структури. Една от тях е така наречената опашка – Queue. Опашката представлява колекция с поведение от вида "first-in, first-out (FIFO)" и е реализирана чрез цикличен масив. Класическа аналогия за тази структура е опашката за билети. Този, който първи се е наредил на опашката, ще може първи да си купи билет.

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

Характерни за класа Queue са двата метода Enqueue(…) и Dequeue(…), служещи съответно за добавяне и изваждане на елемент от опашката. Enqueue(…) добавя елемент в края на опашката, а Dequeue(…) изважда елемент от началото й.

Стек – Stack

Подобно на опашката стекът е друга списъчна структура от пространството System.Collections. За разлика обаче от опашката, стекът представлява структура с поведение от вида "last-in, first-out (LIFO)", която се реализира чрез масив. Той работи на принципа "който е влязъл последен в стека, стои най-отгоре" – точно като колона от чинии, поставени една върху друга.

Основните методи за добавяне и премахване на елемент от стека са Push(…) и Pop(). Push(…) добавя елемент към върха на стека, а Pop() връща елемента от върха на стека, като го премахва. Класът Stack съдържа и още метода Peek(), който връща елемента от върха на стека, но без да го премахва.

Други стандартни списъчни структури са StringCollection и BitArray. StringCollection е аналог на ArrayList, но за string обекти. BitArray, както подсказва и името му, реализира масив от булеви стойности, като съхранява всяка една от тях в 1 бит.

Queue и Stack – примери

Ето и два кратки примера за използването на стек и опашка:

Queue queue = new Queue();

queue.Enqueue("1. IBM");

queue.Enqueue("2. HP");

queue.Enqueue("3. Microsoft");

while (queue.Count > 0)

{

string computer = (string) queue.Dequeue();

Console.Write("{0} ", computer);

}

Console.WriteLine();

// Result: 1. IBM 2. HP 3. Microsoft

В следващия пример на мястото на опашка се ползва стек:

Stack stack = new Stack();

stack.Push("1. IBM");

stack.Push("2. HP");

stack.Push("3. Microsoft");

while (stack.Count > 0)

{

string computer = (string) stack.Pop();

Console.Write("{0} ", computer);

}

Console.WriteLine();

// Result: 3. Microsoft 2. HP 1. IBM

Речникови колекции

Нека сега разгледаме и по-сложната част от средствата за работа с колекции в .NET Framework – речниковите колекции.

Интерфейсът IDictionary

Интерфейсът IDictionary е базов за речниковите колекции. Всеки техен елемент представлява двойка от тип ключ-стойност, която се съхранява в обект от тип DictionaryEntry. Ключът на всяка двойка трябва да е уникален и различен от null, а стойността, асоциирана с този ключ, може да е какъвто и да е обект, включително null. Интерфейсът IDictionary позволява съдържаните в колекцията ключове да се изброяват, но не ги сортира по какъвто и да е признак.

IDictionary поддържа операциите добавяне на нова двойка ключ-стойност (Add(…)), търсене на стойност по ключ (индексатор), премахване на двойка по ключ (Remove(…)), извличане на всички ключове (Keys), извличане на всички стойности (Values).

Имплементациите на IDictionary биват няколко вида: само за четене (read-only), с фиксиран размер и с променлив размер. При колекциите, които са само за четене, не се позволява промяна на елементите им. При имплементация с фиксиран размер не се позволява добавяне и премахване на елементи, но е позволена промяната на вече съществуващи елементи. При имплементация със променлив размер е позволено добавяне, премахване и промяна на елементи.

Класът Hashtable

Hashtable представлява имплементация на структурата от данни "хеш таблица" – речникова колекция, елементите на която се разполагат в специално заделена памет в зависимост от хеш кода на ключа на всяка от тях. Имплементацията на класа е направена така, че да позволява добавянето на елемент и търсенето по ключ да стават с константна сложност в средния случай. Тъй като класът имплементира IDictionary, това означава, че всеки ключ трябва да е уникален и различен от null.

Обектите, които се използват за ключове в хеш-таблица, трябва да имплементират или наследяват методите GetHashCode() и Equals(…). Структурата от данни "хеш-таблица" не може да работи без функция за пресмятане на хеш-код за съхраняваните ключове и без функция за сравнение на ключове. При това ключовете, които се считат за еднакви, задължително трябва да имат еднакъв хеш-код.

Тъй като всеки клас наследява System.Object, то той автоматично наследява и предефинирана имплементация на Equals(…). За съжаление, в общия случай тази имплементация се реализира чрез сравнение за съвпадение на референциите на двата обекта. Това генерално погледнато е грешен начин за сравнение и затова се налага да се имплементират специфични реализации за създадените от нас класове. Имплементацията на Equals(…) трябва да връща винаги един и същ резултат, когато се вика с едни и същи параметри.

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

Класът Hashtable имплементира интерфейса IDictionary, а той от своя страна наследява IEnumerable. Това ни позволява свободата да използваме оператора foreach за да обхождаме елементите на хеш-таблици.

Hashtable – пример

Ето един пример, който демонстрира работата с класа Hashtable и показва как се използват основните операции, свързани с него:

static void Main()

{

Hashtable priceTable = new Hashtable();

priceTable.Add("BMW", 66000);

priceTable.Add("Ferrari", 200000);

priceTable.Add("Ford", 50000);

priceTable.Add("Audi", 80000);

Console.WriteLine("Car \"{0}\", price ${1}",

"Ferrari", priceTable["Ferrari"]);

priceTable.Remove("Ferrari");

priceTable["Audi"] = 88000;

foreach(DictionaryEntry carPrice in priceTable)

{

Console.WriteLine("Car \"{0}\", price ${1}",

carPrice.Key, carPrice.Value);

}

В примера се използва хеш-таблица за съхранение на съответствия между модели леки автомобили и техните цени. След изпълнението му се получава следният резултат:

Примерът демонстрира добавяне, извличане, изтриване и промяна на елементи в хеш-таблица, както и обхождане на всички елементи с foreach.

Производителност на Hashtable

Два фактора оказват влияние върху производителността на хеш-таблиците: техният размер и уникалността на хеш-кодовете, които се съпоставят на ключовете.

Влияние на колизиите върху производителността

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

Размерът на една хеш-таблица автоматично нараства при запълване до определен процент в резултат от добавяне на нови елементи, с което свежда до минимум вероятността да се получат колизии.

Влияние на размера на хеш-таблицата върху производителността

Операциите, предизвикващи увеличаване на размера на една хеш-таблица, са скъпи, защото предизвикват заделяне на нова памет, ново пресмятане на индексите за елементите и копиране на всеки елемент на нова позиция в таблицата. По подразбиране хеш-таблицата се конструира с размер 0. Това означава, че са необходими много операции по заделяне на памет докато се достигне подходящ размер.

Ако предварително знаете приблизително колко елемента ще добавите в хеш-таблицата, задавайте началния й размер като параметър на конструктора. Ето пример за инициализиране на хеш-таблица, която е оптимизирана за 1000 елемента:

Hashtable table = new Hashtable(1000);

Инициализирайки по такъв начин размера на хеш-таблицата, ние не указваме влияние върху производителността на търсещите операции, но можем да подобрим бързодействието на добавянето на нов елемент до няколко пъти.

Фактор на нарастване

Когато една хеш-таблица в .NET Framework нараства, тя винаги приема размер, който е просто число. (Причината за това се дължи на факта, че статистически е по-вероятно, ако n е произволно число, n % m да бъде уникален резултат, когато m е просто). По подразбиране хеш-таблицата увеличава размера си, когато броят на елементите й надвиши даден процент от размера й. Този процент може да се контролира като се променя факторът на нарастване. Фактор на нарастване 1.0 отговаря на 72%, 0.9 отговаря на 65% (0.9*72) и т.н. Валидните фактори на нарастване варират от 0.1 до 1.0.

Ето пример как да инициализираме хеш-таблица за 1000 елемента и да й зададем фактор на нарастване 0.8, което означава че таблицата ще нараства и ще се реиндексира когато броят на елементите й достигне приблизително 58% от размера й:

Hashtable table = new Hashtable (1000, 0.8f);

Факторът на нарастване по подразбиране е 1.0 и в повечето случаи не е нужно да се променя.

Увеличаване на уникалността на хеш-кодовете

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

По подразбиране хеш-таблиците хешират ключовете, като викат техния метод GetHashCode(), който всеки обект е наследил от System.Object. Ако използваме за ключове обекти от клас, чийто метод GetHashCode() не генерира достатъчно уникални хеш-кодове, можем да направим едно от следните неща за да подобрим производителността:

- Да припокрием метода GetHashCode() в производния клас и да осигурим имплементация, която генерира възможно по-уникални хеш-кодове.

- Да създадем тип, който имплементира IHashCodeProvider и да подадем референция към обект от този тип на конструктора на хеш-таблицата. Това ще предизвика извикване на метода IHashCodeProvider.GetHashCode() за генериране на хеш-код.

Собствени хеш-функции

Когато използваме собствени класове за ключове в хеш-таблица, те трябва да припокрият методите GetHashCode() и Equals(…) наследени от System.Object.

Собствени хеш-функции – пример

В следващият пример ще демонстрираме как можем да използваме собствен клас за ключ в хеш таблица, като дефинираме по подходящ начин в него виртуалните методи GetHashCode() и Equals(…):

class Student

{

protected string mName;

protected int mAge;

public Student(string aName, int aAge)

{

mName = aName;

mAge = aAge;

}

public override string ToString()

{

return String.Format("({0}, {1})", mName, mAge);

}

public override bool Equals(object aStudent)

{

if ((aStudent==null) || !(aStudent is Student))

return false;

Student student = (Student) aStudent;

bool equals = (mName == student.mName) &&

(mAge == student.mAge);

return equals;

}

public override int GetHashCode()

{

int hashCode = mName.GetHashCode() ^ mAge;

return hashCode;

}

class CustomHashCodesDemo

{

private static Hashtable mAddressTable;

static void PrintAddress(Student aStudent)

{

if (mAddressTable.ContainsKey(aStudent))

{

Console.WriteLine("{0} has address: {1}.",

aStudent, mAddressTable[aStudent]);

}

else

{

Console.Write("There is no address for {0}.", aStudent);

}

static void Main()

{

Student john = new Student("Sir John", 23);

Student ann = new Student("Lady Ann", 22);

Student richard = new Student("King Richard", 33);

mAddressTable = new Hashtable();

mAddressTable.Add(john, "Nottigham Castle");

mAddressTable.Add(ann, "London Tower");

mAddressTable.Add(richard, "London Castle");

PrintAddress(john);

PrintAddress(new Student("Lady Ann", 22));

PrintAddress(new Student("Lady Ann", 24));

}

// Result:

// (Sir John, 23) has address: Nottigham Castle.

// (Lady Ann, 22) has address: London Tower.

// There is no address for (Lady Ann, 24).

В примера се използва класът Student като ключ в хеш-таблица, която съхранява съответствия между студенти и техните адреси. Ако в класа Student нямаме имплементация на методите Equals(…) и GetHashCode(), нашата хеш-таблица няма да работи коректно с ключове от тип Student.

Много често наш, собствен тип се състои от няколко различни полета, от които може да зависи хеш-кода на отделен обект от дадения тип. Един възможен начин за генериране на хеш код в такива ситуации е да се обединят хеш-кодовете на различните полета като се използва операцията ^ (изключващо или). Точно така се реализира генерирането на хеш код и в примера по-горе.

Изчисляването на хеш-кода за даден студент става като изчислим хеш-кода за неговото име и извършим операцията "изключващо или" с неговите години. По този начин се стремим да получаваме възможно по-уникални стойности за хеш-кодовете. При еднакви имена или еднакви години най-често стойностите ще са различни. Ако имената и годините на двама студента едновременно съвпадат, ще получим еднакви хеш-стойности (което е едно от важните изисквания при имплементацията на метода GetHashCode()).

Equals(…) е имплементиран така, че да връща винаги false за различни инстанции на обекти от тип Student и true за еднакви.

Класът SortedList

Речниковите колекции могат да бъдат реализирани не само в хеш-таблици, но и по други начин. Класът SortedList, например, представлява имплементация на интерфейса IDictionary, която прилича както на хеш-таблица, така и на масив. Тази колекция съхранява двойки елементи ключ-стойност, сортирани по ключ, като позволява индексиран достъп. Тъй като е нужна непрекъсната поддръжка на сортирана последователност, SortedList работи доста бавно (повечето операции имат линейна сложност).

SortedList – пример

Ето един пример, който илюстрира работата със SortedList:

SortedList sl = new SortedList();

sl.Add("BMW", 66000);

sl.Add("Ferrari", 200000);

sl.Add("Audi", 80000);

sl.Add("Ford", 50000);

sl.Remove("BMW");

sl["Audi"] = 88000;

Console.WriteLine("We sell only:");

foreach (string car in sl.GetKeyList())

{

Console.WriteLine("{0} ", car);

}

Console.WriteLine("\nThe prices are as follows:");

for (int i = 0; i < sl.Count; i++)

{

Console.WriteLine("{0} - ${1}",

sl.GetKey(i), sl.GetByIndex(i));

}

В него класът SortedList е използван за да съхранява съответствия между модели леки автомобили и техните цени. Понеже за ключ се използват моделите на автомобилите, след добавянето на няколко автомобила в сортирания списък, те могат да бъдат извлечени след това в азбучен ред чрез просто обхождане.

След изпълнение примерът извежда на конзолата следното:

Силно типизирани колекции

.NET Framework поддържа и силно типизирани колекции. Пространството от имена, което съдържа класовете за работа с тях е System.Collections. Specialized. Пример за силно типизирана колекция е StringDictionary. Това е клас, който работи точно като Hashtable, но използва само string за ключове и стойности. При използване на този клас няма нужда от преобразуване на типа към string при извличане на стойност от хеш-таблицата:

StringDictionary addresses = new StringDictionary();

addresses["доктор Иванов"] = "с. Гинци, на площада";

addresses["бат Сали"] = "гр. София, кв. Факултета";

Console.WriteLine("{0} живее в {1}",

"доктор Иванов", addresses["доктор Иванов"]);

Специални колекции

.NET Framework поддържа и някои специални колекции, които приличат на вече разгледаните, но имат малко по-различно предназначение. Пример за специален тип колекция е хеш-таблица от низове, която не различава главни от малки букви в ключа на елементите. В .NET Framework такава колекция можем да получим чрез метода CreateCaseInsensitiveHashtable() на класа CollectionsUtil:

Hashtable addresses =

CollectionsUtil.CreateCaseInsensitiveHashtable();

addresses["бай Иван"] = "с. Мугла";

Console.WriteLine("{0} живее в {1}",

"БАЙ ИВАН", addresses["БАЙ ИВАН"]);

Упражнения

1. Напишете програма, която прочита от конзолата N цели числа, записва ги в масив и отпечатва тяхната сума и средното им аритметично.

2. Напишете програма, която прочита от конзолата масив от числа и намира в него най-дългата поредица от числа, такива че всяко следващо да е по-голямо от предходното.

3. Напишете програма, която прочита от конзолата масив от N числа и намира в него поредица от точно K числа (1<K<N) с максимална сума.

4. Напишете клас Matrix, който съдържа матрица от реални числа, представена чрез двумерен масив. Дефинирайте оператори за събиране, изваждане и умножение на матрици, методи за достъп до съдържанието и метод за отпечатване.

5. Напишете програма, която прочита от конзолата масив от N цели числа и цяло число K, сортира масива и чрез метода Array.BinSearch(…) намира най-голямото число от масива ≤ K и най-малкото число от масива ≥ K. Да се отпечата сортирания масив, с отбелязани в него търсените две числа.

6. Даден е масив от N цели числа, за който знаем, че един от елементите му (т. нар. мажорант) се среща на поне 1 + N/2 различни позиции. Да се напише програма, която с помощта на класа Stack намира мажоранта на масива. Например ако имаме масива {3, 2, 2, 3, 2, 1, 3, 2, 2, 2, 1}, неговият мажорант е 2. Ако се затруднявате, помислете дали не можете да обходите елементите и всеки от тях или да го добавяте в стека, ако съвпада с елемента на върха му, или в противен случай да премахвате елемента от върха на стека.

7. Даден е масив от символни низове. Да се напише метод, който намира всички низове от масива, които имат четна дължина. Методът трябва да връща масив от символни низове и трябва вътрешно да използва класа StringCollection.

8. Даден е масив от символни низове. Да се напише програма, която отпечатва всички различни низове от масива и за всеки от тях колко пъти се среща. Низовете в резултата трябва да са подредени по брой срещания в низходящ ред. Препоръчва се използване на хеш-таблица с ключове низовете и стойности брой срещания. За сортирането може да се използва Array.Sort(…).

9. Даден е речник, който представлява масив от двойки стойности – дума и значение. Да се напише програма, която превежда поредица от думи. Има ли смисъл да се ползва хеш-таблица?

10. Да се напише клас ComplexNumber, който представлява комплексно число с реална и имагинерна част от тип double. Да се напише метод, който приема като параметър масив от комплексни числа и връща като резултат комплексното число, което се среща най-голям брой пъти в този масив. За целта да се използва хеш-таблица, в която за всяко комплексно число се пази броят на срещанията му. Не забравяйте да реализирате предварително по подходящ начин методите Equals(…) и GetHashCode() на класа ComplexNumber.

Използвана литература

1. Светлин Наков, Масиви и колекции – http://www.nakov.com/dotnet/ lectures/Lecture-7-Arrays-and-Collections-v1.0.ppt

2. MSDN Training, Programming with the Microsoft® .NET Framework (MOC 2349B), Module 7: Strings, Arrays, and Collections

3. Jeff Prosise, Programming Microsoft .NET Microsoft Press, 2002, ISBN 0735613761

4. Jeffrey Richter, Applied Microsoft .NET Framework Programming, Microsoft Press, 2002, ISBN 0735614229

5. Joel Fugazzotto, C# Complete, Sybex Inc., ISBN 0782142036

6. MSDN Library – http://msdn.microsoft.com

Глава 9. Символни низове
(Strings)

Необходими знания

- Базови познания за общата система от типове в .NET Framework

- Базови познания за езика C#

Съдържание

- Стандартът Unicode

- Типът System.Char

- Символни низове. Класът System.String

- Escaping последователности

- Ефективно конструиране на низове чрез класа StringBuilder

- Форматиращи низове

- Класът StringInfo

- Интернационализация и култури

- Парсване на числа и дати

- Кодиращи схеми и конвертиране. Класът System.Text.Encoding

- Кодиране Base64

- Работа с Unicode във Visual Studio .NET

В тази тема ...

В тази тема ще се запознаем с начина на представяне на низовете в .NET Framework и с методите за работа с тях. Ще разгледаме какви кодиращи схеми се използват при съхраняване и пренос на текстова информация и как се решава въпросът с подредбата на байтовете. Ще се спрем подробно на различните начини за манипулиране на низове, предоставени ни от FCL, както и на някои практически съображения при работа с класовете, според решаваната задача. Ще видим как настройките за държава и култура определят вида на текста, показван на потребителите, и как можем да форматираме изхода в четлив и приемлив вид. Ще се запознаем също и с начините за преобразуване на вход от потребителя от текст в обект от стандартен тип, с който можем лесно да работим.

Стандартът Unicode

Стандартът Unicode играе много съществена роля при работата с текст в повечето съвременни софтуерни платформи. Неговата история е дълга и интересна. Той възниква в резултат от усилията за създаване на единна система за представяне на всички азбуки и езици и се налага все повече като универсално средство за представяне на текстова информация.

Преди да се запознаем със средствата на .NET Framework за работа със символни низове и текст, ще разгледаме Unicode стандарта, тъй като низовете в .NET Framework вътрешно са базирани на този стандарт.

В началото бе ASCII

В началните години от развитието си компютърната техника е съсредоточена в Северна Америка. Софтуерът по това време е бил създаван за ползване предимно в англоезични среди. Текстовите данни са били представяни чрез ASCII или EBCDIC символи. За един такъв символ е нужен 1 байт памет: за кодирането на ASCII символ - 7 бита, а за EBCDIC – 8 бита.

Постепенно в останалата част на света се разработват други системи за съхраняване на символи. В Япония това са JIS символите, за руския език се налага KOI8 стандартът, а индийските езици се представят с няколко ISCII стандарта. Изброените стандарти дефинират кодови таблици с двоично представяне на буквите, цифрите и някои други символи.

Ето как изглежда кодовата таблица, дефинирана от стандарта ASCII (American Standard Code for Information Interchange):

00-25

26-51

52-77

78-103

104-127

NUL

SOH

STX

ETX

EOT

ENQ

ACK

BEL

DLE

DC1

DC2

DC3

DC4

NAK

SYN

ETB

CAN

SUB

ESC

(

)

;

[

]

{

}

DEL

ASCII дефинира 127 символа и представя всеки от тях със 7-битово число. Тези символите включват латинските букви, цифрите, някои често използвани знаци и някои служебни символи със специално предназначение. Тъй като ASCII е бил въведен преди много време, част от специалните символи за загубили значението си.

Unicode

Unicode е проект, който има за цел да замести съществуващите символни кодови таблици. Голяма част от тях не са всеобщо приети, което създава проблеми при пренос на данни между различни среди и платформи. Въпреки техническите трудности и мащабността на проекта, Unicode се е наложил като стандарт при интернационализацията на софтуера. Той съдържа изключително богат набор от символни дефиниции. Unicode е приет и като основа за представяне на текст в много операционни системи, платформи и стандарти (XML, Java, .NET Framework и др.).

Символите в Unicode

Unicode е стандарт, предоставящ уникален номер за всеки един знак (букви, йероглифи, математически символи и др.) с цел универсалност при съхраняването им в цифров вид при различни операционни системи и езикови среди.

Версия 4.0 на Unicode стандарта дефинира близо 100 000 символа и може да поддържа над 1 милион различни знака (чрез комбинация от символи).

Стандартът Unicode се развива постоянно под контрола на Unicode консорциума (www.unicode.org) – добавят се нови символи, утвърждават се нови спецификации и т. н.

Обикновено Unicode символите се записват с "U+" и съответния номер в шестнайсетичен вид.

Например символът "листо" на традиционен китайски се записва като U+8449. Това съответства на десетичния номер 33865. За да представим този символ в сорс код на C# трябва да използваме шестнайсетичния номер и да укажем, че това е Unicode символ, чрез записа "\u8449". Същият символ в езика HTML се записва като 葉 или 葉.

Да разгледаме още един пример за Unicode символ – музикалният знак "нота шестнайсетина". Стандартно този символ се записва в Unicode като U+1D161, което съответства на десетичния номер 119137. В HTML можем отново да използваме два записа, съответстващи на шестнайсетичния и десетичния номер 𝅘𝅥𝅯 и 𝅘𝅥𝅯. При записа на този символ в сорс код на C# се използва т. нар. кодова двойка и символът се изписва като последователност от две шестнайсетични числа – "\uD834\uDD61".

Употребата на кодови двойки е необходима при символи, чиито Unicode номера не могат да бъдат кодирани само с 16 бита. Обърнете внимание, че Unicode поддържа над 500 000 символа, а в 16 бита могат да се запишат само 65536 различни стойности.

Кодови двойки

За да получим кодовата двойка, съответстваща на даден символ, трябва от шестнайсетичния му Unicode номер да извадим 0x10000, след което да преобразуваме получената стойност в двоично число и да я разделим на две части – водещите 6 бита и останалите 10 бита. Първите 6 бита, отново превръщаме в шестнайсетично число и към тях прибавяме специалния Unicode номер U+D800. Подобна е процедурата и с вторите 10 бита, но там прибавяме U+DC00. Извършването на тази операция върху символа нота шестнайсетина е илюстрирано на следната фигура:

Познавайки тези правила, лесно можем да определим дали дадена шестнайсетична стойност съответства на Unicode номер или е част от кодова двойка, както и да съобразим коя част от кодовата двойка представлява.

Като правило по-често използваните знаци в Unicode стандарта се представят с една шестнайсетбитова стойност, а останалите – с кодови двойки.

Графични знаци (графеми)

Графеми се наричат всички графични знаци от писмеността на различните езици, използвани в човешката цивилизация – букви, цифри, идеограми, пунктуационни знаци, математически символи и т. н.

Не всички графеми имат свой уникален номер в Unicode стандарта, защото някои графеми могат да се представят като комбинация от няколко други. Това е направено с цел да се намали общият брой на Unicode символите.

Например графемата А се представя с Unicode номер U+0041, но Ạ (А с точка отдолу) се представя с последователността U+0041, U+0323 от Unicode номера. Това се дължи на факта, че в Unicode има някои символи, които не представляват самостоятелни знаци, а допълват други символи. Такива са например ударенията, горната подчертаваща чертичка, долната подчертаваща чертичка и др.

По-нататък, в секцията "Кодиращи схеми", ще разгледаме подробно кодиращите схеми, поддържани в .NET Framework, както и по какъв начин се представя текстовата информацията в паметта.

Типът System.Char

Типът System.Char в .NET Framework е стойностен тип и позволява съхранението на една 16-битова Unicode стойност. В езика C# примитивният тип char е еквивалентен на типа System.Char.

В повечето случаи един символ може да се представи с една инстанция на типа char, но това не винаги е така. В .NET Framework символите с Unicode номер, по-голям от 65536, се представят като последователност от две инстанции на System.Char.

Методи за класификация на символите

Типът System.Char притежава статичен метод GetUnicodeCategory(…), който връща информация за съответния знак (дали е малка буква, главна буква, символ за валута, математически символ и т.н.). Останалите методи, служещи за класифицирането на символите, са дадени в таблицата:

Метод	Описание
IsLetter()	Проверка дали знакът е буква (letter). Букви са не само латинските A..Z, но и буквите от други азбуки, като например "Ъ", "Σ" и "ẅ".
IsDigit()	Връща true ако знакът е цифра.
IsWhiteSpace()	Връща true ако знакът е за празно място (интервал, табулация, символ за нов ред и др.).

Методите IsLetter(), IsDigit(), IsSeparator() и IsWhiteSpace() връщат са реализирани чрез вътрешно извикване на GetUnicodeCategory().

Методи за смяна на регистъра

Конвертирането на знак към главни или малки букви става чрез извикване на статичните методи Char.ToUpper() и Char.ToLower(). Резултатът от извикването на двата метода зависи от информацията за културата. Тя може да бъде подадена като параметър, а по подразбиране се използва текущата. Ролята на културата ще бъде дискутирана малко по-нататък.

Символни низове в .NET Framework

В .NET Framework символните низове (strings) представляват последователност от Unicode знаци, записани в кодиране UTF-16. Това позволява на програмистите с лекота да използват в своите приложения едновременно различни езици.

За символните низове в .NET се използва системният тип System.String. Той представлява неизменима (immutable) последователност от символи (инстанции на System.Char).

Както всички типове в .NET Framework, така и System.String е наследник на System.Object. Типът System.String е референтен и неговите инстанции се съхраняват в динамичната памет. Той е обезопасен за многонишково изпълнение.

В езика C# типът System.String може да се изписва съкратено чрез неговия псевдоним, запазената дума string:

string s = "Няма бира!";

Поради причини, свързани с производителността, архитектите на .NET Framework са интегрирали символните низове тясно с CLR.

Веднъж създадени инстанциите на типа String не могат повече да бъдат променяни. При нужда от промяна на символни низове в хода на програмата, тази особеност може да доведе до намалена производителност. За справяне с този проблем при динамична обработка на символни низове се използва класът System.Text.StringBuilder, на който ще се спрем малко по-късно.

Символните низове и паметта

При работа с методи, които модифицират символните низове, ние не променяме самия символен низ, а създаваме нов, в който биват отразени промените.

Нека да разгледаме следния примерен код, който демонстрира работата със символни низове:

static void Main()

{

string s = "Няма бира!";

string s2 = s;

s = "Докараха бира!";

s += " ... и трезви няма.";

Console.WriteLine("s = {0}", s);

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

}

В началото дефинираме променлива s от референтния тип System.String, като едновременно с това й задаваме стойност "Няма бира!":

string s = "Няма бира!";

В този случай s е указател (референция), който сочи към определено място в динамичната памет, където е записана стойността "Няма бира!".

На следващия ред създаваме втори символен низ, който инициализираме със стойността на първия:

string s2 = s;

В този случай вече имаме два указателя (s и s2), които сочат към едно и също място в паметта:

При третото действие задаваме нова стойност за s, при което се създава нов обект в динамичната памет:

s = "Докараха бира!";

След изпълнението на този ред s съдържа указател, който сочи към друго място в паметта, защото стойността е променена:

Следва долепване на низа " ... и трезви няма." към стойността на низа s:

s += " ... и трезви няма.";

Понеже низовете в .NET Framework са неизменими, тази операция създава нов обект в динамичната памет и записва в него резултата от долепването. Старата стойност на s остава в динамичната памет като нерефериран от никого обект, който ще бъде освободен при следващото почистване на паметта:

Класът System.String

Класът System.String е основополагащ за работата със символни низове в .NET Framework. Нека се запознаем в детайли с по-важните методи и свойства на System.String.

Правила за сравнение на символни низове

Методите и свойствата на класа System.String могат да бъдат разделени на числени и лексикографски. Числените методи, изпълнявани върху символен низ, действат върху индекса (поредния номер в низа) на всеки знак. Лексикографските операции действат върху стойността на низа, съобразно избраната култура, форматиране и правила за парсване.

Много от числените и лексикографските операции се базират на правилата за сортиране. .NET Framework подържа правила за сортиране по дума, низ и последователност на Unicode символите.

Сортирането на думи (word sorting) е чувствително към културата лексикографско сравнение на низове. На Unicode символите, които не са букви или цифри, се приписва определена стойност – тегло. Например символът тире "-" може да има нулево тегло, така че низовете "coop" и "co-op" да бъдат равни. Така два низа могат да бъдат логически равни, дори и знаковите им последователности да не са еднакви. Например ако използваме немска култура, низовете "Straße" и "Strasse" ще са еквивалентни.

Сортирането на низове (string sorting) по същество е същото като сортирането по думи, с изключение на факта, че всички небуквени и нецифрени символи предхождат всички останали.

При сортирането по последователност на Unicode символите (ordinal sorting) два низа се сравняват по числената стойност (поредния номер в Unicode стандарта) на всеки символ в низа.

Процедурите за сравнение и процедурите за търсене в низове по подразбиране са чувствителни към главни и малки букви. Те използват културата, асоциирана към текущата нишка, освен ако изрично не е указана друга. По дефиниция всеки символен низ, включително и празният (""), е по-голям от стойността null. При сравнение на две стойности null, те се считат за равни.

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

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

Методи и свойства на System.String

По-важните свойства на класа за работа с низове са Length, което връща броя на символите в инстанцията на низа, и Chars[int], което връща символа на зададена позиция в низа. В C# вместо свойството Chars[int] се използва за индексатор на низа this[int], който също връща символа на зададената позиция.

Индексирането на символите в низовете в .NET Framework започва от 0. Първият символ в даден низ s се намира на позиция 0, а последният – на позиция s.Length-1.

Методи за сравнение на низове

За сравнение на низове се използва методът Compare(…), който е предефиниран с различни по брой и/или тип параметри. При Compare(…) сравнението на низовете е лексикографско, като се взима предвид текущата културата. Като параметър може да бъде зададена специфична култура или инвариантност спрямо културата. Ако целта на сравнението е да бъдат сортирани низове, то трябва да укажем да се прави разлика между малки и главни букви. В противен случай два низа, съдържащи съответно малка и главна буква, се считат за равни и при всяко изпълнение на програмата низовете могат да бъдат сортирани в различен ред.

За разлика от метода Compare(…), статичният метод CompareOrdinal(…) не отчита културата. При него се сравняват само Unicode стойностите и той връща равенство, ако двата низа съдържат една и съща последователност от знаци. Тъй като малките и главните букви имат различни Unicode стойности, то CompareOrdinal(…) е чувствителен към разлика в низовете, дължаща се на малки и главни букви.

Методите Compare(…) и CompareOrdinal(…) връщат положително, отрицателно число или 0 в зависимост дали първият аргумент е съответно по-голям, по-малък или равен на втория. Ето един пример, който илюстрира лексикографско сравнение на низове:

string s1 = ".NET Framework";

string s2 = ".NET Platform";

int compareResult = String.Compare(s1, s2);

Console.WriteLine(compareResult); // Prints -1

В примера не е указано какво култура да бъде използвана, заради което се подразбира текущата.

Друг метод за сравнение на низове е Equals(…). Преди да извърши сравнението на два низа чрез вътрешно извикване на методът CompareOrdinal(…), този метод проверява референциите на двата низа. Ако референциите сочат към един и същ обект в паметта, Equals(…) връща true без да прави по-нататъшна проверка. Това прави методът изключително бърз при използване на интерниране на низове, с което ще се запознаем по-късно.

Методът Equals(…) може да бъде извикван с различен тип и брой параметри. Той приема един или два параметъра, които могат да бъдат низове, произволен обект или инстанция на класа StringBuilder (който ще разгледаме след малко).

Освен методите за сравнение на низове се използват и операторите == и !=. Двата оператора са имплементирани на базата на метода Equals(…) на System.String и са чувствителни към малки и главни букви.

Търсене на съвпадения в началото и в края

StartsWith(…) и EndsWith(…) са методи, които проверяват дали дадената инстанция на класа String започва или завършва със зададения като параметър низ. StartsWith(…) връща true, ако зададеният низ се среща в началото на инстанцията или ако сме задали празен низ, и false в противен случай. EndsWith(…) връща true, ако инстанцията на обекта от класа System.String завършва със зададения като параметър низ или ако сме задали празен низ. За целта методът сравнява параметъра с подниз, извлечен от края на текущата инстанция със същата дължина, като параметъра. И двата метода извършват търсене на дума (word search), използвайки текущата култура и са чувствителни към малки и главни букви.

Работа с низове – прост пример

Следният примерен код илюстрира индексиране на низ, слепване на низове и сравняване на низове с оператор, както и метода StartsWith(…):

static void Main()

{

string s = "Няма бира!";

for (int i=0; i<s.Length; i++)

{

Console.WriteLine("s[{0}] = {1}", i, s[i]);

}

string s2 = "Няма " + "бира!";

if (s == s2) // true

{

// Both strings have equal values

Console.WriteLine("s == s2");

}

if (s.StartsWith("Няма")) // true

{

Console.WriteLine("Няма, но ще докарат!");

}

Ето резултата от изпълнението на примера:

Извличане на подниз

За извличане на подниз в класа System.String е предвиден метод Substring(…). Той може да бъде извикан с един или два параметъра от тип Int32, които задават съответно началото и дължината на подниза. Ако подаденият начален индекс е равен на дължината на низа и вторият параметър е 0 или липсва, то върнатият подниз ще е празен. Ако параметърът, указващ началото, е по-малък от 0 или по-голям от дължината на низа, се получава изключение ArgumentOutOfRangeException. Това изключение ще получим и ако подадената дължина е по-голяма от дължината на низа. Отново ще напомним, че индексирането на символите в низа започва от 0.

Търсене в низ

Методът IndexOf(…) връща позицията на първото срещане на посочения като параметър низ в текущия низ. Ако низът не бъде открит, върнатата стойност е -1. Този метод също е предефиниран по сигнатура и може да приеме като параметър String или Char обект за търсене. Може да бъде зададена и специфична област от низа, в която да се търси зададения подниз или символ. Сравнението при търсене на подниза е чувствително към малки и главни букви, но е нечувствително към културата.

Аналогично методът LastIndexOf(…) връща позицията на последното срещане на зададения низ в низовия обект или -1 ако няма съвпадение.

Търсене в низове – пример

За да илюстрираме търсенето в низове, ще дадем за пример следния код, показващ действието на методите Substring(…) и IndexOf(…):

string s = "Няма бира!";

string beer = s.Substring(5, 4); // beer = "бира"

Console.WriteLine(

"\"{0}\".Substring(5,4) is \"{1}\".", s, beer);

// Result: "Няма бира!".Substring(5,4) is "бира".

int beerIndex = s.IndexOf("бира"); // 5

Console.WriteLine(

"The index of \"{0}\" in \"{1}\" is {2}.",

"бира", s, beerIndex);

// Result: The index of "бира" in "Няма бира!" is 5.

int vodkaIndex = s.IndexOf("водка"); // -1

Console.WriteLine(

"The index of \"{0}\" in \"{1}\" is {2}.",

"водка", s, vodkaIndex);

// Result: The index of "водка" in "Няма бира!" is -1.

Разделяне и слепване на низове

За разделяне и слепване на низове в класа System.String са предвидени няколко метода. Методът Split(…) разделя низовия обект на множество от поднизове по зададен като параметър масив от разделителни символи. Поднизовете се връщат в масив от низове (string[]).

Методът Join(…) на класа String служи за слепване на низове. При зададен разделител и масив от низове, той създава един обединен низ, като между елементите от масива постави разделителя.

Допълнителни ресурси при визуализация на низове

При визуализиране на низове в .NET често се използва методът Format(…). Той замества всеки форматиращ идентификатор в низа със стойностите на посочените обекти. Има възможност за поставяне на няколко форматиращи идентификатора, както и задаване на специфична култура за визуализацията на стойностите. На форматиращите низове ще се спрем в детайли след малко.

За подравняване на низове при визуализация се използват методите PadLeft(…) и PadRight(…). PadLeft(…) подравнява низа като отляво оставя посочения брой празни места или друг зададен Unicode символ. Аналогично PadRight(…) визуализира низа като оставя отдясно зададен брой празни места или зададения символ.

Разделяне, слепване и визуализация на низове - пример

След като се запознахме с методите Split(…), Join(…) и Format(…) ще използваме следния пример, за да демонстрираме работата с тях:

string wisdom = "Петър плет плете, през три пръта " +

"преплита. Подпри, Петре, плета!";

string[] words = wisdom.Split(' ', ',', '.', '!');

foreach (string w in words)

{

if (w != "")

{

Console.Write("{0} ", w);

}

Console.WriteLine();

// Result: Петър плет плете през три пръта преплита Подпри Петре плета

string[] drinks = {"бира", "ракия", "вино", "водка"};

string wordsList = String.Join(", ", drinks);

Console.WriteLine("Остана само: {0}.", wordsList);

// Result: Остана само: бира, ракия, вино, водка.

string nonsense = String.Format(

"Доказано е, че {0} + {1} = {2}, но само при " +

"достатъчно големи стойности на {3}.", 2, 2, 5, 2);

Console.WriteLine(nonsense);

// Result: Доказано е, че 2 + 2 = 5, но само при достатъчно големи стойности на 2.

string formattedDate = String.Format(

"Днес е {0:d.MM.yyyy} г.", DateTime.Now);

Console.WriteLine(formattedDate);

// Result: Днес е 2.08.2004 г.

const int SIZE = 15;

string formattedName = "Бай Иван".PadLeft(SIZE, ' ');

string formattedSum = "131.7 лв.".PadLeft(SIZE, '0');

Console.WriteLine("Вашето име : {0}", formattedName);

Console.WriteLine("Вие дължите: {0}", formattedSum);

// Result:

// Вашето име : Бай Иван

// Вие дължите: 000000131.7 лв.

Понеже в примера не е указана култура при форматирането на датата, се използва културата по подразбиране, в случая българската култура.

Модифициране на низове

Класът System.String притежава и някои методи за модификация на низове. Както споменахме, стойността на обект от тип string е непроменяема и затова всички тези методи водят до създаване на нов обект, в който връщат модифицираният низ. Използването на тези методи е подходящо при началната инициализация на низов обект, но не е препоръчително да се използват многократно в цикъл, защото това ще намали значително производителността.

Методът Trim(…) премахва зададените символи от началото и края на низа. Извикан без параметър методът премахва празните места в началото и края на низа. Предефинираният метод може да бъде извикан с група от символи, които да бъдат премахнати.

Методите за смяна на главни с малки букви и обратно са ToLower() и ToUpper(). За целта те използват текущата култура, ако не бъде зададена изрично друга.

За вмъкване на низ в низовия обект се използва методът Insert(…). Като параметри му се задават позицията в низовия обект, където да бъде вмъкнат подниз, и подниза, който да бъде вмъкнат. Грешки възникват при изпълнение на C# код ако е зададен null като подниз за вмъкване или позицията за вмъкване е извън границите на низовия обект.

Класът System.String предлага и метод за премахване на зададен брой символи от указана позиция в низовия обект. Това става с метода Remove(…). При работа с този метод трябва да внимаваме параметрите да не излизат извън дължината на низовия обект, защото това води до възникване на изключение.

Методът Replace(…) служи за заместване на зададен низ със зададен друг низ. Това заместване се извършва при всяко срещане на подадения като параметър низ в низовия обект.

Модифициране на низове – пример

Ще илюстрираме работата с методите Trim(…), ToUpper(), Insert(…), Remove(…) и Replace(…) чрез следния пример:

string example = ", мента, мастика, коняк.";

string trimmed = example.Trim(',', '.', ' ');

Console.WriteLine(trimmed);

// Result: мента, мастика, коняк

String upDemo = trimmed.ToUpper();

Console.WriteLine(upDemo);

// Result: МЕНТА, МАСТИКА, КОНЯК

string insertDemo = upDemo.Insert(7, "боза, ");

Console.WriteLine(insertDemo);

// Result: МЕНТА, боза, МАСТИКА, КОНЯК

string removeDemo = insertDemo.Remove(11, 9);

Console.WriteLine(removeDemo);

// Result: МЕНТА, боза, КОНЯК

string replaceDemo = removeDemo.Replace(", ", " + ");

Console.WriteLine(replaceDemo);

// Result: МЕНТА + боза + КОНЯК

Методи на System.String

Ще обобщим накратко действието на по-важните методи на класа String:

Метод	Описание
Compare(…)	Сравнява два низа лексикографски, като се съобразява с особеностите на културата.
CompareOrdinal(…)	Сравнява два низа като взима числената стойност на всеки символ от Unicode таблицата.
CompareTo(…)	Сравнява низовия обект със зададен като параметър друг низ.
Concat(…)	Слепва два или повече низа или стойности на низови обекти.
Copy(…)	Създава нова инстанция на обект от тип string със същата стойност.
CopyTo(…)	Копира зададен брой символи от определена област в низа и ги записва в масив.
EndsWith(…)	Определя дали низът завършва със зададения низ.
Equals(…)	Определя дали два низови обекта имат една и съща стойност.
Format(…)	Замества всеки форматиращ идентификатор със стойността на зададен обект.
GetEnumerator()	Връща обект, който може да обхожда отделните знаци на низовия обект.
IndexOf(…)	Връща позицията на първото срещане на зададен низ в низовия обект.
IndexOfAny(…)	Връща позицията на първото срещане на някои от символите, зададени в масив като параметър.
Insert(…)	Вмъква зададен низ на зададена позиция.
Intern()	Ако вече не е добавен, добавя низ в "Intern pool" таблицата и връща системния указател към него. Ще разгледаме този метод в секцията "Интерниране на низове".
IsInterned()	Връща указател към зададен низ. Ако низът не е в "Intern pool" връща null.
Join(…)	Слепва елементите на зададен масив от низове като между всеки два елемента поставя зададен разделител.
LastIndexOf(…)	Връща позицията на последното срещане на зададен низ в низовия обект.
LastIndexOfAny(…)	Връща позицията на последното срещане на някои от символите зададени в масив като параметър.
PadLeft(…)	Подравнява низа като добавя отляво зададен брой празни места или символи.
PadRight(…)	Подравнява низа като добавя отдясно зададен брой празни места или символи.
Remove(…)	Изтрива зададен брой символи от низа, започвайки от зададена позиция.
Replace(…)	Замества всички срещания на зададен низ със стойността на зададен друг низ в нов обект от тип string.
Split(…)	Разделя низа на поднизове по зададен разделител и записва получените поднизове в низов масив.
StartsWith(…)	Определя дали низът започва със зададен низ.
Substring(…)	Връща подниз от низовия обект.
ToCharArray()	Връща съдържанието на низа във вид на масив от символи (char[]).
ToLower()	Сменя регистъра на низа към малки букви.
ToUpper()	Сменя регистъра на низа към малки букви.
Trim(…)	Премахва зададени символи от началото и края на низа.
TrimEnd(…)	Премахва зададени символи от края на низа.
TrimStart(…)	Премахва зададени символи от началото на низа.

Escaping последователности

Когато искаме да съхраним в сорс кода на програмата специален знак или низ, който не може да се изпише директно в кода (например символа за празен ред), трябва да използваме т. нар. escaping последователности. Те представляват последователност от символи със специално значение и при компилация се заместват със съответния специален символ.

В таблицата са дадени някои често използвани escaping последователности:

Изписване	Значение	Код
\n	символ за нов ред LF (line feed)	\x0A
\r	символ CR (carriage return)	\x0D
\"	символ двойни кавички	\x22
\t	символ табулация	\x09
\'	символ апостроф	\x27
\\	символ обратна наклонена черта	\x5C
\0	символ null	\x00

В езика C# чрез escaping последователности може да се използва произволен ASCII и Unicode символ. Това става чрез следните escaping последователности:

- \xXX – обозначава символ с ASCII код XX (шестнайсетично), например \x0A е символ за нов ред (LF), а \0x41 е буквата A (главна, латинска)

- \uXXXX – обозначава Unicode символ с номер XXXX (шестнайсетично), напр. \u03A3 е символа Σ, а \u20AC е символа €

В C# символът @ пред даден низ указва, че низът е цитиран (verbatim string) и escaping последователностите в него се игнорират.

Това е удобно, когато задаваме пълния път за достъп до файл, например:

string fileName = @"C:\Windows\System32\calc.exe";

В горния пример обратната наклонена чертичка "\" не задава escaping последователности, защото низът е цитиран и се възприема без изменения, точно както е зададен.

Следва още един пример, който показва как да ползваме escaping последователности и цитиране на низове в C#:

static void Main()

{

string message = @"Добре дошли на биреното парти,

скъпи приятели! Има Загорка, Beck's,

Каменица, Шуменско, Ариана и Амстел.";

string copyright = "\xA9 2004 Бира Софт";

System.Windows.Forms.MessageBox.Show(message, copyright);

}

Резултатът от изпълнението на програмата е следният диалогов прозорец:

Специалният символ "©" се получава чрез escaping последователността \xA9. Съдържанието на диалога е цитиран низ и това запазва новите редове в текста и позволява той да бъде разположен на няколко реда в сорс кода.

В примера използвахме класа System.Windows.Forms.MessageBox. Този клас е дефиниран в системното асембли System.Windows.Forms.dll, което не се включва по подразбиране към проекта при създаване на конзолно приложение от VS.NET. По тази причина горният примерен код може да не се компилира успешно, ако се постави в конзолно приложение.

Ако компилаторът съобщи за грешка с текст "The type or namespace name 'Windows' does not exist in the class or namespace 'System' (are you missing an assembly reference?)", трябва да добавим асемблито System.Windows. Forms.dll към проекта. Това става като изберем "Add Reference" от контекстното меню на Solution Explorer във VS.NET и след това изберем съответното асембли от диалога за добавяне на референция:

Ефективно конструиране на низове чрез класа StringBuilder

Ако ви се наложи да добавяте символи към вече дефиниран низ, може би този код ще ви се стори логичен:

string result = "";

for (int i=0; i<10000; i++)

{

result += "някакъв текст";

}

Проблемът с долепването на низове

Този код има един много сериозен недостатък. Тъй като в .NET Framework стойността на обект от тип string не може да бъде променяна след като той веднъж е бил инициализиран, долепването на низ към друг низ е много бавна операция. Тя работи на няколко стъпки:

1. Създава се нов междинен обект (буфер) за резултата.

2. Копира се първият низ в началото на буфера.

3. Копира се вторият обект в буфера, след края на първия.

4. Създава се нов обект, символен низ и в него се копира стойността от буфера.

Старият низ и буферът остават неизползвани и се отбелязват за почистване от системата за почистване на паметта (garbage collector).

Когато изпълним процеса на долепване на низове в цикъл 10 000 пъти, се получава чувствително забавяне на програмата, което може да се избегне, ако низът се конструира по правилния начин.

Никога не конструирайте низове чрез долепване на техни части в цикъл!

Поради неизменяемостта на символните низове в .NET Framework и нуждата от допълнителен буфер, използването на операторите + и += и методите Insert(…) и Remove(…) e изключително неефективно при многократно изпълнение. Когато е необходимо един низ да бъде променян много пъти, много по-удачно е да се ползва класът StringBuilder.

Решението на проблема – класът StringBuilder

За разлика от String, класът StringBuilder представлява изменяема последователност от символи. Той съдържа указател към масив от символи, всеки от които може да бъде променян. Могат да бъдат добавяни и нови символи в края на низа. При добавянето на нови символи се извършва проверка дали общата дължина на низа не надхвърля заделената памет (т. нар. капацитет). Ако дължината е по-голяма от капацитета, StringBuilder заделя нов масив, който е двойно по-голям от предишния, т. е. капацитетът се удвоява.

Горният пример може да се преработи да използва StringBuilder по следния начин:

StringBuilder resultBuilder = new StringBuilder();

for (int i=0; i<10000; i++)

{

resultBuilder.Append("някакъв текст");

}

string result = resultBuilder.ToString();

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

Членове на StringBuilder

В таблицата по-долу е дадено описание на по-важните свойства на класа StringBuilder:

Свойство	Описание
Capacity	Извлича или задава капацитета (максималният брой символи, за които има заделена памет в текущата инстанция). Обикновено StringBuilder заделя повече памет, отколкото му е необходима, за да не се налага преоразмеряване при добавяне или вмъкване на символи или низове. Операцията преоразмеряване е бавна, защото е свързана с преместването на всички символи на нова позиция в паметта.
Chars[int]	Взима или задава символа на зададената позиция в инстанцията. В C# това свойство е реализирано като индексатор на класа StringBuilder.
Length	Взима или задава дължината на инстанцията, т. е. броя символи. Чрез задаване на по-малка дължина от текущата може по ефективен начин да се премахват символи от края на текущия низ.
MaxCapacity	Връща максималния брой символи, които могат да бъдат съхранени в инстанцията (в .NET Framework 1.1 това ограничение е 2 147 483 647, т. е. 2 GB).

Методи за работа със StringBuilder:

Метод	Описание
Append(obj)	Добавя низ или низовото представяне на даден обект към края на инстанцията.
AppendFormat(…)	Добавя низовото представяне на обект или група обекти, форматирани по даден форматиращ низ.
EnsureCapacity(int capacity)	Обезпечава минималния брой символи, които могат да бъдат съхранени в инстанцията, като заделя памет за посочения брой символи, ако текущото количество заделена памет е по-малко от указаното.
Equals(obj)	Проверява дали даден обект е равен на текущата инстанция. Извършва се сравнение символ по символ.
Insert(index, obj)	Вмъква низово представяне на указания обект с начало указаната позиция.
Remove(int index, int lenght)	Премахва указана област от символи.
Replace(…)	Замества всеки срещнат указан символ или низ с друг указан символ или низ.
ToString(…)	Конвертира StringBuilder към String.

Използване на StringBuilder – пример

За да илюстрираме по-добре работата със StringBuilder, ще дадем пример за неговото използване за модифициране на символни низове. Функцията UpcaseTextInBrackets(…) приема като параметър низ и връща като резултат същия низ, като частта от низа, която е била в скоби, се преобразува в главни букви:

public static string UpcaseTextInBrackets(string aText)

{

StringBuilder result = new StringBuilder(aText);

int brackets = 0;

for (int i=0; i<result.Length; i++)

{

if (result[i] == '(')

{

brackets++;

}

else if (result[i] == ')')

{

brackets--;

}

else if (brackets > 0)

{

result[i] = Char.ToUpper(result[i]);

}

string resultStr = result.ToString();

return resultStr;

}

От указания в конструктора низ се създава обект StringBuilder, който позволява да бъдат променяни отделните символи чрез индексатора this. След като приключи промяната на низа се използва StringBuilder. ToString(), за да се извлече променения низ във вид на String.

При създаването на обекта result от тип StringBuilder е използван конструкторът StringBuilder(string). Чрез него на инстанцията на StringBuilder се задава първоначалната стойност, а като размер на масива от символи се задава най-близката по-голяма от дължината на низа степен на 2, или 16, ако низът е по-къс от 16 знака. Например ако извикаме разгледаната в примера функция UpcaseTextInBrackets(…) с параметър "Test", размерът на заделената памет, който можем да проверим чрез свойството Capacity, ще е 16. Ако подадем като параметър низ с дължина от 100 символа, за масива ще бъдат заделени 128 позиции.

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

Задаване на първоначален размер за StringBuilder

Винаги, когато се работи със StringBuilder и е приблизително известен очакваният размер на резултатния низ, който ще бъде конструиран, се препоръчва да се задели предварително количеството памет, необходимо за него или дори малко повече от него (да има малък резерв). Това увеличава значително производителността, защото след първоначалното заделяне на паметта не се извършва нито едно преоразмеряване по време на работа, което е много бавна операция. Началният капацитет на StringBuilder може да се подаде в конструктора му.

Следният пример илюстрира динамично конструиране на низ (фактура в XML формат) като използва конструктора StringBuilder(int), чрез който задава първоначален размер на работния масив от символи. Така се избягва заделянето на нова памет при добавянето на текст чрез методите Append(…) и AppendFormat(…).

using System;

using System.Text;

class StringsDemo

{

static string CreateXmlInvoice(string aName, double aAmmount)

{

StringBuilder invoiceXml = new StringBuilder(1024);

invoiceXml.Append("<?xml version=\"1.0\"?>\n");

invoiceXml.Append("<invoice>\n");

invoiceXml.AppendFormat("\t<name>{0}</name>\n", aName);

invoiceXml.AppendFormat("\t<ammount>{0}</ammount>\n",

aAmmount);

invoiceXml.Append("</invoice>\n");

return invoiceXml.ToString();

}

static void Main()

{

string invoice = CreateXmlInvoice("Бай Иван", 137.60);

Console.WriteLine(invoice);

}

Резултатът е изпълнението на примера е следният:

Сравнение на скоростта на String и StringBuilder – пример

За да илюстрираме разликата в производителността между долепването на низове с оператора "+" на класа String и долепването на низове с помощта на StringBuilder, ще използваме следния пример:

static void Main()

{

// Append strings directly - runs very slowly

long startTime = Environment.TickCount;

Console.WriteLine("Direct string concatenation started.");

string result = "";

for (int i=0; i < 15000; i++)

{

result += "Дайте бира! ";

}

long endTime = Environment.TickCount;

long duration = endTime-startTime;

Console.WriteLine("Operation took {0:F8} sec.",

(decimal)duration/1000);

// Append strings with StringBuilder - the correct way

startTime = Environment.TickCount;

Console.WriteLine("String concatenation with StringBuilder started.");

StringBuilder resultBuilder = new StringBuilder();

for (int i=0; i < 15000; i++)

{

resultBuilder.Append("Дайте бира! ");

}

result = resultBuilder.ToString();

endTime = Environment.TickCount;

duration = endTime-startTime;

Console.WriteLine("Operation took {0:F8} sec.",

(decimal)duration/1000);

}

В примера се измерва времето за изпълнение на 15000 слепвания на низ, реализиран по два начина – чрез оператора += от класа String и по правилния начин – чрез класа StringBuilder. Полученият резултат е подобен на следния:

Виждаме, че има огромна разлика във времето за изпълнение на двете реализации на слепванията на 15000 низа. При първата реализация във всяко изпълнение на цикъла се създава нов обект, друг обект се маркира за унищожаване и се копират данни между двата. Тъй като тази операция се изпълнява хиляди пъти, това довежда до голямо забавяне в изпълнението. Втората реализация работи няколко хиляди пъти по-бързо, защото не изпълнява постоянно тежката операция "преместване на низ".

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

Класът StringInfo

Както споменахме при разглеждането на стандарта Unicode, някои символи се представят с повече от една 16-битова стойност. Тъй като един Char обект съдържа информация за една 16-битова стойност, няма как той да съхрани графеми, съставени от повече от една Unicode стойност.

Ако един низов обект, съдържащ съставни графеми, се обхожда символ по символ, то една графема, която се състои от няколко, примерно три, абстрактни Unicode стойности, няма да бъде коректно разпозната. Тъй като тези стойности са записани в последователни Char обекти, индексаторът на класа String ще разгледа всяка съставна стойност като отделен символ.

Съставните символи могат да бъдат съхранявани в низ, като класът StringInfo дава възможност низовете да се обхождат графема по графема. Чрез метода GetTextElementEnumerator(…) можем да получим итератор по отделните графеми на низа. След това с методите MoveNext() и GetTextElement() можем да осъществяваме достъп до поредната графема.

Използване на StringInfo – пример

Следващият пример илюстрира обхождането на отделните графеми от даден Unicode текст:

String s = "s\u0069\u0307\u0301\u0078\u0323";

TextElementEnumerator graphemes =

StringInfo.GetTextElementEnumerator(s);

StringBuilder text = new StringBuilder();

while (graphemes.MoveNext())

{

string grapheme = graphemes.GetTextElement();

foreach (char ch in grapheme)

{

text.AppendFormat("\\u{0:X4}", (int) ch);

}

text.Append(" = " + grapheme);

text.Append(Environment.NewLine);

}

MessageBox.Show(text.ToString(), s);

Резултатът от изпълнението на примера е низ от три символа в заглавието на показаната диалогова кутия и всяка от получените графеми, представена със съответните Unicode стойности, от които се състои.

Друг начин за ползване на класа StringInfo е чрез неговия метод ParseCombiningCharacters(…). Той приема като параметър String обект и връща масив от цели числа, които съдържат началните индекси на отделните единични или съставни символи.

Интерниране на низове

При работа със string обекти често се налага да се извърши сравняване на два низа. Тази операция отнема много системни ресурси и ако нашето приложение предполага много такива операции, то това ще влоши бързодействието на програмата ни.

С цел спестяване на памет CLR поддържа хеш таблица на всички използвани низови константи чрез структурата от данни "intern pool". Всеки символен низ, които се намира в "intern pool", се нарича интерниран.

В тази таблица се записват всички заложени в сорс кода символни низове, като е предвиден и методът System.Intern(String) за добавяне на динамично генерираните символни низове.

При добавянето на нов запис в таблицата първо се проверява дали символният низ не съвпада с вече въведен такъв. Така еднаквите низове се съхраняват в паметта физически на едно място. Сравнението на два интернирани низа става много по-бързо, защото те не се сравняват по съставящите ги символи, а се извършва директно сравнение на референциите им.

Методът System.Intern(…) позволява на програмиста сам да интернира динамично генериран низ по време на изпълнение на програмата, ако той не съществува в таблицата, и връща референция към него.

Методът String.IsInterned(…) проверява дали даден низ съществува в хеш таблицата и връща референция към него, ако вече е добавен. В противен случай връща null.

Всички символни низове, заложени като константи в сорс кода, винаги се добавят в хеш таблицата "intern pool", но това не важи за низовете, дефинирани по време на изпълнение. Нека разгледаме следния пример:

string s1 = "Няма бира!";

string s2 = "Няма ";

s2 = s2 + "бира!";

Console.WriteLine(Object.ReferenceEquals(s1,s2)); // False

s2 = String.Intern(s2);

Console.WriteLine(Object.ReferenceEquals(s1, s2)); // True

На първия ред дефинираме String обект, като стойността му ще се запише в хеш таблицата на "intern pool", когато то се компилира от JIT компилатора.

Тъй като s2 е дефиниран динамично, стойността му не се записва в "intern pool" и методът Object.ReferenceEquals(s1, s2) ще върне false.

За да интернираме s2, използваме статичния метод String.Intern(), който приема като параметър низ и търси в хеш таблицата "intern pool". Ако подаденият низ бъде намерен, методът връща референция към вече съществуващото поле.

Форматиращи низове

Възможностите на .NET Framework за форматиране ни позволяват да преобразуваме обект в низ, който е подходящ за извеждане на екрана. С форматиращи низове лесно може да представим информацията, предназначена за потребителя, в четим и разбираем вид.

Следните методи използват форматиращи низове:

- IFormattable.ToString(string format)

- String.Format(string format, …)

- Console.WriteLine(…)

- StringBuffer.AppendFormat(…)

Използване на форматиращи символи

Форматирането се задава с форматиращи символи и комбинации от тях. Ето няколко примера:

string s = 42.ToString("C5"); // s = "00042"

string s = String.Format("{0:P2}", 0.374); // s = "37,4%"

Console.WriteLine("Приходите за {0:d.MM.yyyy г.} са " +

"{1:C2}", DateTime.Now, 1872.43);

// Result: Приходите за 4.08.2004 г. са 1 872,43 лв

Методите, които приемат съставен форматиращ низ (composite formatting string) и променлив брой аргументи, изискват параметрите да се номерират и поставят във фигурни скоби, съдържащи незадължителен форматиращ низ. Ето пример:

Console.WriteLine("Здравейте, {0}!\n" +

"Днес е {1:dd.MM.yyyy, а часът е HH:mm:ss}.\n" +

"Вие сте посетител номер {2:D6}.\nДължите {3:C2}.",

"Бай Иван", DateTime.Now, 38, 17.40);

// Result:

// Здравейте, Бай Иван!

// Днес е 04.08.2004, а часът е 19:01:09.

// Вие сте посетител номер 000038.

// Дължите 17,40 лв.

В примера методът Console.WriteLine(…) се извиква с форматиращ низ и 4 параметъра, които се използват при форматирането.

Форматиране на числа

Стандартните форматиращи низове позволяват задаването на изгледа при отпечатване на основните типове числови стойности. Форматиращият низ трябва да е във вида Axx, където А е символ от азбуката, наречен форматен спецификатор (format specifier), a xx е незадължително число между 0 и 99 (указател за точност), което задава броя на значимите цифри или броя на нулите след десетичната запетая. Форматиращият низ не трябва да съдържа празни места.

Форматният спецификатор трябва да е един от позволените форматиращи символи (по-важните от тях са изброени в таблицата по-долу). В противен случай се получава изключение от тип FormatException.

Спецификатор на форматиране	Име	Описание
C или c	валута	Числото се преобразува в низ, който представлява парична стойност в стандартния формат за валута на текущата нишка (ако не бъде зададен изрично друг формат за валута – NumberFormatInfo обект).
D или d	десетична стойност	Числото се преобразува в низ от десетични цифри (0-9), предхождани от минус, ако е отрицателно. Указателят за точност определя минималния брой цифри, присъстващи в получения низ. При необходимост се добавят нули от ляво. Този формат се поддържа само от целочислени типове.
E или e	научен (експоненциален)	Числото се преобразува в експоненциален формат. Например числото 3.14 се записва във вида 3,140000E+000. Указателят за точност определя броя на знаците след десетичната запетая.
F или f	фиксирана запетая	Подаденото реално число се записва като низ с фиксирана запетая, например "3,14". Указателят за точност определя броя на десетичните знаци. В зависимост от културата се използва различен разделител между цялата и дробната част ("." или ",").
N или n	число	Числото се преобразува в низ от вида "-d,ddd,ddd.ddd…", където всяко ‘d’ обозначава цифра (0-9). Низът започва със знака минус, ако числото е отрицателно. Между всяка група от три цифри в ляво от десетичната запетая се поставя разделител. Указателят за точност задава желания брой знаци след десетичната запетая.
P или p	процент	Числото се преобразува в проценти чрез умножение по 100. Указателят за точност задава желания брой десетични знаци.
X или x	шестнайсетично число	Числото се преобразува в низ от шестнайсетични цифри. Например числото 234 се записва като "EA". Това форматиране се поддържа само от целочислени типове.

Трябва да имаме предвид, че при повечето форматиращи низове крайният вид на низа зависи от настройките в Regional Options в Control Panel, когато не е подадена изрично култура. Класът NumberFormatInfo съдържа информация за валута, десетични разделители и други символи, свързани с числовите стойности. Ще го разгледаме по-подробно в секцията за интернационализация и култури.

Следните примери демонстрират форматирането на число във вид на валута, експоненциален запис, шестнайсетичен запис и процент.

int i = 100;

string formatted = i.ToString("C");

Console.WriteLine(formatted);

// Result: 100,00 лв

// (при български настройки на Windows)

double d = -3.27e38;

Console.WriteLine("{0:E}", d);

// Result: -3,270000E+038

int value = 29690;

Console.WriteLine("0x{0:X8}", value);

// Result: 0x000073FA

double p = 0.3378;

Console.WriteLine("{0:P}", p);

// Result: 33,78 %

В горния пример видът на получения низ зависи от регионалните настройки на машината, на която е стартиран.

Форматиране със собствени шаблони

При отпечатване на числа имаме възможност да задаваме и собствени шаблони за форматиране чрез използването на следните символи:

Форматиращ знак	Име	Описание
#	диез	Замества една цифра, като при липса на цифра не се отпечатва нищо.
0	нула	Замества една цифра, като при липса на цифра се отпечатва 0.
.	точка	Задава десетичната запетая.
,	запетая	Задава разделител между хилядите.

Следният пример показва как могат да се ползват тези символи за създаване на собствени шаблони:

long tel = 359888123456;

Console.WriteLine("Тел. {0:(+###) (##) ### ## ##}", tel);

// Result: Тел. (+359) (88) 812 34 56

decimal sum = 4317.60M;

Console.WriteLine("Sum = {0:###,###,##0.00}", sum);

// Result: Sum = 4 317,60

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

Отместване при форматирането

При отпечатване с форматиране можем да задаваме ширината на полето, в което трябва да се запише резултатът. Ширината се указва след номера на аргумента, отделена със запетая. Например {0,10} разполага нулевият аргумент в пространство от 10 символа, като допълва отляво с интервали, а {0,-8} разполага нулевият аргумент в пространство от 8 символа, като допълва отдясно с интервали.

decimal sum = 4317.60M;

Console.WriteLine("Sum = |{0,16:C}|", sum);

// Result: Sum = | 4 317,60 лв|

string ip = "62.44.14.203";

Console.WriteLine("IP: |{0,-20}|", ip);

// Result: IP: |62.44.14.203 |

Освен чрез стандартните форматиращи низове, начинът на отпечатване на стойностите може да се контролира и чрез потребителско форматиране.

В горния пример, понеже се използва типът decimal, константата, която му се присвоява като стойност, трябва да завършва с буквата "M". В езика C# тази буква указва, че константната стойност е от тип System.Decimal. Ако тази буква се пропусне, компилаторът ще счита константата за число от тип double. По подобен начин константите от тип long трябва да завършват на "L", а константите от тип float – на "F".

Форматиране на дати и часове

Форматирането на дати и часове се извършва чрез шаблони за форматиране. Тези шаблони представляват символни низове, които се състоят от форматиращи символи (букви от латинската азбука, които се заместват с елемент от подадената дата или час) и други символи, които се използват без изменение. В таблицата са дадени най-често използваните форматиращи символи:

Форматиращ символ	Описание
d, dd	Замества деня от подадената дата (във вариант съответно с и без водеща нула).
M, MM	Замества месеца от подадената дата (във вариант съответно с и без водеща нула).
MMMM	Замества пълното име на месеца от подадената дата на езика, свързан с културата на текущата нишка.
yy, yyyy	Замества годината от подадената дата (в двуцифрен или четирицифрен формат).
h, hh, H, HH	Замества часа от подадените дата и време (във вариант съответно с и без водеща нула). Във варианта с малки букви се използва 12-часов формат, а във варианта с главни букви - 24-часов формат.
m, mm	Замества минутата от подадените и време (във вариант съответно с и без водеща нула).
s, ss	Замества секундата от подадените и време (във вариант съответно с и без водеща нула).
/	Замества текущия разделител между дни, месеци и години. Разделителят се взима от текущата култура (от свойството DateTimeFormatInfo.DateSeparator).
:	Замества текущия разделител между часове, минути и секунди. Разделителят се взима от текущата култура (от свойството DateTimeFormatInfo.TimeSeparator).

При отпечатване на дата може да се зададе или да не се зададе шаблон. Ако шаблон не бъде зададен, се използва шаблонът по подразбиране за текущата култура. От текущата култура зависят и някои от форматиращите символи, например разделителите.

Форматиране на дати и часове – пример

Ще демонстрираме използването на форматиращи низове за дати с няколко примера:

DateTime now = DateTime.Now;

Thread.CurrentThread.CurrentCulture=CultureInfo.InvariantCulture;

Console.WriteLine("{0:d.MM.yyyy - HH:mm:ss} ", now);

// Result: 28.09.2005 - 19:25:02

Thread.CurrentThread.CurrentCulture = new CultureInfo("bg-BG");

DateTime birthDate = new DateTime(1980, 06, 14, 06, 10, 00);

Console.WriteLine(

"Аз съм роден на {0:d MMMM yyyy г., в HH:mm часа}.",

birthDate);

// Result: Аз съм роден на 14 Юни 1980 г., в 06:10 часа.

Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");

Console.WriteLine(DateTime.Now);

// Result: 9/28/2005 7:24:49 PM

Потребителско форматиране

Типовете могат да дефинират свое собствено форматиране. За целта е нужно типът да имплементира интерфейса IFormattable и да предоставя свой метод ToString(string format, IFormatProvider formatProvider).

Възможно е също да си дефинираме собствен метод, който да се грижи за форматиране на произволен тип. За да направим наш метод Format(…), който да използваме за форматирането на даден тип, трябва да имплементираме ICustomProvider и IFormatProvider.

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

Можем да добавим възможност за обработка на дефинирани от нас форматиращи низове в дефинираните от нас собствени типове. За целта трябва в нашите типове да имплементираме интерфейса IFormattable и метода му ToString(). По този начин ще имаме контрол върху това какви форматиращи низове ще разпознава нашият тип.

Методът ToString(…) на IFormattable приема като параметри форматиращ низ и доставчик на формат (format provider). Ако форматиращият низ е празен или null, се извършва форматиране по подразбиране. Ако доставчикът на форматиране е null, се използва този по подразбиране.

Следва пример за тип, поддържащ няколко вида форматиращи низове:

class Money : IFormattable

{

private double mAmmount;

public Money(double aAmmount)

{

mAmmount = aAmmount;

}

public string ToString(string aFormat,

IFormatProvider aFormatProvider)

{

if (aFormat == "USD")

{

return String.Format(

"${0:###,###,##0.00}", mAmmount);

}

else if (aFormat == "BGL")

{

return String.Format(

"{0:###,###,##0.00} лв.", mAmmount);

}

else

{

throw new FormatException(String.Format(

"Invalid format: {0}", aFormat));

}

static void Main()

{

Money m = new Money(27000);

Console.WriteLine("В долари: {0:USD}", m);

// Result: В долари: $27 000,00

Console.WriteLine("В лева: {0:BGL}", m);

// Result: В лева: 27 000,00 лв.

try

{

Console.WriteLine("В евро: {0:EUR}", m);

}

catch (FormatException fe)

{

Console.WriteLine("Error: {0}", fe.Message);

}

// Result: Error: Invalid format: EUR

}

Класът Money от примера реализира интерфейса IFormattable и може да бъде форматиран с низовете "USD" и "BGL".

Потребителско форматиране за съществуващи типове

Можем да управляваме форматирането на вече съществуващите типове, като създаваме собствени класове, доставчици на формат. Те трябва да имплементират интерфейсите ICustomFormatter и IFormatProvider. При извикването на метода ToString(…), правилата, по които да ще се извърши форматирането, се определят от подадения като параметър доставчик на формат. Няма да се спираме не повече детайли. Конкретен пример за използването на ICustomFormatter и IFormatProvider има в MSDN Library, в помощната информация за класа IFormatProvider.

Интернационализация

Класовете String и Char зависят от т. нар. култура, която използват. Техните методи Format(…), Compare(…), ToUpper() и ToLower() работят по различен начин за различните езици. Културата влияе и на стандартните форматиращи низове, чрез които се форматират числа, валути и др.

Културите се дефинират от класа System.Globalization.CultureInfo и всяка нишка в приложението има асоциирана с нея култура (инстанция на този клас).

Културата на текущата нишка може да бъде извлечена от свойството CurrentCulture на класа System.Threading.Thread. Ако не бъде указана изрично, по подразбиране текущата култура се извлича от регионалните настройки в контролния панел на Windows.

Културите в .NET Framework

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

Инстанция на класа CultureInfo може да получим чрез конструктора CultureInfo, на който се подава код на език, следван от код на държава:

CultureInfo cultureFrenchCanada = new CultureInfo("fr-CA");

CultureInfo cultureEngUnitedStates = new CultureInfo("en-US");

Друг начин за инстанциране на класа CultureInfo е с помощта на статичното му свойство InvariantCulture, което връща инвариантната (общата) култура:

CultureInfo cultureNeutral = CultureInfo.InvariantCulture;

Инвариантната култура не е свързана с никой език и държава и се използва, за работа в неутрална среда, примерно за записване на числа в неутрален формат, който не зависи от държавата.

Класът CultureInfo

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

Свойства на класа CultureInfo

По-важните свойства на класа CultureInfo са Calendar, CompareInfo, DateTimeFormat, NumberFormat и TextInfo:

- Calendar – съдържа календара на културата (григориански, юлиански, еврейски, японски, корейски, тайвански), включващ информация за ерите, високосните години, броя месеци и броя дни за всеки месец в зависимост от годината.

- CompareInfo –дефинира как да бъдат сравнявани низове за зададената култура.

- DateTimeFormat – съдържа формата за визуализация на дата и час за зададената култура.

- NumberFormat – съдържа формата за запис на числата и вида на валутата.

- TextInfo – дефинира писмеността, асоциирана с текущата култура. Писмеността определя правилата за смяна на регистъра.

За всяко от тези свойства има съответни класове, дефинирани в пространството от имена System.Globalization.

Класът CultureInfo – пример

Със следния пример ще демонстрираме влиянието на културата при форматиране на валута:

using System;

using System.Globalization;

using System.Windows.Forms;

class CulturesDemo

{

static void ShowAmmount(

double aAmmount, CultureInfo aCulture)

{

string message = String.Format(

aCulture, "Ammount: {0:C}", aAmmount);

String caption = aCulture.EnglishName;

MessageBox.Show(message, caption);

}

static void Main()

{

ShowAmmount(137.25, new CultureInfo("bg-BG"));

ShowAmmount(137.25, new CultureInfo("en-US"));

ShowAmmount(137.25, new CultureInfo("de-DE"));

}

В диалоговата кутия ще се визуализира сумата 137.25, като валутата ще бъде съответно в лева, долари и евро:

Списък на културите – пример

Следният код реализира визуализиране на всички вградени в .NET Framework култури:

using System;

using System.Globalization;

public class ListAllCulturesDemo

{

public static void Main()

{

CultureInfo[] allCultures = CultureInfo.

GetCultures(CultureTypes.AllCultures);

foreach (CultureInfo ci in allCultures)

{

Console.Write("{0,-11}", ci.Name);

Console.Write(" {0,-4}", ci.TwoLetterISOLanguageName);

Console.Write(" {0,-4}",

ci.ThreeLetterWindowsLanguageName);

Console.WriteLine(" {0,-30}", ci.DisplayName);

}

Извличане на списък от всички култури в .NET Framework – пример

Целта на следващия пример е да изведем списък от всички култури, поддържани от .NET Framework. Списъкът ще бъде съставен от няколко колонки - .NET идентификатор на култура, двубуквен ISO идентификатор, Windows идентификатор и текстово описание. Ето как изглежда сорс кода на примера:

using System;

using System.Globalization;

public class ListAllCulturesDemo

{

public static void Main()

{

Console.WriteLine("CULTURE ISO WIN DISPLAYNAME");

Console.WriteLine("------- --- --- -----------");

CultureInfo[] allCultures =

CultureInfo.GetCultures(CultureTypes.AllCultures);

foreach (CultureInfo ci in allCultures)

{

Console.Write("{0,-11}", ci.Name);

Console.Write(" {0,-4}", ci.TwoLetterISOLanguageName);

Console.Write(" {0,-4}",

ci.ThreeLetterWindowsLanguageName);

Console.WriteLine(" {0,-30}", ci.DisplayName);

}

Ето и извадка от получения резултат:

Парсване на типове

Задачата за получаване на обект въз основа на низ е често срещана в практиката. Низът може да е получен като вход от потребителя или взет от база данни. Целта ни е да конструираме обект от стойността му, за да бъде тя по-лесно използваема в нашето приложение.

В .NET Framework за решението на тази задача е предоставено специално средство – методът Parse(string), който прави синтактичен анализ (парсване). Механизмът на неговото действие е следният: на метода Parse(string) на обект, поддържащ парсване, се подава низ, който задава валидна стойност за инстанция на такъв обект. Методът Parse(string) обработва подадения низ и връща инстанция на обекта със зададената стойност. Така методът изпълнява ролята на конструктор при създаването на обекта.

Методът Parse(string) реализира противоположната функция на метода ToString(). Подобно на него, той използва обект, доставчик на формат (FormatProvider), за да определи какво тълкуване да направи на подадения му символен низ.

Методът Parse(string) се поддържа стандартно от всички числени типове, от типа DateTime, от изброените типове (enums), както и от типовете Char и Boolean.

Парсване на числови типове

Методът Parse(string) може да парсва числа, записани в различни формати. Вариантът Parse(string, NumberStyles) позволява да се задават различни опции при парсването. NumberStyles дефинира битово поле, в което всеки бит обозначава дали е позволено или не определено поведение на входящия низ. В таблицата са дадени по-важните флагове и значението, което NumberStyles им придава:

Име на флага	Описание
None	Специални знаци не са позволени.
AllowLeadingWhite, AllowTrailingWhite	Указва, че при парсването трябва да се пренебрегнат празни места в началото / в края.
AllowLeadingSign	Указва, че числовият низ може да има знак в началото. Валидните символи за знак се определят културата, от свойствата PositiveSign и NegativeSign на NumberFormatInfo.
AllowParentheses	Указва, че числовият низ може да бъде заграден в двойка скоби.
AllowDecimalPoint	Указва, че числовият низ може да съдържа десетична запетая. Валидните знаци за десетична запетая се определят от свойството NumberFormatInfo на използваната култура.
AllowThousands	Указва, че числовият низ може да съдържа групиращи разделители - разделящи например стотиците от хилядите. Валидните разделители се определят от NumberFormatInfo свойството на използваната култура.
AllowExponent	Указва дали числовият низ може да е в експоненциален запис.
AllowCurrencySymbol	Указва, че числовият низ се приема като валутна информация, ако има наличен символ за валута; в противен случай се приема като число. Валидните символи за валута се определят от свойството CurrencySymbol на NumberFormatInfo.
AllowHexSpecifier	Указва, че числовият низ представлява шестнайсетична стойност. Валидните шестнайсетични стойности съдържат цифрите 0-9 и шестнайсетичните цифри A-F и a-f. Низовете не трябва да имат "0x" в началото.

Тъй като за всяка настройка се използва един бит от битовото поле, е лесно да се зададе комбинация от настройки. Това можем да направим с побитовия оператор | по следния начин:

string price = "3,14159";

double unitPrice = Double.Parse(price,

NumberStyles.AllowCurrencySymbol |

NumberStyles.AllowDecimalPoint |

NumberStyles.AllowExponent |

NumberStyles.AllowLeadingWhite |

NumberStyles.AllowParentheses |

NumberStyles.AllowThousands |

NumberStyles.AllowTrailingWhite);

С този код указваме, че желаем да получим число от потребителски низ, като позволяваме символ за валута, десетична запетая, експонента, празни символи в началото, двойка скоби, разделители на хилядите и празни символи в края. Някои от тези параметри зависят от зададените настройки за култура. По-нататък ще разгледаме влиянието на зададената култура върху метода Parse(…).

За да не се налага всеки път да изброяваме толкова много флагове, можем да използваме предефинираните комбинации от флагове в изброения тип NumberStyles – стойностите Integer, Number, Float, Currency, HexNumber и т. н., имената на които подсказват за какво служат. Ето пример за използването на предефинирана комбинация от флагове при парсването на число:

string price = "17,34 лв";

double unitPrice = Double.Parse(price, NumberStyles.Currency);

Влияние на културата върху парсването

За да зададем изрично желаните настройки на културата, трябва да използваме варианта Parse(string, IFormatProvider). Той приема като параметър обект, имплементиращ IFormatProvider, който указва форматиращите настройки за използваната култура. IFormatProvider обектът включва информация за форматирането на числата (разделител за хилядите, знак за дробната част и др.) и за форматирането на валутата (символ за валута и местоположение).

Методът Parse(string, NumberStyles, IFormatProvider) комбинира предходните два варианта на метода. С този метод може да се зададат едновременно специфичен формат за парсваното число и специфична култура.

Парсване на числови типове – пример

Нека разгледаме няколко примера как можем да парсваме числа като задаваме комбинация от флагове за техния формат и култура:

static void Main()

{

// Set the default formatting for current thread.

// Invariant culture will be used for Console.WriteLine()

System.Threading.Thread.CurrentThread.CurrentCulture =

CultureInfo.InvariantCulture;

string s = " 000012,54 лв ";

double value = Double.Parse(s, NumberStyles.Currency,

new CultureInfo("bg-BG"));

Console.WriteLine(value); // 12.54

s = "17,345,342.38";

value = Double.Parse(s, NumberStyles.Number,

new CultureInfo("en-US"));

Console.WriteLine(value); // 17345342.38

value = Double.Parse(s, NumberStyles.Number,

new CultureInfo("bg-BG"));

// System.FormatException: Input string was not in a

// correct format.

}

При първото обръщение към Parse(…) подаваме низ, съдържащ информация за цена в български формат. Задаваме параметър NumberStyles. Currency, за да укажем, че това е валута и указваме, че използваме културата за България ("bg-BG"), за да може правилно да бъдат разпознати символът за валута ("лв") и знакът за дробната част (",").

При второто обръщение задаваме, че очакваме да прочетем число. Тъй като указваме американска култура ("en-US"), коректно се разпознават знакът "," като разделител на хилядите и знакът "." като обозначение за начало на дробната част. За сравнение сме показали, че ако опитаме да прочетем това число с българска култура, ще се получи изключение от тип FormatException защото в България символът "," се използва за отделяне на дробната част при реалните числа.

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

Класът DateTime имплементира метод Parse(…), който ни позволява да получим нов DateTime обект от низове, съдържащи дати в текстов вид.

Нека разгледаме метода DateTime.Parse(…) със сигнатура Parse(string, IFormatProvider, DateTimeStyles). Начинът на записване на датата и часа се взимат от IFormatProvider. Изброеният тип DateTimeStyles задава допълнителни настройки (дали низът може да съдържа празно място, дали да се приема текущата дата, когато е зададен само час и др.).

Освен метода Parse(…) класът DateTime имплементира и друг метод за парсване на дати и часове – ParseExact(string date, string format, IFormatProvider). Този метод позволява задаване на точния формат на датата и часа, които трябва да се парснат. За разлика от Parse(…), ParseExact(…) няма да обработи правилно датата, ако тя не отговаря абсолютно точно на зададения формат.

Форматът на датите и часовете се задава чрез шаблони за форматиране, които са същите, които разгледахме в секцията за форматиране на дати.

Парсване на дати – пример

За да илюстрираме работата с Parse(…) и ParseExact(…) ще използваме следните примери:

DateTime dt = DateTime.Parse(" Thursday,August 05, 2004 ",

new CultureInfo("en-US"), DateTimeStyles.AllowWhiteSpaces);

Thread.CurrentThread.CurrentCulture =

CultureInfo.InvariantCulture;

Console.WriteLine("{0:d}", dt);

// Result: 08/05/2004

dt = DateTime.ParseExact("5.08.2004 г. 15:47:00 ч.",

"d.MM.yyyy г. HH:mm:ss ч.", new CultureInfo("bg-BG"));

Console.WriteLine("{0:d.MM.yyyy HH:mm:ss}", dt);

// Result: 5.08.2004 15:47:00

dt = DateTime.ParseExact("15:53:21", "HH:mm:ss",

CultureInfo.InvariantCulture);

Console.WriteLine("{0:HH:mm:ss}", dt);

// Result: 15:53:21

При първото обръщение към метода Parse(…) указваме, че желаем да конструираме нов обект от тип DateTime, като стойността се взима от низа " Thursday,August 05, 2004 ". Вторият параметър създава нов обект CultureInfo, който указва използването на настройките за култура на САЩ (US). От изброения тип DateTimeStyles се указва стойността DateTimeStyles.AllowWhiteSpaces, която разрешава низът, който се парсва, да съдържа интервали, табулации и други символи за празно пространство.

Следващата стъпка е да зададем инвариантна култура за текущата нишка. Както видяхме в секцията за култури, инвариантната култура, не е свързана с конкретно местонахождение. В резултат на тази операция следващите извиквания на WriteLine(…) няма да отпечатват датата с настройките на операционната система, а по неутрален относно държавата начин.

За да бъде извършено правилно следващото разпознаване, подаваме на метода ParseExact(…) низ с дата, която отговаря символ по символ на шаблона на зададения от нас формат. Задаваме българска култура, за да бъдат разпознати правилно символите за час и година.

При второто обръщение към ParseExact(…) подаваме като култура CultureInfo.InvariantCulture за да укажем, че низът, който парсваме, не съдържа символи за час, година и т. н.

Кодиращи схеми

При преноса на текстове по мрежата или записа им във файлове се използват т. нар. кодиращи схеми (encodings). Най-често се използват кодиращите схеми от стандарта UTF (Unicode Transformation Format), дефинирани от Unicode стандартите.

Кодиращи схеми UTF

UTF представляват алгоритмични кодиращи схеми, при които всеки Unicode номер се представя като уникална поредица от 8-битови, 16-битови или 32-битови стойности. От тук произлизат и различните формати за съхранение на текст в Unicode формат в компютърната памет - UTF-8, UTF-16, UTF-32.

Най-разпространеният в Интернет е UTF-8. UTF-16 се използва в Windows и Java, а UTF-32 е популярен в някои UNIX системи. Конвертирането между различните кодиращи схеми се осъществява от бързи алгоритми, работещи без загуба на информация.

Понеже кодирането при UTF схемите е без загуба, съществува взаимоеднозначно съответствие между схемите UTF-8, UTF-16 и UTF-32. Това означава, че всеки текст от UTF-8 може да се преобразува до UTF-16 и след това ако се преобразува обратно до UTF-8, ще се получи оригиналният UTF-8 текст без никакви промени. Съществуват и други кодиращи схеми, които работят със загуба, и при тях няма взаимоеднозначно съответствие между оригинален текст и кодиран текст.

UTF-8

При UTF-8 символите се кодират с 8-битови стойности, като символите с номера до 128 (т. е. ASCII символите) се представят със собствения си Unicode номер, като най-старшият им бит е нула. Останалите символи се кодират с два, три или четири байта по определени правила. Това кодиране се използва за предаване на текст, когато е необходим компресиран запис. UTF-8 кодирането е подходящо за текстове, в които преобладават символите от ASCII таблицата, например за текстове на английски език.

При UTF-8 знаците \u0000 до \u007F се записват с един байт. Това са ASCII символите, използвани в САЩ. Знаците \u0080-\u07FF, които отговарят на символите от европейските, арабските и еврейските езици, се записват с два байта. Знаците в интервала \u0800-\uFFFF се записват с три байта. Всички останали се записват с четири байта.

За източноазиатските езици кодирането UTF-8 е неефективно, защото записва повечето символи с 4 байта.

UTF-16

Кодиращата схема UTF-16 представя един знак (графема) като една или две 16-битови стойности, като по-често използваните Unicode знаци се представят с една 16-битова стойност, а останалите – с две (чрез кодова двойка).

Всички символни низове в .NET Framework инстанциите на класа System. String) съхраняват своите стойности в паметта в кодиране UTF-16.

UTF-16 е най-ефективният начин за представяне на азиатски символни низове. При ASCII символите UTF-16 схемата не е много ефективна, защото се използват по два байта за знак, който може да бъде представен само с един байт.

При UTF-16 трябва да се съобрази правилно и подредбата на байтовете, тъй като се срещат два различни подхода при запис. В зависимост дали подредбата на байтовете е little-endian или big-endian стойността \uABCD се записва съответно като 0xCD 0xAB или като 0xAB 0xCD.

UTF-32

Както предполага наименованието, в тази кодираща схема се използват 32 бита за всеки Unicode знак. Така всеки един символ се записва като 4-байтово число. В повечето приложения не се налага да използвате нещо повече от ASCII символите и в този случай използването на 32 бита е доста разточително. Затова употребата на UTF-32 е нежелателна при съхранение на диска или при пренос по мрежата.

Подредба на байтовете при UTF-16 и UTF-32

Броят на байтовете не определя еднозначно кодирането на символите. Съществуват различни начини за подреждане на последователността от байтове. Когато първо се записва най-старшият байт, това е big-endian кодиране, а когато той е в края на записа - little-endian. Преди да предадете между два компютъра например една 4-байтова стойност (UTF-32), трябва да се уверите, че те интерпретират по един и същ начин последователността от байтове.

Unicode разрешава проблема с подредбата на байтовете, като дефинира специален символ с номер U+FFFE, който се нарича "Byte Order Mark (BOM)" и се поставя като идентификатор в началото на Unicode текстовете. Наличието на U+FFFE в началото на даден UTF-16 файл указва обратен ред на байтове.

Следната таблица показва съдържанието на BOM в различните видове кодиране:

Байтове	Формат на кодиране
00 00 FE FF	UTF-32, big-endian
FF FE 00 00	UTF-32, little-endian
FE FF	UTF-16, big-endian
FF FE	UTF-16, little-endian
EF BB BF	UTF-8

Знаейки че .NET Framework използва кодиране UTF-16 със запис в little-endian формат, можем да проверим коректната стойност на BOM.

Съществуват и други схеми, производни на UTF-16 и UTF-32. Unicode дефинира стандартите UTF-16BE, UTF-16LE, UTF-32LE и UTF-32BE (big-endian, little- endian), които имат гарантирана подредба на байтовете.

Други кодиращи схеми

Освен изброените Unicode кодиращи схеми има и други такива. Повечето от тях кодират Unicode текстовете със загуба. Това означава, че няма взаимоеднозначно съответствие между оригиналния текст и кодирания текст, т. е. от оригиналния текст можем да получим кодирания текст, но обратната операция не е еднозначна.

Например ASCII кодирането преобразува всички Unicode символи с кодове в диапазона \u0000-\u007F в съответен ASCII символ, а останалите в символа "?" (0x3F). Всички символи от кирилицата при това кодиране се заместват с "?" и губят оригиналната си стойност.

Кодиращата схема Windows-1251 замества ASCII символите, символите от кирилицата и някои други с байтове в диапазона 0x00-0xFF, а останалите замества със знак "?" (0x3F). Тази кодираща схема често пъти се използва за представяне на текстове на кирилица, но тя не е универсална, както UTF-8 и причинява загуби при някои текстове.

Кодиращи схеми – пример

За илюстрация на разгледаните кодиращи схеми са дадени няколко символа, техните Unicode номера и кодирането им в различните UTF схеми:

Знак	Unicode номер	Unicode номер (hex)	UTF-8 (hex)	UTF-16 (hex)	UTF-32 (hex)
A главна латинска буква "A"	65	U+0041	0x41	0x0041	0x00000041
⅔ математически символ "две трети"	8532	U+2154	0xE2 0x85 0x94	0x2154	0x00002154
♥ символ "сърце"	9829	U+2665	0xE2 0x99 0xA5	0x2665	0x00002665
листо на китайски	33865	U+8449	0xE8 0x91 0x89	0x8449	0x00008449
нота шестнайсетина	119137	U+1D161	0xF0 0x9D 0x85 0xA1	0xD834 0xDD61	0x0001D161

За да конвертираме текст от символи в байтове и обратно, можем да използваме класа System.Text.Encoding.

Конвертиране със System.Text.Encoding

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

В .NET Framework преобразуването на текст в последователност от байтове и обратното по дадена кодираща схема можем да извършваме с помощта на класа System.Text.Encoding и неговите наследници.

В таблицата са дадени най-често използваните методи и свойства на класа Encoding:

Метод/Свойство	Описание
GetBytes(string)	Конвертира символен низ в масив от байтове.
GetString(byte[])	Конвертира масив от байтове в символен низ.
GetChars(byte[])	Конвертира масив от байтове в масив от символи.
GetMaxByteCount(…) GetMaxCharCount(…)	Връща максималната дължина на резултата, която може да се получи при конвертиране.
Convert(Encoding, Encoding, byte[])	Конвертира от една схема на кодиране в друга.

Следват няколко примера, които илюстрират използването на тези методи за конвертиране между различните кодиращи схеми:

Encoding utf16le = Encoding.Unicode;

byte[] bytes = utf16le.GetBytes("\uABCD");

Console.WriteLine("0x{0:X} 0x{1:X}", bytes[0], bytes[1]);

// Result: 0xCD 0xAB

Encoding utf16be = Encoding.BigEndianUnicode;

bytes = utf16be.GetBytes("\uABCD");

Console.WriteLine("0x{0:X} 0x{1:X}", bytes[0], bytes[1]);

// Result: 0xAB 0xCD

Encoding windows1251 = Encoding.GetEncoding("windows-1251");

bytes = windows1251.GetBytes("Цакам с A♥ и две ♣.");

Console.WriteLine(BitConverter.ToString(bytes));

// Result: D6-E0-EA-E0-EC-20-F1-20-41-A6-20-E8-20-E4-E2-

// E5-20-A6-2E

Console.WriteLine(windows1251.GetString(bytes));

// Result: Цакам с A│ и две │.

// Windows-1251 encoding is unable to preserve

// some character's original values

Encoding utf8 = Encoding.UTF8;

bytes = utf8.GetBytes("Ω(x) ≤ Ψ(x)π² ≤ ∫φ(x) ∂x ≤ ⅔");

Console.WriteLine(BitConverter.ToString(bytes));

// Result: CE-A9-28-78-29-20-E2-89-A4-20-CE-A8-28-78-

// 29-CF-80-C2-B2-20-E2-89-A4-20-E2-88-AB-CF-86-28-78-29-

// 20-E2-88-82-78-20-E2-89-A4-20-E2-85-94

Encoding ascii = Encoding.ASCII;

Console.WriteLine(BitConverter.ToString(bytes));

// Result: 3F-20-32-30-30-34-20-4D-65-6E-74-65-3F

Console.WriteLine(ascii.GetString(bytes));

// Result: ? 2004 Mente?

// ASCII encoding is unable to preserve

// some character's original values

Encoding western = Encoding.GetEncoding("iso-8859-1");

Console.WriteLine(BitConverter.ToString(bytes));

// Result: A9-20-32-30-30-34-20-4D-65-6E-74-65-AE

Console.WriteLine(western.GetString(bytes));

// Result: c 2004 MenteR

// ISO-8859-1 (latin) encoding is unable to preserve

// some character's original values

В разгледания пример първо създаваме обект от тип Encode.Unicode. След това извикваме метода му GetBytes(string) и запазваме върнатия резултат в масив от байтове. Отпечатваме получения масив от байтове на екрана, като задаваме формат за шестнайсетично число.

Вторият пример е аналогичен но вместо Unicode кодираща схема използваме BigEndianUnicode, за да укажем, че искаме запис, при който по-старшите байтове се записват преди младшите.

В третия пример създаваме Encoding обект с конструктора GetEncoding(), като му подаваме като параметър името на кодиращата схема windows-1251. Отново с помощта на GetBytes(string) взимаме байтовото представяне на низа и с помощта на класа BitConverter го отпечатваме на екрана. Класът BitConverter е предназначен за преобразуване на базови типове (числа, знаци, низове, булеви стойности) в редици от байтове и обратно. В случая използваме метода му ToString(byte[]) за да преобразуваме поредицата във вид, удобен за визуализация.

Следващата стъпка демонстрира как да получим обратно символният низ от извлечената поредица от байтове по зададена кодираща схема.

Останалите примери аналогично използват операциите GetBytes(string) и GetString(bytes[]) за UTF8, ASCII и ISO-8859-1. Вижда се, че при някои кодирания преобразуванията са със загуба.

Кодиране Base64

Когато се налага да се пренесат двоични данни през текстова среда, която поддържа само 7-битово кодиране, например при изпращане на ZIP архив по имейл, се налага последователността от байтове да се представи като символен низ. Тази задача се изпълнява най-често с помощта на кодирането Base64.

Кодиращата схема Base64 преобразува всеки три последователни байта в четири символа измежду A-Z, a-z, + и /. В резултат на това кодиране обемът на данните се увеличава с около 1/3.

За да извършим преобразуване на последователност от байтове в Base64 низ в .NET Framework можем да използваме класа System.Convert. Методът Convert.ToBase64String(byte[]) приема като параметър масива от байтове и по гореописания начин го преобразува в низ.

За преобразуване в обратна посока, от Base64 низ към масив от байтове, се използва методът Convert.FromBase64String(base64string). Този метод връща като резултат получения масив от байтове. Тази операция се налага да бъде извършвана например когато се записва прикачен към e-mail файл на твърдия диск.

Следният пример показва и двете преобразуващи операции:

using System;

class Base64Demo

{

static void Main()

{

byte[] array = {0x00, 0x3D, 0x80, 0xA0, 0xFF};

string base64 = Convert.ToBase64String(array);

Console.WriteLine(base64);

// Result: AD2AoP8=

byte[] array2 = Convert.FromBase64String(base64);

Console.WriteLine(BitConverter.ToString(array2));

// Result: 00-3D-80-A0-FF

}

Работа с Unicode във Visual Studio.NET

Различните схеми за кодиране за запис на файлове на компютъра важат както за всички текстови файлове така и за файловете със сорс код във Visual Studio.NET. Текстовият редактор има възможност за работа с файлове, записани в голям набор от кодирания.

Ако не укажем изрично каква кодираща схема да се използва, текстовият редактор на Visual Studio.NET използва кодирането по подразбиране в Windows. За да използваме Unicode символи в сорс кода на програмите си, трябва да запишем файловете си с кодираща схема UTF-8.

Поддръжка на всички езици

По подразбиране Windows не поддържа всички езици от Unicode стандарта. С цел спестяване на дисково пространство и други ресурс в Microsoft Windows шрифтовете за източноазиатските езици не се инсталират по подразбиране, но могат да се инсталират ръчно.

Това става като в Control Panel от настройките на Regional and Language Options, както се вижда на фигурата:

Използване на Unicode в редактора на Visual Studio .NET – пример

С настоящия пример ще разгледаме нагледно как чрез редактора на Visual Studio .NET можем да създаваме, компилираме и изпълняваме програми, които съдържат в сорс кода си Unicode низове.

Ето стъпките за изграждането на проект съдържащ Unicode низове:

Стартираме VS.NET
Създаваме ново конзолно приложение на езика C#

3. Заместваме кода в главния файл (Class1.cs) със следния код:

using System;

using System.Text;

using System.Windows.Forms;

class UnicodeInVsNETDemo

{

static void Main()

{

StringBuilder sb = new StringBuilder();

sb.Append("What is Unicode? (English)");