Дослідження технологій створення тривимірних графічних додатків на базі платформи dotNET

Размещено на http://www.allbest.ru/

"Дослідження технологій створення тривимірних графічних додатків на базі платформи dotNET"

тривимірний графічний додаток dotnet

Анотація

Метою дипломної роботи є дослідження технологій створення тривимірних графічних додатків на базі платформи dotNET. Як мова програмування для реалізації поставленого завдання була вибрана мова програмування С#, як середа розробки -Microsoft Visual Studio 2008.

Аннотация

Целью дипломной работы является исследование технологий создания трехмерных графических приложений на базе платформы dotNET. Как язык программирования для реализации поставленной задачи был выбран язык программирования C #, как среда разработки - Microsoft Visual Studio 2008.

Разделов 6, схем и рисунков 30, таблиц 5, библиографических ссылок 27, общий объем - 113.

The summary

The purpose of degree work is research technologies create three-dimensional image on a platform dotNET. As a programming language for implementation of the task was chosen programming language C #, as the development environment Microsoft Visual Studio 2008.

Sections 6, circuits and figures 30, tables 5, bibliographic references 27, total amount - 113.

Вступ

DirectX -- це набір API функцій, розроблених для вирішення завдань, пов'язаних з ігровим і відеопрограмуванням в операційній системі Microsoft Windows. Найширше використовується при написанні комп'ютерних ігор. Пакет засобів розробки DirectX під Microsoft Windows безкоштовно доступний на сайті Microsoft. На даний момент найновішою версією є DirectX 11. Часто, свіжі версії DirectX поставляються разом з ігровими додатками, оскільки DirectX API оновлюється достатньо часто, і версія, включена в ОС Windows часто є далеко не самою новою.

Managed DirectX -- це підтримка DirectX з керованого коду, тобто з програм, написаних на платформі dotNET і для неї. Спочатку ця технологія називалася DirectX dotNET, але пізніше була перейменована в Managed DirectX.

Бібліотека Managed DirectX розділена на наступні простори імен:

MICROSOFT.DIRECTX.DIRECT3D -- інтерфейси для реалізації 3D-графіки;

MICROSOFT.DIRECTX.DIRECTDRAW -- старі, але дуже добрі функції для роботи з 2D-поверхнями і відповідною графікою;

MICROSOFT.DIRECTX.DIRECTSOUND -- інтерфейси для роботи із звуком;

MICROSOFT.DIRECTX.DIRECTINPUT -- інтерфейси для роботи з пристроями введення.

Це основні простори, крім того, в managed DirectX є інтерфейси для реалізації засобів безпеки і підтримка мережі.

Всі ці інтерфейси можна використовувати в наступних мовах програмування:

· MICROSOFT VISUAL C#;

· MICROSOFT VISUAL BASIC .NET;

· MICROSOFT VISUAL C++;

· MICROSOFT JSCRIPT .NET.

Managed DirectX планувався для використання в Інтернеті для створення сервісів з підтримкою 3D-графіки тих, що розробляються на таких мовах, як C# і VB.NET.

Технологія Managed DirectX -- могутній засіб створення ігор. Уяви собі гру, написану C# у поєднанні з Managed DirectX. За заявами MS, програми .NET можуть виконуватися на будь-якій платформі за наявності відповідного .NET Framework, отже, ми одержуємо міжплатформену гру.

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

1. Постановка завдання

1.1 Найменування та галузь застосування

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

1.2 Підстава для створення

Підставою для розробки є наказ № 62С-01 від 29 жовтня 2008 р. по Криворізькому інституту КУЕІТУ.

Початок робіт: 31.10.08. Закінчення робіт: 01.06.09.

1.3 Характеристика розробленого програмного забезпечення

Як мова програмування для реалізації поставленого завдання була обрана мова програмування С#, як середа розробки - Microsoft Visual Studio 2008. До складу системи входять:

- BookWriter3D.exe - виконавчий файл системи;

- 3DTools.dll - бібліотеку взаемодії з DirectX

1.4 Мета й призначення

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

1.5 Загальні вимоги до розробки

Вимоги до програмного забезпечення:

· Робота в середовищі операційних систем Windows 2000/XP;

· Простота й зрозумілість інтерфейсу.

Мінімальні вимоги до апаратного забезпечення:

· IBM-сумісний комп'ютер, не нижче Pentium IІI, RAM-256Mb, SVGA-800*600*16bit;

· Вільний простір на жорсткому диску не менш 800 Мб;

· Додаткове програмне забезпечення: інсталяція DirectX

1.6 Джерела розробки

Джерелами розробки дипломної роботи є:

· довідкова література;

· наукова література;

· технічна література;

· програмна документація.

2. Особливості технологій розробки Windows додатків

2.1 Огляд основних технологій розробки Windows додатків

2.1.1 Програмування з використанням Win32/C

Спочатку під програмуванням під Windows малося на увазі програмування з використанням Windows Application Programming Interface (інтерфейсом прикладного програмування Windows, в 32-разрядних версіях Windows -- Win32 API). З використанням цієї технології було створено безліч цілком гідних додатків, проте навряд чи хто-небудь сперечатиметься з тим, що написання додатка з використанням лише Windows API -- це дуже трудомістке завдання.

Ще одна проблема полягає в тому, що С -- досить сувора по відношенню до програміста мова. Тим, хто створює додатки цією мовою програмування, доводиться уручну займатися управлінням пам'яттю, виконати розрахунки при використанні покажчиків і працювати з абсолютно неприродними з точки зору людської мови синтаксичними конструкціями. Крім того, в С недостатньо можливостей для об'єктно-орієнтованого програмування.

2.1.2 Програмування з використанням C++/MFC

