Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
23
Добавлен:
26.03.2016
Размер:
693.88 Кб
Скачать

Операційні системи і системне програмування

Збірки, маніфести, простори імен. Утиліта IL DASM

Для кращого розуміння подальшого матеріалу розглянемо деякі поняття і технологію роботи середовища виконання.

  • Common Intermediate Language (скорочено CIL) - проміжна мова, розроблена фірмою Microsoft для платформи .NET Framework. Компілятори зі всіх мов, з якими працює платформа .NET, переводять програми з цих мов у проміжну мову CIL. Приклад показаний на рис. 11.1. Мова CIL за синтаксисом і мнемонікою нагадує мову асемблера. В той же час мова CIL містить деякі достатньо високорівневі конструкції, що підвищують її рівень у порівнянні з асемблером для будь-якої реально існуючої машини, і писати код безпосередньо на CIL легше, ніж на асемблері для реальних машин. Тому його можна розглядати як своєрідний "високорівневий асемблер". Мову CIL також нерідко називають просто IL (Intermediate Language), тобто "проміжна мова".

  • Common Language Runtime (CLR) - загальне мовне середовище виконання програм на мовах .NET.

  • Just in Time (JIT) - компілятор з мови CIL. Є частиною так званої CLR. Прямо у момент виконання програма транслюється у машинну мову і виконується.

  • Код програми - команди програми після їх компіляції.

  • Метадані платформи .NET - спеціальні структури даних програми, які додаються в код, на мові CIL. Метадані описують всі класи і члени класів, а також класи і члени класів, які програмою викликаються з іншої програми. Метадані для методу містять повний опис методу, включаючи його клас (а також програму, яка містить цей клас), його повернутий тип і всі параметри цього методу. Взагалі метаданими називають не звичайні в побутовому розумінні дані, а якісь інші, специфічні, перетворені дані, відмінні від звичайних.

  • Dinamic Link Library (dll) - бібліотека програмних модулів, відкомпільованих і готових вбудуватися у викликаючи програму. Модулі можуть під’єднуватися до програми на етапі створення exe-файла (виконуваного файла) або у момент виконання програми. Містять різні стандартизовані функціональні блоки.

Рис. 11.1. Організація взаємодії з мовами на платформі .NET

Збірки

Збірка - це exe- або dll-файл. Перший тип збірки називають статичним, другий - динамічним. Яку збірку можна отримати, визначається заданням режиму компіляції (задається спеціальним ключем). Збірки можуть містити один або декілька модулів. Наприклад, великі проекти можуть бути сплановані так, щоб декілька розробників працювали кожен над своїм модулем, а разом ці модулі утворювали б одну збірку. Файли, які складають збірку, об'єднані логічно, незалежно від їх фізичного розташування. Зв’язує їх маніфест. Середовище виконання розцінює збірку, як цілісний модуль. Маніфест - частина збірки, в якій містяться метадані, тобто дані, що описують збірку, і параметри для її використання. Маніфест містить ім'я збірки, номер версії, інформацію про підтримувані процесори та операційні системи, імена файлів, які утворюють збірку, інформацію, яка зв'язує типи з файлами, які їх містять, інформацію про збірки, які використовуються цією збіркою.

Відомості про збірку можуть бути переглянуті за допомогою спеціальної програми IL DASM (Intermediate Language Disassembler - дизасемблер проміжної мови), вихід на виклик якої знаходиться в інтегрованому середовищі в меню Tools (рис. 11.2).

Рис. 11.2. Виклик IL Dasm

Команда IL DASM дозволяє відкрити діалогове вікно для вибору збірки. Для ілюстрації ми вибрали застосування по роботі з інтерфейсами, яке розглядалося в розділі «Інтерфейси». Вигляд збірки показаний на рис. 11.3.

З рисунка видно повну структуру модуля застосування. Модуль можна детальніше досліджувати за допомогою команд меню View (ховати рядки з деякими властивостями, залишаючи видимими інші рядки і т. п.). Якщо двічі клацнути на методі Main(), відкриється вікно з програмою на мові CIL, в яку програми транслюються компіляторами всіх мов, що входять в платформу .NET. Якщо ж треба подивитися вміст маніфесту, треба двічі клацнути на нім мишею.

Рис. 11.3. Збірка застосування по роботі з двома інтерфейсами

