.NET і зміна парадигми

Яке відношення все сказане має до .NET? Найпряміше. Бачте .NET змінить підхід до проектування додатків так само сильно, як поява класів в VB колись вплинула на проектування додатків Vb5 і 6. І перехід на .NET викличе певні незручності — як і перехід від «безкласових» версій VB до підтримки класів! [ У постачання VB .NET входить утиліта перетворення програм, но'не варто покладати на неї надмірні надії. Жодна серйозна програма не перетвориться автоматично — можливо, її буде простіше написати з нуля. ]

Розглянемо деякі чинники, які слід враховувати при переході з Vb6 на VB .NET.

Common Language Runtime

Виконавче середовище (runtime) було завжди присутнє в Visual Basic, тому наступне твердження спочатку виглядає декілька дивно. Отже, одним з найсерйозніших нововведень VB .NET є наявність виконавчого середовища CLR (Common Language Runtime), загального для всіх мов .NET. Хоча на перший погляд CLR нагадує звичайну бібліотеку часу виконання на зразок бібліотеки З MSVCRTXX.DLL, бібліотека VB MSVBVMXX.DLL має значно великі розміри і володіє набагато більшими можливостями. З цієї причини написання програм, повною мірою використовуючих CLR, більше схожий на програмування для API нової операційної системи [ Можливості бібліотеки класів .NET Framework настільки широкі, що вам практично не доведеться використовувати функції API. ].

Оскільки всі мови .NET використовують одне і те ж середовище CLR, необхідність у виконавчих середовищах для окремих мов відпадає. Більш того, код, призначений для виконання в CLR, може бути написаний на будь-якій мові і з однаковим успіхом використовуватися у всіх мовах, відповідних специфікації CLR [ У цьому виявляється головна відмінність .NET від Java: на платформі .NET можна використовувати будь-яку мову за умови, що він відповідає специфікації CLR. Програма, написана на Java, працює на будь-якій платформі (принаймні теоретично — на практиці виникають проблеми), але за умови, що вона написана саме на Java. Ймовірно, саме мовна інтеграція стане однією з складових успіху .NET. ]. Зокрема, код VB може використовуватися в програмах, написаних на С#, і навпаки, причому це не зажадає додаткових зусиль з боку програміста.

Наступне принципове нововведення — загальний формат виконуваної коди .NET, так званий Microsoft Intermediate Language (проміжна мова Microsoft), MSIL або просто IL Він є кодом, що частково відкомпілювався, перетворюється в машинний код середовищем .NET під час виконання. Перед нами принципове удосконалення схеми, що існувала у всіх версіях VB до версії 5. Раніше додатку VB компілювалися в Р-код (псевдокод, машинна мова абстрактної машини), свого роду проміжне представлення остаточної виконуваної коди. Механізм часу виконання інтерпретував Р-код при запуску програми користувачем. Користувачі постійно скаржилися на погану швидкодію [ Взагалі-то, в більшості випадків причини слід було шукати у іншому місці. Швидкість роботи з мишею обмежена, так що в більшості додатків з призначеним для користувача інтерфейсом перехід на код, що компілює, особливого виграшу не давав. ]і прохали Microsoft включити в VB підтримку компіляції в машинний код. Починаючи з версії 5 з'явилася можливість вибору між компактним Р-кодом і машинним (native) кодом, який займав більше місця, але теоретично швидше працював. У мовах .NET переваги Р-кода об'єдналися з перевагами компільованих мов. Спочатку програма, написана на будь-якій мові, компілюється в IL (віддалений аналог Р-кода), а потім отриманий IL-код перетвориться в машинний код. Подібна двокрокова схема відносно легко забезпечує міжмовну сумісність, а підсумкове використання машинної коди забезпечує хороша швидкодія.

VB як об'єктно-орієнтована мова

Об'єктно-орієнтовані засоби Vb5 і Vb6 були, м'яко кажучи, обмеженими. Зокрема, ці версії VB не дозволяли автоматично ініціалізувати дані класу при створенні екземпляра. В результаті об'єкт створювався в невизначеному стані, що підвищувало вірогідність помилок і примушувало програміста приймати додаткові запобіжні засоби при роботі з об'єктами. Для вирішення цієї проблеми в VB .NET з'явилися конструктори, що параметризувалися (див. розділ 4).

Іншим недоліком була відсутність повноцінного спадкоємства (ця тема розглядається в розділі 5 [ Спадкоємство — штука корисна, але воно не є панацеєю для написання об'єктно-орієнтованих програм, як вважають деякі. Безперечно, це важливе, але не найважливіше удосконалення в VB .NET. ]). Спадкоємством називається особлива форма багатократного використання коди, при якій програміст визначає нові об'єкти на базі існуючих об'єктів. Спадкоємство дуже добре підходить для таких завдань, як створення нового текстового поля з розширеними можливостями на підставі стандартного текстового поля. У VB версій 5 і 6 спадкоємство не підтримувалося, тому для побудови покращуваного текстового поля доводилося удаватися до послуг незручної і ненадійної програми-майстра (wizard).

Розглянемо інший приклад, в якому було б доречне спадкоємство, — створення класів для роботи із спеціалізованими колекціями. Щоб створити колекцію, що спеціалізувалася на зберіганні строкових даних, в Vb5 і 6 в клас включалося закрите поле:

Private mcollection As Collection

У обробниках подій Initialize і Terminate відбувалося виділення і звільнення пам'яті, використовуваною закритою колекцією. Потім програмувалися методи спеціалізованої колекції, призначені для зовнішнього використання. Більшість таких методів зводилися до простого виклику відповідного методу закритої колекції, наприклад:

Sub Add(Item As String)

mcollection.Add Item

End Sub

Але найосоружніше починалося в тому випадку, якщо вміст колекції потрібно було перебирати в циклі For Each. Для цього в модуль класу доводилося включати фрагменти вигляду:

Public Function Newenum As lunknown

Set Newenum = mcollection.[_newenum]

End Function

Але і це не все — цій функції слід було привласнити ідентифікатор —4!

Принцип «абракадабра — дістаємо з капелюха кролика!» хороший для фокусника, але не для програміста. При використанні спадкоємства вся ця нісенітниця не потрібна. У VB .NET досить написати:

Class Mycollection

Inherits Collection

...і ви отримуєте автоматичну підтримку For Each (див. розділ 5).