C++ -- це величезний крок вперед відносно нових можливостей в порівнянні з початковою мовою С. В багатьох ситуаціях C++ цілком допустимо представити як об'єктно-орієнтовану надбудову над С. Така надбудова дозволяє використовувати переваги «стовпів об'єктно-орієнтованого програмування -- інкапсуляції, поліморфізму і спадкоємства. Проте програмісти, використовуючи C++, залишаються незахищеними від багатьох і часто небезпечних особливостей С++ (тими ж самими низькорівневими можливостями роботи з пам'яттю і важкими для сприйняття синтаксичними конструкціями).

Існує безліч бібліотек для C++, основне призначення яких -- полегшити написання додатків під Windows, надавши для цієї мети вже готові класи. Одна з найбільш поширених бібліотек -- це MFC (Microsoft Foundation Classes). MFC -- це додатковий рівень над Win32 API, який значно спрощує роботу програміста за рахунок використання готових класів, макросів і майстрів. Проте MFC -- це лише часткове вирішення проблеми. Навіть при використанні MFC програмістові доводиться працювати з складним для читання кодом, вельми небезпечним з точки зору можливих помилок.

2.1.3 Програмування з використанням Visual Basic

Люди завжди прагнуть зробити своє життя простішим. Підкоряючись цьому прагненню багато програмістів на C++ обернули свої погляди до набагато простішої і доброзичливішої мови, якою є Visual Basic (VB). Visual Basic дозволяє працювати з досить складними елементами інтерфейсу користувача, бібліотеками коду (наприклад, Сом-серверами) і засобами доступу до даних при мінімальних витратах часу і сил. Visual Basic в набагато більшому ступені, чим MFC, ховає від користувача виклики Win32 API і надає великий набір інтегрованих засобів швидкої розробки.

Проте в Visual Basic є і недоліки. Головний з них -- це набагато менші можливості, які надає ця мова, в порівнянні з C++ (це твердження справедливе, принаймні, для версій раніших, ніж VB.NET). Visual Basic -- це мова «для роботи з об'єктами», а не об'єктно-орієнтована мова в звичайному розумінні цього слова. У Visual Basic немає класичного спадкоємства, немає підтримки створення класів, що параметризуються, немає власних засобів створення багатопоточних додатків -- і цей список можна продовжувати ще довго.

2.1.4 Програмування з використанням Java

Мова програмування Java -- це повністю об'єктно-орієнтована мова, яка відносно синтаксису багато що успадкувала від C++ . Звичайно, переваги Java далеко не вичерпуються міжплатформеностю. Мова Java в синтаксичному відношенні простіша і логічніша, ніж C++. Java як платформа надає в розпорядження програмістів велику кількість бібліотек (пакетів), в яких міститься велика кількість описів класів і інтерфейсів на всі випадки життя. З їх допомогою можна створювати стовідсоткові додатки Java з можливістю звернення до баз даних, підтримкою передачі поштових повідомлень, з клієнтською частиною, якою необхідний лише web-браузер, або на зворот, з клієнтською частиною, що володіє витонченим інтерфейсом.

Java -- це дуже елегантна і красива мова. Проте при його використанні проблем також уникнути не вдається. Одна з серйозних проблем полягає в тому, що при створенні складного додатку на Java нам доведеться використовувати лише цю мову для створення всіх частин цього додатку. У Java передбачено не так вже багато засобів для міжмовної взаємодії (що зрозуміло, зважаючи на призначення Java бути єдиною багатоцільовою мовою програмування). Але в реальному світі існують мільйони рядків готового коду, які хотілося б інтегрувати з новими додатками на Java. Проте це зробити дуже важко.

Java -- це далеко не ідеальна мова в багатьох ситуаціях. Простий приклад -- якщо ми спробуємо створити лише Java додаток, що активно працює з 3d-графікой, швидше за все, працювати такий додаток буде не дуже швидко. Для роботи з 3d-графікой краще використовувати код, написаний на мові з розвиненішими низькорівневими можливостями (наприклад, на C++). Проте інтегрувати такий код з кодом на Java буде дуже складно. Оскільки можливості для звернення до API компонентів, створених на інших мовах, в Java дуже обмежені, говорити про реальну міжмовну взаємодію на основі Java не доводиться.

2.1.5 Програмування з використанням СОМ

Сучасний стан справ такий, що якщо програміст не будуєте Java-додатки, то велика вірогідність, що програміст освоює технологію Microsoft Component Object Model (COM). Сом-технологія проголошує: «Якщо ви створюєте класи в точній відповідності з вимогами СОМ, то у вас вийде блок повторно використовуваного програмного коду».

Краса двійкового Сом-сервера полягає в тому, що до нього можна звертатися з будь-якої мови. Наприклад, програмісти, використовуючи C++, можуть створювати класи, які можна буде використовувати з додатка на Vbasic. Програмісти, використовуючи Delphi, можуть використовувати класи, створені на С++ и т.д. Проте в міжмовній взаємодії СОМ є свої обмеження. Наприклад, немає можливості провести нового типа СОМ від того, що існує. Для повторного використання існуючих типів СОМ доведеться використовувати інші, набагато менш надійні і ефективні засоби.

Велика перевага СОМ полягає в тому, що програміст може не піклуватися про фізичне місцезнаходження компонентів. Такі засоби, як Application Identifiers (Appids, ідентифікатори додатків), стаби (stubs), проксі, середа виконання СОМ, дозволяють уникати при зверненні до компонентів по мережі необхідності поміщати в додаток код для роботи з сокетами, викликами RPC і іншими низькорівневими механізмами. Досить поглянути на такий код на Visual Basic 6.0 для клієнта СОМ:

Dim с as New MyCOMClass. Місцезнаходження класу визначається через AppID c.DoSomeWork.

Об'єктна модель СОМ використовується дуже широко. Проте внутрішній устрій компонентів вельми складний. Щоб навчитися знатися на нім доведеться витратити принаймні декілька місяців. Написання додатків з використанням Сом-компонентів можна спростити, використовуючи стандартні бібліотеки, наприклад біблітеку Active Template Library (ATL) зі своїм набором готових класів, шаблонів і макросів.

Деякі мови (наприклад, Visual Basic) також дозволяють приховати складність інфраструктури СОМ. Проте всіх складнощів уникнути все одно не вдається. Наприклад, навіть якщо працювати з відносно простим і підтримуючим COM Visual Basic, доведеться вирішувати не завжди прості питання, пов'язані з реєстрацією компонентів на комп'ютері і розгортанням додатків.

2.1.6 Програмування з використанням Windows DNA

Картина буде неповною, якщо не взяти до уваги як Інтернет. За декілька останніх років Microsoft додала в свої операційні системи велику кількість засобів для роботи з цією середою, у тому числі і засоби, покликані допомогти в створенні Інтернет-додатків. Проте, побудова закінченого web-додатки з використанням технології Windows DNA (Distributed internet Architecture -- розподілена міжмережева архітектура) до цих пір залишається вельми складним завданням.

Значна частина складнощів виникає тому, що Windows DNA вимагає використання різнорідних технологій і мов (ASP, HTML, XML, Javascript, Vbscript, COM ( ), ADO і т. д.). Одна з проблем полягає в тому, що синтаксично всі ці мови і технології дуже мало схожі один на одного. Наприклад, синтаксис JavaScript більше схожий на синтаксис С++, тоді як VbScript є підмножиною Visual Basic. Сом-сервери, призначені для роботи в середі виконання СОМ, створені на основі здійснений інших підходів, ніж Asp-сторінки, які до них звертаються. Кінцевим результатом є лякаюче змішення технологій. Окрім всього іншого, в кожній мові, яка входить до складу Windows DNА, передбачена своя система типів, що також не є джерелом великої радості для програмістів. Наприклад, тип даних іnt у JavaScript -- це не те ж саме, що іnt у С++, який, у свою чергу, відмінний від іnteger у Visual Basic.

2.2 Рішення .NET

Один з головних принципів .NET звучить так: «Змінюйте все, що хочете, звідки вам завгодно». .NET -- це абсолютно нова модель для створення додатків під Windows (а в майбутньому, мабуть, і під іншими операційними системами). Ось коротке перерахування основних можливостей .NET:

· Повні можливості взаємодії з існуючим кодом.

· Повна і абсолютна міжмовна взаємодія. На відміну від класичного СОМ, в .NET підтримуються міжмовне спадкоємство, міжмовна обробка виключень і міжмовна відладка.

· Спільна середа виконання для будь-яких додатків .NET, незалежно від того, на яких мовах вони були створені. Один з важливих моментів при цьому -- те, що для всіх мов використовується один і той же набір вбудованих типів даних.

· Бібліотека базових класів, яка забезпечує приховування всіх складнощів, пов'язаних з безпосереднім використанням викликів API, і пропонує цілісну об'єктну модель для всіх мов програмування, що підтримують .NET,

· Спрощення процесу розгортання додатка. У .NET немає необхідності реєструвати подвійні типи в системному реєстрі. Більш того .NET дозволяє різним версіям одного і того ж модуля DLL мирно співіснувати на одному комп'ютері.

2.2.1 Основи CLS

CLS (Common Language Specification) - загальна специфікація мов програмування. Це набір конструкцій і обмежень, які є керівництвом для творців бібліотек і компіляторів в середовищі .NET Framework. Бібліотеки, побудовані відповідно до CLS, можуть бути використані з будь-якої мови програмування, підтримуючого CLS. Мови, відповідні CLS (до їх числа відносяться мови Visual C# 2.0, Visual Basic, Visual C++), можуть інтегруватися один з одним. CLS - це основа міжмовної взаємодії в рамках платформи Microsoft .NET.

Немає необхідності доводити, що одні і ті ж програмні конструкції в різних мовах виглядають абсолютно по-різному. Наприклад, в С# і Delphi об'єднання рядків (конкатенація) проводиться за допомогою оператора плюс "+", а в Visual Basic для цієї мети використовується амперсант "&". Для середовища виконання .NET така різниця в синтаксисі абсолютно байдужа: все одно відповідні компілятори створять однаковий код IL. Проте мови програмування відрізняються не тільки синтаксисом, але і можливостями. Наприклад, в одних мовах програмування дозволено перевантаження операторів, а в інших -- ні. Одні мови можуть використовувати беззнакові типи даних, в інших такі типи даних не передбачені. Тому потрібні деякі єдині правила для всіх мов .NET. Якщо їм слідувати, то програмні модулі, написані на різних мовах, нормально взаємодіятимуть один з одним. Такий набір правил визначений в універсальній специфікації мови (CLS).

Набір правив CLS не тільки гарантує нормальну взаємодію блоків коду, створених на різних мовах, але і визначає мінімальні вимоги, які пред'являються до будь-якого компілятора .NET. Необхідно пам'ятати, що CLS -- це лише частина тих можливостей, які визначені в CTS. Правилам CLS повинні задовольняти і інструментальні засоби середовища розробки -- якщо ми хочемо забезпечити міжмовну взаємодію, вони повинні генерувати тільки такий код, який відповідає вимогам CLS. У кожного правила CLS є назва (наприклад, CLS Rule 6). Ось приклад один з найважливіших правил -- правило номер 1.

Правило 1. Правила CLS відносяться тільки до частин типу, призначених для взаємодії за межами збірки, в якій вони визначені.

З цього правила виходить, що при реалізації якого-небудь типу можна скільки завгодно порушувати правила CLS -- це ні на що не вплине. Наприклад, можна створити додаток .NET, який взаємодіє із зовнішнім світом за допомогою трьох класів, і в кожному з цих класів тільки одна функція. Правилам CLS в цьому випадку повинні задовольняти тільки три цих функції (область видимості, угоди про іменування, типи параметрів і т.д.). У внутрішній реалізації цих функцій, класів або додатку в цілому може бути скільки завгодно відступів від правил CLS.

2.2.2 Основи CLR

CLR (Common Language Runtime) - Середовище Часу Виконання або Віртуальна Машина. Забезпечує виконання збірки. Основний компонент .NET Framework. Під Віртуальною Машиною розуміють абстракцію інкапсульованої (відособленої) керованої операційної системи високого рівня, яка забезпечує виконання (керованого) програмного коду.

Керований код - програмний код, який при своєму виконанні здатний використовувати служби, що надаються CLR.

Відповідно, некерований код подібною здатністю не володіє. Про особливості керованого коду можна судити по переліку завдань, рішення яких покладається на CLR:

· Управління кодом (завантаження і виконання).

· Управління пам'яттю при розміщенні об'єктів.

· Ізоляція пам'яті додатків.

· Перевірка безпеки коду.

· Перетворення проміжної мови в машинний код.

· Доступ до метаданих (розширена інформація про типи).

· Обробка виключень, включаючи міжмовні виключення.

· Взаємодія між керованим і некерованим кодами (у тому числі і COM-об'єктами).

· Підтримка сервісів для розробки (профілізація, відладка і т.д.).

Коротше, CLR - це набір служб, необхідних для виконання керованого коду

Сама CLR складається з двох головних компонентів: ядра (mscoree.dll) і бібліотеки базових класів (mscorlib.dll). Наявність цих файлів на диску - вірна ознака того, що на комп'ютері, принаймні, була зроблена спроба установки платформи .NET.

Ядро середовища виконання реалізоване у вигляді бібліотеки mscoree.dll. При компоновці збірки в неї вбудовується спеціальна інформація, яка при запуску додатку (EXE) або при завантаженні бібліотеки (звернення до DLL з некерованого модуля - виклик функції LoadLibrary для завантаження керованої збірки) приводить до завантаження і ініціалізації CLR. Після завантаження CLR в адресний простір процесу, ядро середовища виконання проводить наступні дії:

· знаходить розташування збірки;

· завантажує збірку в пам'ять;

· проводить аналіз вмісту збірки (виявляє класи, структури, інтерфейси);

· проводить аналіз метаданих;

· забезпечує компіляцію коду на проміжній мові (IL) в платформозалежні інструкції (асемблерний код);

· виконує перевірки, пов'язані із забезпеченням безпеки;

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

· FCL (.NET Framework Class Library) - відповідна CLS-специфікації об'єктно-орієнтована бібліотека класів,

· інтерфейсів і системи типів (типів-значень), які включаються до складу платформи Microsoft .NET.

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

NET бібліотека класів є другим компонентом CLR.

NET FCL можуть використовувати ВСЕ .NET-приложения, незалежно від призначення архітектури використовуваного при розробці мови програмування, і зокрема:

· вбудовані (елементарні) типи, представлені у вигляді класів (на платформі .NET все побудовано на структурах або класах);

· класи для розробки графічного призначеного для користувача інтерфейсу (Windows Form);

· класи для розробки web-додатків і web-служб на основі технології ASP.NET (Web Forms);

· класи для розробки XML і Internet-протоколів (FTP, HTTP, SMTP, SOAP);

· класи для розробки додатків, що працюють з базами даних (ADO .NET) і багато що інше.

Рис.2.1 Послідовність виконання програм в середовищі CRL

2.2.3 Стандартна система типів CTS

Стандартна система типів (CTS) -- це всеосяжна специфікація, яка визначає, яким чином який-небудь тип (клас, структура, інтерфейс, вбудований тип даних і т.д.) повинен бути сформований для його правильного сприйняття середовищем виконання .NET. Система CTS описує синтаксичні конструкції (наприклад, перевантаження операторів), які можуть підтримуватися, а можуть і не підтримуватися конкретною мовою програмування .NET. Якщо необхідно створювати сбірки, які повинні використовуватися всіма мовами програмування .NET, то при створенні типів доведеться слідувати правилам стандартної системи типів.

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

Крім класів в CTS також представлені і структури. У першому наближенні структури можна розглядати як спрощені різновиди класів. Структури CTS можуть мати будь-яку кількість конструкторів з параметрами (конструктор без параметрів зарезервований). За допомогою конструкторів з параметрами можна встановити значення будь-якого поля структури у момент створення цього об'єкту. Всі структури CTS проведені від єдиного базового класу System.ValueType.

Цей базовий клас визначає структуру як тип даних для роботи тільки із значеннями, але не з посиланнями. У структурі може бути будь-яка кількість інтерфейсів.

Проте структури не можуть бути успадковані від решти типів даних і вони завжди є закритими -- іншими словами, вони не можуть виступати як базові з метою їх спадкоємства.

Члени типів CTS

Раніше було відмічено, що класи і структури можуть мати будь-яку кількість членів. Член -- це або метод, або властивість, або поле, або подія. Для кожного члена в .NET існує набір характеристик. Наприклад, будь-який член в .NET характеризується своєю областю видимості (public, private, protected і т.д.). Член можна оголосити як абстрактний, щоб скористатися можливостями поліморфізму при роботі з похідними класами. Члени можуть бути статичними (такі члени можуть спільно використовуватися всіма об'єктами даного класу) і звичайними -- що належать тільки одному об'єкту даного класу.

Перерахування CTS

Перерахування -- це зручна програмна конструкція, яка дозволяє об'єднувати пари "ім'я-значення" в групи, до яких потім можна звернутися на ім'я груп.

У CTS всі перерахування є похідними від єдиного базового класу System.Enum. Цей базовий клас містить безліч корисних членів, які допоможуть в роботі з парами "ім'я-значення".

Делегати CTS

Делегати в світі .NET -- це безпечні для типів вказівники на функції. Але на відміну від інших мов програмування, делегат .NET це вже не просто адреса в оперативній пам'яті, а клас, похідний від базового класу Multicast-Delegate. Делегати дуже корисні в тих ситуаціях, коли потрібно, щоб одна суть передала виклик іншої суті. Делегати -- це наріжний камінь в технології обробки подій в середовищі.NET.

Вбудовані типи даних CTS

У середовищі .NET передбачений багатий набір вбудованих типів даних, причому цей набір використовується всіма мовами програмування .NET. Назви типів даних в різних мовах .NET можуть виглядати по-різному, але ці назви всього лише псевдоніми для вбудованих системних типів даних .NET, визначених в бібліотеці базових типів.

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

Після знайомства із загальниймовним виконуючим середовищем .NET звернемося до особливостей бібліотеки базових класів .NET. Важливість бібліотек коду очевидна.

Наприклад, бібліотека MFC визначає набір класів C++ для створення форм, діалогових вікон, меню, панелей управління і т.д. В результаті програмісти можуть не займатися створенням того, що вже давно зроблене, а зосередитися на унікальних аспектах застосування, що розробляється ними. Аналогічні засоби існують в Delphi, Visual Basic, Java і в решті всіх мов програмування.

Проте на відміну від цих мов програмування, в мовах для середовища .NET не існує бібліотеки базових класів тільки для однієї мови. Натомість розробники використовують бібліотеку базових типів для всього середовища .NET, а для організації типів усередині цієї бібліотеки використовується концепція просторів імен.

Ефективність роботи програміста, що використовує .NET, безпосередньо залежить від того, наскільки добре він знайомий з тим безліччю типів, які визначені в просторах імен бібліотеки базових класів. Найважливіший простір імен називається System. У нім визначені класи, які забезпечують найважливіші функції, і жодне застосування не обходиться без використання цього простору імен.

Простір імен -- це спосіб організації типів (класів, перерахувань, інтерфейсів, делегатів і структур) в єдину групу. У одному просторі імен зазвичай об'єднуються взаємозв'язані типи. Наприклад, в просторі імен System.Drawing міститься набір типів, які покликані допомогти в організації виведення зображень на графічний пристрій. У .NET передбачені простори імен для організації типів, розрахованих на роботу з базами даних, мережею, багатопотоковістю, захистом даних і безлічі інших завдань.

2.2.5 Основи MSIL

(Microsoft Intermediate Language) - проміжна мова платформи Microsoft .NET. Початкові тексти програм для .NET-приложений пишуться на мовах програмування, відповідних специфікації CLS. Для таких мов може бути побудований перетворювач в MSIL. Таким чином, програми на цих мовах можуть транслюватися в проміжний код на MSIL.

Завдяки відповідності CLS, в результаті трансляції програмного коду, написаного на різних мовах, виходить сумісний IL-код.

Фактично MSIL є асемблером віртуального процесора.

МЕТАДАНІ - при перетворенні програмного коду в MSIL також формується блок метаданих, який містить інформацію про даних, використовуваних в програмі. Фактично це набори таблиць, які включають інформацію про типи даних, визначуваних в модулі (про типи даних, на які посилається даний модуль). Раніше така інформація зберігалася окремо. Наприклад, додаток міг включати інформацію про інтерфейси, яка описувалася на Interface Definition Language (IDL). Тепер метадані є частиною керованого модуля.

Зокрема, метадані використовуються для:

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

· верифікації коду в процесі виконання модуля;

· управління динамічною пам'яттю (звільнення пам'яті) в процесі виконання модуля;

· забезпечення динамічної підказки (IntelliSence) при розробці програми стандартними інструментальними засобами (Microsoft Visual Studio .NET) на основі метаданих.

Мови, для яких реалізований переклад на MSIL:

· Visual Basic,

· Visual C++,

· Visual C# 2.0,

· і ще багато інших мов.

2.2.6 Поняття збірки і виконувані модулі

Виконуваний модуль - незалежно від компілятора (і вхідної мови) результатом трансляції .NET-додатку є керований виконуваний модуль (керований модуль). Це стандартний переносимий виконуваний (PE - Portable Executable) файл Windows.

Однією з особливостей керованого коду є наявність механізмів, які дозволяють працювати з керованими даними. Керовані дані - об'єкти, які в ході виконання коду модуля розміщуються в керованій пам'яті (у керованій купі) і знищуються складальником сміття CLR. Дані C#, Visual Basic і JScript .NET є керованими за замовчанням. Виконуваний модуль - незалежно від компілятора (і вхідної мови) результатом трансляції .NET-додатку є керований виконуваний модуль (керований модуль). Це стандартний переносимий виконуваний (PE - Portable Executable) файл Windows. Однією з особливостей керованого коду є наявність механізмів, які дозволяють працювати з керованими даними.

Керовані дані - об'єкти, які в ході виконання коду модуля розміщуються в керованій пам'яті (у керованій купі) і знищуються прибиральником сміття CLR. Дані C#, Visual Basic і JScript .NET є керованими за замовчанням.

Дані C# також можуть бути помічені як некеровані.

Збірка (Assembly) - базовий будівельний блок додатку в .NET Framework. Керовані модулі об'єднуються в складки. Збірка є логічним угрупуванням одного або декількох керованих модулів або файлів ресурсів. Керовані модулі у складі складок виконуються в Середовищі Часу Виконання (CLR). Збірка може бути або виконуваним застосуванням (при цьому вона розміщується у файлі з розширенням .exe), або бібліотечним модулем (у файлі з розширенням .dll). При цьому нічого спільного із звичайними (старого зразка!) виконуваними застосуваннями і бібліотечними модулями збірка не має.

Декларація збірки (Manifest) - складова частина збірки. Це ще один набір таблиць метаданих, який:

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

- визначає вхідні в склад файли (по імені і хешу);

- указує типи і ресурси, що існують в збірці, включаючи опис тих, які експортуються із збірки;

- перераховує залежності від інших складок;

- указує набір має рацію, необхідних збірці для коректної роботи.

Ця інформація використовується в період виконання для підтримки коректної роботи додатку.

3. Теоретичне дослідження роботи з графікою засобами Direct3D

3.1 Огляд бібліотеки DirectX 9.0

Створення складних і високопродуктивних мультимедійних програм вимагає безпосереднього доступу до апаратних ресурсів. Бібліотека DirectX містить набір низькорівневих програмних інтерфейсів, надаючий такий доступ Windows-програмістам. Якщо ви збираєтеся створити захоплюючу мережеву гру, мультимедійний додаток або хранитель екрану з використанням тривимірної графіки -- безумовно, варто почати з розгляду можливостей DirectX.

За час свого існування бібліотека DirectX зазнала великі зміни. Ми розглядатимемо можливості найсучаснішої (на момент написання цієї книги) версії API DirectX версії 9.0. Крім різних технологічних нововведень, що відображають появу нових пристроїв, в цій бібліотеці вперше представлений managed-інтерфейс, що дозволяє легко використовувати DirectX в програмах для платформи .NET Framework.

DirectX 9.0 складається з наступних компонентів:

1. DirectX Graphics: поєднує в собі можливості інтерфейсів DirectDraw і Direct3D попередніх версій, призначених для програмування графіки. Ми вивчатимемо можливості саме цього компоненту.

2. DirectInput: надає можливості по обробці призначеного для користувача введення з найрізноманітніших пристроїв таких, як ігрові маніпулятори і "миші".

3. DirectPlay: містить засоби для створення мережевих додатків (наприклад, розрахованих на багато користувачів ігор).

4. DirectSound, DirectMusic і DirectX Media Objects (ці компоненти у версії 9.0 об'єднані під назвою DirectX Audio): надають засоби програмування звуку і MIDI-музики.

5. DirectShow: засоби для захоплення і відтворення мультимедійних потоків. У версії 9.0 вперше з'явилися DirectShow Editing Services (DES): набір об'єктів, що дозволяють легко створювати програми для нелінійного монтажу або програвачів аудіо і відео із застосуванням real-time ефектів і красивих переходів між роликами.

6. DirectSetup: програмний інтерфейс, що дозволяє настроювати установку DirectX на системах користувачів.

7. DirectX Diagnostics: програмний інтерфейс для діагностики драйверів і устаткування.

Як бачимо, DirectX надає засоби для створення найрізноманітніших графічних і мультимедійних додатків, а також включає додаткові програмні інтерфейси (на відміну від свого основного конкурента, бібліотеки OpenGL, орієнтованої виключно на графіку).

3.2 Пакет DirectX 9.0 SDK

Для успішного запуску космічної «стрелялки», що використовує можливості Direct3D, цілком досить встановити пакет DirectX Runtime, який містить набір динамічних бібліотек, драйверів пристроїв і конфігураційних файлів. Цей набір файлів займає близько 36 мегабайт у повному складі, і його часто можна знайти на компакт-дисках з драйверами для нових відеокарт або з іграми останнього покоління.

Але для самостійного створення програм з використанням DirectX 9 його абсолютно недостатньо. Для цього необхідний пакет DirectX 9.0 SDK, що знаходиться у вільному доступі на сайті Microsoft.

Ось що входить до складу цього пакету:

· Набір заголовних файлів і бібліотек для компіляторів C++.

· Складки Managed DirectX для використання з .NET-компиляторами.

· Велика кількість документації у форматі Compiled HTML Help.

· Набір прикладів і покрокових інструкцій, організованих в цілу оболонку Sample Browser по категоріях і мовах розробки (див. рис 3.1).

Рис 3.1 Оболонка для доступу до прикладів і покрокового керівництва DirectX

"Майстри" (AppWizard) для створення стартових додатків в середовищах Visual С++, Visual C# і Visual Basic.NET.

Допоміжні утиліти для редагування файлів DirectX, проглядання системних параметрів і спостереження за системою.

Власне середовище виконання -- пакет DirectX Runtime в двох версіях: налагоджувальної (Debug) і остаточної (Retail). Налагоджувальна версія дещо повільніше, але містить додаткові перевірки, що дозволяють відловлювати помилки на етапі розробки. Між двома цими версіями можна легко перемикатися.

Запустивши инсталлятор DirectX, можна вибрати, які компоненти пакету потрібно встановити на комп'ютер (рис 3.2). Рекомендується вибрати повну інсталяцію.



Рис 3.2 Установка DirectX 9 SDK

3.3 Створення програм з використанням DirectX Graphics

Почнемо з написання двох програм: для Windows і середовищ .NET. Виконавши покрокові описи, ми в результаті одержимо повноцінні програми, що використовують компонент DirectX Graphics для створення тривимірного зображення

3.3.1 Написання програм мовою C++

На жаль, майстер AppWizard, що поставляються у складі пакету DirectX 9.0 SDK, призначені тільки для використання в середовищах Visual Studio 6.0 і 7.0. Тому ми приводимо інструкцію, що дозволяє підключити DirectX SDK до пакету Microsoft Visual Studio .NET 2003 (7.1).

Отже, запустіть середовище Visual Studio і створіть новий проект Win32 Project (рис 3.3). Привласніть йому ім'я (у нашому прикладі - DX_Sample1), виберіть опцію Empty Project і підтвердіть створення проекту.



Рис 3.3 Створення нового проекту на C++

Тепер необхідно додати в проект новий файл .cpp. Для цього в меню Project виберіть пункт Add New Item. і знайдіть серед всіляких елементів значок C++ File (.cpp). Файлу також необхідно привласнити ім'я (наприклад, Hello.cpp), після чого можна приступати до «начинки».

3.3.2 Настройка середовища. Заголовні файли і бібліотеки

Перш за все, необхідно переконатися, що середовище Visual Studio правильно настроєне для компіляції програм, що використовують компоненти DirectX 9 SDK. Для цього зайдіть в пункт меню Tools - Options і знайдіть в лівому списку папку Projects. Розкрійте її і виберіть пункт VC++ Directories.

Потрібно переконатися, що в переліку шляхів до заголовних файлів (Include files) присутній рядок з вказівкою відповідного каталога DirectX SDK. Якщо ж такого рядка немає, необхідно додати її самостійно. У нашому прикладі (рис 3.4) це G:\dx9sdk\Include.



Рис 3.4 Настройка шляхів до заголовних файлів і бібліотек DirectX

Так само настроюється шлях до бібліотек DirectX. Для цього необхідно вибрати з випадного списку пункт Library files і додати в перелік рядок з вказівкою каталога Lib. Важливо, щоб шлях до каталогів dx9sdk/include і dx9sdk/lib стояв в списку раніше аналогічних каталогів (наприклад, від Platform SDK). Ну що ж, тепер компілятор знатиме, в якому місці шукати файли заголовків і бібліотек -- самий час вказати їх. Додайте у файл Hello.cpp наступні рядки:

#include <d3d9.h>

#include <d3dx9mesh.h>

#pragma comment(lib, "d3d9.lib")

#pragma comment(lib, "d3dx9.lib")

Ці рядки означають, що ми використовуватимемо як бібліотеку Direct3D, так і бібліотеку допоміжних компонентів Direct3D Extension (D3DX), в якій містяться функції, що полегшують програмування графіки.

3.3.3 Клас додатку і функція WinMain

Для створення програми застосуємо об'єктно-орієнтований підхід. Створимо клас додатку, в який помістимо функції ініціалізації і очищення DirectX, а також код побудови зображення.

Назвемо цей клас SampleApplication :

class SampleApplication

{

IDirect3D9 *pD3D;

IDirect3DDevice9 *pDevice;

ID3DXMesh *pTeapot;

HWND hWnd;

static LRESULT WINAPI MsgProc(HWND, UINT, WPARAM, LPARAM);

bool CreateMainWindow();

void CreateTeapot();

public:

SampleApplication():

pD3D(NULL), pDevice(NULL), pTeapot(NULL), hWnd(NULL){

bool InitD3D();

void CleanupD3D();

void Render();

void MessagePump();

};

Клас зберігає ресурси Direct3D, які йому знадобляться для роботи, і дескриптор головного вікна додатку. Крім того, він надає допоміжні функції ініціалізації, очищення і управління чергою повідомлень Windows.

Звернемо увагу, що метод MsgProc є статичним. Це необхідно для коректної обробки Windows-повідомлень усередині класу. Але усередині статичного методу не можна звертатися до полів класу, оскільки невідомо, до якого саме екземпляру йде звернення. Для вирішення цієї проблеми застосований простий прийом: описаний глобальний екземпляр об'єкту SampleApplication. Всі звернення ззовні проводитимуться до полів цього об'єкту.

При всій простоті цей спосіб страждає істотним недоліком: у програмі може існувати тільки один екземпляр такого класу. Втім, для класу додатку це не дуже істотно. Як буде показано далі .NET-розробники не повинні вдаватися до таких хитрувань для обробки повідомлень.

Отже, додамо оголошення глобального екземпляра додатку і функції WinMain :

static SampleApplication g_App;

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)

{

if(g_App.InitD3D())

{

g_App.MessagePump();

g_App.CleanupD3D();

}

return 0;

}

Виконання WinMain починається із спроби ініціалізації Direct3D. У разі успіху програма входить в цикл обробки повідомлень, а після його завершення виконує очищення Direct3D.

Це єдина глобальна функція в програмі, вся решта функцій буде методами класу SampleApplication.

3.3.4 Створення вікна

Як буде показано трохи нижче, метод InitD3D спочатку створює головне вікно додатку за допомогою виклику CreateMainWindow. Ось текст цього методу :

bool SampleApplication::CreateMainWindow()

{

// Реєстрація класу вікна

WNDCLASSEX wc = { sizeof(WNDCLASSEX) CS_CLASSDC,

MsgProc, 0L, 0L

GetModuleHandle(NULL), NULL, NULL

NULL, NULL

"Direct3D Class", NULL };

RegisterClassEx( &wc );

// Створення вікна додатку

hWnd = CreateWindow( "Direct3D Class",

"Direct3D для чайників"

WS_OVERLAPPEDWINDOW,

100, 100, 400, 300

GetDesktopWindow(), NULL

wc.hInstance, 0 );

if(!hWnd)

{

MessageBox(0, "Помилка створення головного вікна"

0 MB_OK|MB_ICONSTOP);

return false;

}

return true;

}

Як і в звичайному Windows-додатку, спочатку відбувається реєстрація класу вікна, в якій необхідно, зокрема, вказати процедуру обробки повідомлень (ось і став в нагоді статичний метод MsgProc) і ім'я класу (у нашому прикладі -- «Direct3D Class»). Потім створюється головне вікно додатку з розмірами 400x300 пикселов. У разі помилки видається діагностичне повідомлення.

3.3.5 Обробка повідомлень

Метод MessagePump «прокачує» Windows-повідомлення, що поступають в програму. Крім реакції на необхідні події (наприклад, закриття вікна), це дозволяє брати участь в кооперативній багатозадачності Windows і понизити навантаження на процесор. Початковий код методу приведений в лістингу.

void SampleApplication::MessagePump()

{

MSG msg;

while(GetMessage(&msg, 0, 0, 0))

{

TranslateMessage(&msg);

DispatchMessage(&msg);

}

}

Метод MsgProc нашого простого додатку обробляє тільки два повідомлення: WM_DESTROY (посилане вікну при його закритті) і WM_PAINT (що сигналізує про необхідність перемальовування).

LRESULT WINAPI SampleApplication::MsgProc(

HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)

{

g_App.hWnd = hWnd;

switch( msg )

{

case WM_DESTROY:

PostQuitMessage( 0 );

return 0;

case WM_PAINT:

{

PAINTSTRUCT ps;

BeginPaint(hWnd &ps);

g_App.Render();

EndPaint(hWnd &ps);

return 0;

}

}

return DefWindowProc(g_App.hWnd, msg, wParam, lParam);

}

До стандартної обробки повідомлення WM_PAINT ми додали тільки виклик методу Render для побудови тривимірного зображення.

Але, перш ніж використовувати бібліотеку Direct3D, необхідно її ініціалізувати. Розглянемо відповідні методи класу SampleApplication.

3.3.6 Ініціалізація і очищення бібліотеки

Код методу InitD3D спочатку створює головне вікно додатку викликом CreateMainWindow. У разі успіху програма приступає до ініціалізації бібліотеки DirectX.

Спершу намагаємося створити об'єкт Direct3D -- стартову крапку для зручної ініціалізації компонентів Direct3D. Для цього викличемо функцію Direct3DCreate9 з константою D3D_SDK_VERSION як параметр. Якщо цей виклик завершиться невдачею, на комп'ютері відсутня підтримка DirectX потрібної нам версії, і далі продовжувати безглуздо.

Якщо ж функція повернула створений об'єкт Direct3D, то використовуємо його для створення і ініціалізації графічного пристрою, викликавши у нього метод CreateDevice з необхідними параметрами (ми повернемося до розгляду ініціалізації нижче).

Крім того, нам потрібен об'єкт, що відображається. Для прикладу використовуємо функцію D3DXCreateTeapot бібліотеки D3DX, яка дозволяє створити готовий тривимірний об'єкт, що моделює чайник. Відповідний символ для початку вивчення тривимірної графіки, чи не так? :)

І, нарешті, після успішної ініціалізації об'єктів DirectX, показуємо головне вікно. Тепер додаток зможе коректно перемальовувати його вміст, використовуючи Direct3D.

Текст функції ініціалізації приведений в лістингу:

bool SampleApplication::InitD3D()

{

if(!CreateMainWindow())

return false;

pD3D = Direct3DCreate9(D3D_SDK_VERSION);

if(!pD3D)

return false;

D3DPRESENT_PARAMETERS params;

ZeroMemory( &params, sizeof(params));

params.Windowed = TRUE;

params.SwapEffect = D3DSWAPEFFECT_DISCARD;

params.BackBufferFormat = D3DFMT_UNKNOWN;

HRESULT hr = pD3D->CreateDevice(

D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd

D3DCREATE_SOFTWARE_VERTEXPROCESSING,

&params &pDevice);

if(FAILED(hr))

{

pD3D->Release();

pD3D = 0;

return false;

}

D3DXCreateTeapot(pDevice &pTeapot, 0);

ShowWindow(hWnd SW_SHOWDEFAULT);

UpdateWindow(hWnd);

return true;

}

Після закриття вікна функція викликає метод додатку для коректного очищення всіх виділених ресурсів Direct3D. Як буде показано в наступному розділі, об'єкти DirectX підкоряються правилам COM, і для їх звільнення також необхідно використовувати метод Release :

void SampleApplication::CleanupD3D()

{

if(pTeapot)

pTeapot->Release();

if(pDevice)

pDevice->Release();

if(pD3D)

pD3D->Release();

}

Як вже мовилося, для відладки складних додатків DirectX буває корисно встановити Debug-версію бібліотеки, що входить до складу DirectX 9.0 SDK. Вона не тільки дозволяє контролювати правильність параметрів методів, але і видає діагностичне повідомлення при завершенні програми, якщо ви забудете видалити який-небудь об'єкт.

3.3.7 Побудова зображення

Для створення зображення обробник повідомлення WM_PAINT викликає метод Render. Настав час познайомитися і з ним.

Спочатку заповнимо область висновку синім кольором, викликавши метод Clear пристрою. Потім приступимо до підготовки зображення.

Всі команди виведення графічних об'єктів повинні обрамлятися операторними дужками BeginScene/EndScene для коректного відробітку конвейєра висновку.

Спочатку для сцени задається джерело світла і характеристики матеріалу, з якого виготовлений чайник. Потім до пристрою застосовується матриця світового перетворення (чайник злегка зменшується і відсовується по осі Z). Нарешті, виводимо довгождане зображення. Об'єкти Mesh бібліотеки D3DX самі уміють відображати себе в пристрій Direct3D, досить викликати метод DrawSubset. Насправді, як ми переконаємося пізніше, вони складаються з безлічі дрібних тривимірних примітивів (як правило, трикутників), але угрупування примітивів в об'єкт сильно полегшить нам завдання. Після завершення виведення сцени необхідно викликати метод EndScene, який і приведе до побудови зображення у вторинному буфері. Метод пристрою Present дозволяє вивести вміст вторинного буфера на екран.

Повністю текст методу Render приведений в лістингу.

void SampleApplication::Render()

{

if(pDevice)

{

// Очистимо область висновку темно-синім кольором

pDevice->Clear( 0, NULL

D3DCLEAR_TARGET,

D3DCOLOR_XRGB(0,0,128), 0.0f, 0 );

// Малюємо сцену

if( SUCCEEDED( pDevice->BeginScene() ))

{

// створюємо джерело світла

D3DLIGHT9 light=

{ D3DLIGHT_DIRECTIONAL, // нескінченно видалене джерело

{1,1,0,0}// дифузне освітлення: жовтий колір

{0,0,0,0}

{0.1f,0.1f,0.1f,1}// розсіяне світло: тьмяний білий

{0,0,0}

{7-2,1} // вектор напряму

} ;

pDevice->SetLight( 1 &light ) ;

pDevice->LightEnable( 1, TRUE ) ;

// створюємо матеріал

D3DMATERIAL9 material = {

{1,1,1,1}

{1,1,1,1}

{1,1,1,1}

{0,0,0,0}

1

} ;

pDevice->SetMaterial( &material ) ;

float scale = 0.4f;

D3DMATRIX transform = {

scale, 0.0f, 0.0f, 0.0f

0.0f, scale, 0.0f, 0.0f

0.0f, 0.0f, scale, 0.0f

0.0f, 0.0f, 1.0f, 1.0f

};

pDevice->SetTransform(D3DTS_WORLD, &transform);

pTeapot->DrawSubset(0);

pDevice->EndScene();

}

// Виводимо вміст вторинного буфера

pDevice->Present( NULL, NULL, NULL, NULL );

}

}

Отже, всі необхідні функції реалізовані. Відкомпілюйте одержану програму. Якщо не виникло жодної помилки, запустіть її на виконання. Ось воно, творіння наших рук (рис 3.5).

Рис 3.5 Зовнішній вигляд вікна першої програми

Ми обов'язково поліпшимо цей приклад, але зараз давайте ближче познайомимося з основою основ бібліотеки DirectX -- моделлю COM.

3.3.8 Огляд моделі COM

У даному розділі ми стисло розглянемо особливості компонентної моделі COM, на якій побудована реалізація DirectX для платформи Windows. Знайомі з COM програмісти вільно можуть пропустити цей розділ без збитку для розуміння.

Програмування в термінах класів і об'єктів давно вже стало звичним. Мова C++ придбав величезну популярність завдяки підтримці об'єктно-орієнтованого програмування. За час існування C++ для нього була створена велика кількість бібліотек класів.

Проте сучасний світ багатий різноманітними технологіями, і сумісності на рівні початкових текстів вже недостатньо. Що, якщо вам знадобиться використовувати об'єкт, створений на іншій версії компілятора або взагалі на іншій мові? Один з варіантів рішення вже давно існує в операційній системі Windows.

Бібліотеки динамічної компоновки (DLL) дозволяють створити програмний код, доступний для завантаження і виконання. Експортуються з DLL функції стають доступними в зухвалій програмі, неначебто вони були в ній реалізовані. Схрестивши дві ці ідеї, ми і одержимо реалізацію компонентного програмування.

Отже, компонентне програмування цей логічний розвиток ідей об'єктно-орієнтованого програмування, яке дозволяє вирішити проблеми повторного використання коду з різних програмних середовищ і понизити витрати на супровід різних версій програмного коду. Це досягається за рахунок відділення інтерфейсів об'єктів від їх реалізації.

3.3.9 Інтерфейс і реалізація

Інтерфейсом об'єкту називають опис його функціональності (методів, властивостей і т.д.) на одній з мов високого рівня. У компонентних середовищах (таких, як COM) забороняється звертатися до об'єкту інакше, як через інтерфейси. Навіщо потрібні такі строгі обмеження? Давайте подивимося.

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