Простори імен

Простір імен (namespace) - концепція, запозичена з C++ і, яка дозволяє забезпечити унікальність всіх імен, використовуваних у конкретній програмі або проекті.

Якщо ви, наприклад, є учасником групи розробників деякого великого проекту і створюєте свій модуль, то вам не обов'язково піклуватися про найменування змінних в цьому модулі, про те, що коли всі розробники почнуть збирати свої модулі в єдиний проект, з'являться змінні з однаковими іменами і різним сенсом, почнеться плутанина і проект стане непрацездатним. Концепція простору імен як раз і забезпечує незалежну розробку модулів одного проекту тому що кожен розробник може оголосити свій особистий простір імен і в ньому називати змінні на свій розсуд. А загальний проект вказуватиме, що він використовує такий-то простір імен, щоб працювати з таким-то модулем. Компілятор просто в цьому випадку до кожного внутрішнього імені додає ім'я простору імен і тим робить співпадаючі імена в різних просторах різними. Така ж історія і з бібліотеками класів в C#. Класи створювалися різними розробниками і можуть мати співпадаючі імена (та так воно і є насправді: наприклад, класів Timer в .NET Framework нараховується три штуки). Тому класи розділені: вони згруповані за своїми функціональними властивостях і розподілені по різних іменованих просторах, головним з яких є простір System.

Більше 90 просторів імен, визначених в .NET Framework, починаються зі слова System.

Як створити собі свій простір імен? Згідно синтаксису:

namespace Ім'я

{

class ім'я

{

...

}

...

}

Усередині простору імен ви можете оголосити один і більш наступних типів:

  • інший простір імен;

  • клас;

  • інтерфейс;

  • структуру.

Взагалі тоді при зверненні до якогось класу при такому підході треба вказувати весь ланцюжок назв просторів, в який входить даний клас, бо простори складають якусь ієрархію і назви просторів досить довгі. Але якщо використати ключове слово using (використовуючи) перед складеним ім'ям простору, в якому знаходяться потрібні нам класи, то цей простір імен можна не вводити при зверненні до його класів.

Деякі простори імен середовища .NET приведені в табл. 11.1.

Таблиця 11.1. Простори імен середовища .NET

Назва простору

Опис

System

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

http://msdn.microsoft.com/en-us/library/system.aspx

System.Collections

System.Collections.Generic

Містять класи, що дозволяють створювати спеціальні колекції даних: списки, черги, бітові масиви, словники. Вміст можна подивитися за посиланням http://msdn.microsoft.com/en-Us/library/system.collections(v=vs.80).aspx

System.Data

Містить класи для взаємодії з базами даних. Вміст можна подивитися за посиланням http://msdn.microsoft.com/en-us/library/system.data.aspx

System.IO

Містить типи даних для обробки файлового вводу-виводу. Вміст можна подивитися за посиланням http://msdn.microsoft.com/en-us/library/29kt2zfk.aspx

System.Drawing

System.Windows.Forms

Містить типи даних для побудови графічних застосувань з використанням набору Windows Forms. Вміст можна подивитися за посиланнями: http://msdn.microsoft.com/en-us/library/system.drawing(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/system.windows.forms.aspx

System.Windows

System.Windows.Controls

System.Windows.Shapes

System.Windows є кореневим для інших, які містять набір графічних інструментів для роботи в середовищі Windows Presentation Foundation (WPF). Вміст можна подивитися за посиланнями:

http://msdn.microsoft.com/en-us/library/system.windows.aspx

http://msdn.microsoft.com/en-us/library/system.windows.controls(v=vs.95).aspx

http://msdn.microsoft.com/en-us/library/system.windows.shapes.aspx

System.ServiceModel

Містить інструменти для створення розподілених застосувань в середовищі Windows Communication Foundation (WCF). Вміст можна подивитися за посиланням

http://msdn.microsoft.com/en-us/library/system.servicemodel.aspx

System.Security

Містить типи даних, які дозволяють створювати застосування з криптографічного захисту і т. п. Вміст можна подивитися за посиланням

http://msdn.microsoft.com/en-us/library/windows/apps/hh454038.aspx

Простори імен підключаються до програми за допомогою ключового слова using. Добре, якщо ці простори знаходяться в стандартній бібліотеці середовища розробки. А якщо ви самі створили власні простори імен, використовуючи свої застосування? Ваші застосування після їх компіляції приймають формат збірки. Тобто визначені вами простори імен потрапили, в загальному випадку, в різні складки. Або якийсь інший розробник визначив якісь класи в своєму просторі імен в своїй збірці, яку ви придбали якимсь шляхом. Як підключати ці нові простори із збірок? Для цього існує команда Add Reference (Додати посилання) меню Project (Проект) середовища розробки. Якщо ви виберете цю команду, відкриється діалогове вікно для формування посилань на потрібні вам збірки (вкладка Net Assembly Browser - пошук NET-збірок). При відкритті вкладки видно кнопку Browse, яка вас виведе на теку зі збіркою.

Після того, як ви знайшли всі потрібні вам збірки, що містять потрібні простори імен, треба натиснути кнопку OK і перейти у ваше робоче застосування. У ньому ви за допомогою ключового слова using підключаєте знайдені простори, записуючи їх імена через крапку від імені збірки, наприклад

using app39_namespace.pbi.MyModul;

де app39_namespace - ім'я збірки (розширення exe не включати), а pbi.MyModul - ім'я простору імен, в якому визначені класи. Якщо вам незручно користуватися довгими іменами просторів імен ви можете дати їм псевдоніми (alias) за правилом:

using alias = довге_імя

і надалі працювати з псевдонімом як ім'ям простору імен. Все вищесказане відображене в трьох застосуваннях, приведених у лістингу 11.1, а результат роботи основного застосування показаний на рис. 11.4. Перше із застосувань створює простір імен з класом А, друге - з класом В, а третє працює з просторами, створеними в першому і другому застосуваннях.

Лістинг 11.1

// Перше застосування

using System;

namespace app39_namespace

{

namespace pbi.MyModul

{

public class A

{

public int A_a { get; set; }

}

} // Mymodul

class Program

{

public static void Main(string[] args)

{

Console.WriteLine("Hello World!");

// TODO: Implement Functionality Here

Console.Write("Press any key to continue...");

Console.ReadKey(true);

}

}

}

// Друге застосування

using System;

namespace app40_namespace_2

{

namespace pbi.MyModul2

{

public class B

{

public int B_b { get; set; }

}

} // MyModul2

class Program

{

public static void Main(string[] args)

{

Console.WriteLine("Hello World!");

// TODO: Implement Functionality Here

Console.Write("Press any key to continue...");

Console.ReadKey(true);

}

}

}

// Третє, головне застосування

using System;

// Ці модулі знаходяться у збірках і під'єднуються за посиланням із меню Project

// Можно використовувати справжні імена збірок, якщо вони не довгі:

// using app39_namespace.pbi.MyModul;

// using app40_namespace_2.pbi.MyModul2;

// Використання псевдоніма замість довгого імені

using MyModul = app39_namespace.pbi.MyModul;

using MyModul2 = app40_namespace_2.pbi.MyModul2;

namespace app41_namespace_main

{

class Program

{

public static void Main(string[] args)

{

Console.WriteLine("Обробка модулів, " + "створених різними джерелами\n");

// app39_namespace.pbi.MyModul.A a =

new app39_namespace.pbi.MyModul.A();

MyModul.A a = new MyModul.A();

a.A_a=5;

// app40_namespace_2.pbi.MyModul2.B b =

new app40_namespace_2.pbi.MyModul2.B();

MyModul2.B b = new app40_namespace_2.pbi.MyModul2.B();

b.B_b=6;

Console.Write("Робота з класами із різних" + "просторів імен\n");

Console.Write("Поле А_а = {0}, поле B_b = {1}\n", a.A_a, b.B_b);

Console.Write("Press any key to continue...");

Console.ReadKey(true);

}

}

}

а

б

Рис. 11.4. Використання просторів імен з різних збірок:

а, б - послідовність підключення просторів імен;

в - результат роботи основного застосування з

використанням просторів імен з різних збірок.

Тепер зрозуміло, чому шаблон застосування оформляється як namespace <ім’я_застосування>: після компіляції застосування набуває формат збірки. Якщо в ньому є деякі класи, функціональність яких корисна для інших застосувань, то таку збірку можна під’єнати до своєї програми за посиланням та отримувати з неї потрібну функціональність класів, що знаходяться в ній.

8