Хочется верить,
что книга пригодится программистам с опытом работы на любых языках, но данная
глава рассчитана в основном на программистов Visual Basic. Остальные могут сразу
переходить к главе 2 и начинать знакомство с невероятно мощной интегрированной
средой разработки (IDE), в основу которой положен первый по-настоящему объектно-ориентированный
язык семейства BASIC. Программист, привыкший работать на Visual Basic, не сразу
поверит, что хлопоты по переходу на VB .NET будут оправданы. Именно поэтому
и была написана данная глава.
Visual Basic: прошлое и настоящее
Visual Basic
для Windows появился около 10 лет назад. Дебют состоялся 20 марта 1991 года
на выставке «Windows World», хотя своими корнями он уходит к программе
Ruby, написанной Аланом Купером (Alan Cooper) в 1988 году.
Бесспорно,
появление Visual Basic произвело настоящую сенсацию. Стив Гиб-сон (Steve Gibson)
в журнале «InfoWorld» назвал Visual Basic «потрясающим новым
чудом», которое «радикально изменит подход к программированию для
Microsoft Windows». Чарльз Петцольд (Charles Petzold), автор знаменитой
книги, посвященной программированию для Windows на языке С, написал в «New
York Times»: «Visual Basic представляет настоящую угрозу для благополучия
тех, кто зарабатывает себе на жизнь, разъясняя программистам сложности программирования
для Windows» (вряд ли к комментарию Петцольда стоит относиться серьезно,
поскольку с того знаменательного дня были проданы миллионы книг, посвященных
VB). Еще решительнее высказался Стюарт Элсоп (Stewart Alsop): он назвал Visual
Basic «идеальной средой программирования для 90-х годов».
Но 90-е годы
уже прошли, поэтому никого не удивит тот факт, что Visual Basic .NET отличается
от обычного Visual Basic так же сильно, как Visual Basic версии 1 отличается
от своего предшественника QuickBasic. Хотя из прежнего опыта использования
Visual Basic можно вынести много полезного, переход на платформу [ Microsoft
серьезно относится к этому слову. В частности, Windows тоже именуется платформой.].NET
и Visual Basic .NET (сокращенно VB .NET) сопровождается такими же основательными
изменениями, как и переход с QuickBasic для DOS на VB1 для Windows.
Первые две
версии Visual Basic для Windows хорошо подходили для создания прототипов программ
и демонстрационных приложений — но этим все и ограничивалось. В обеих версиях
отличная среда программирования сочеталась с относительной простотой языка.
Сам язык обладал относительно бедными возможностями. С появлением VB3 и новых
средств работы с базами данных, требовавших изучения новой модели программирования,
первая реакция нередко была обескураживающей: «Зачем они испортили VB?!»
Сейчас становится понятно, что включение поддержки баз данных в VB3 было необходимо,
чтобы Visual Basic из «игрушечного языка» превратился в серьезный
инструмент программирования. В VB4 появились базовые возможности для создания
объектов, а следовательно — базовые средства объектно-ориентированного программирования.
В VB5 и VB6 объектно-ориентированные аспекты языка были расширены, появились
новые возможности создания элементов и использования интерфейсов. Однако сам
язык постепенно утрачивал целостность, поскольку объектно-ориентированные средства
строились на базовом фундаменте, в котором их поддержка не предусматривалась.
Например, правильность создания объектов в Visual Basic не гарантировалась —
программисту приходилось применять особые синтаксические конструкции вместо
конструкторов, используемых практически во всех объектно-ориентированных языках
(конструкторы рассматриваются в главе 4). В итоге разработчики VB пришли к выводу,
что поддержка VB на платформе .NET потребует новых изменений — например, использование
.NET Framework требует полноценной объектной ориентации языка.
Вероятно,
при знакомстве с изменениями VB основные трудности возникнут не в связи с новшествами
в среде IDE или появлением новых ключевых слов, а из-за необходимости радикального
пересмотра парадигмы программирования на VB. В частности, чтобы в полной мере
использовать преимущества VB5 и VB6, с объектно-базированного подхода,
обладавшего весьма ограниченными возможностями создания новых объектов, приходилось
переходить на объектно-ориентированный подход, в инструментарии которого,
например, важное место занимают интерфейсы. К сожалению, большинство программистов
VB, выросших на этом продукте, ранее никогда не использовали принципы объектно-ориентированного
программирования. Когда в VB впервые появились классы, многие программисты VB
понятия не имели, что это такое и зачем они нужны.
Но даже эти
ограниченные возможности, появившиеся в VB5 и VB6, при правильном применении
упрощали работу над большими проектами. Например, они позволяли создавать компоненты
многократного использования (такие, как элементы управления), а на более прозаическом
уровне — просто приводить код в порядок, упрощая его сопровождение. В некоторых
случаях удавалось исключить оператор Sel ect Case, нередко порождавший большие
проблемы с сопровождением. Речь идет о конструкциях, более или менее похожих
на следующие: [В поставку VB .NET входит утилита преобразования программ,
но не стоит возлагать на нее чрезмерные надежды. Ни одна серьезная программа
не преобразуется автоматически — возможно, ее будет проще написать с нуля. ]
Select Case kindOfEmployee
Case Secretary
RaiseSalary 5%
Case Manager
RaiseSalary 10%
Case Programmer
RaiseSalary 15%
Case Architect
RaiseSalary 20%
'и т. д.
End Select
Сопровождение
подобного кода было делом крайне неприятным, поскольку при каждом добавлении
нового типа сотрудника (Employee) приходилось изменять все соответствующие операторы
Select Case, тогда как эту работу можно было бы поручить компилятору. Начиная
с VB5 это наконец стало возможным, поскольку волшебство полиморфизма интерфейсов
(см. главу 5) позволяло использовать конструкции вида:
For Each employee
in Employees
employee.RaiseSalary
Next
Компилятор
анализировал объект и автоматически выбирал нужный метод Rai seSal ary. "Классы
заметно повышают эффективность и удобство сопровождения приложений VB. Останетесь
ли вы с VB5 или перейдете на VB .NET — без классов трудно представить себе серьезное
приложение VB.
Какое отношение
все сказанное имеет к .NET? Самое прямое. Видите ли, .NET изменит подход к проектированию
приложений так же сильно, как появление классов в VB некогда повлияло на проектирование
приложений VB5 и 6. И переход на .NET вызовет определенные неудобства — как
и переход от «бесклассовых» версий VB к поддержке классов! [В
поставку VB .NET входит утилита преобразования программ, но'не стоит возлагать
на нее чрезмерные надежды. Ни одна серьезная программа не преобразуется автоматически
— возможно, ее будет проще написать с нуля. ]
Рассмотрим
некоторые факторы, которые следует учитывать при переходе с VB6 на VB .NET.
Исполнительная
среда (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).
Автоматическая сборка мусора: ликвидация утечки памяти
У программистов,
работающих на Visual Basic, всегда возникали проблемы с утечкой памяти из-за
так называемых циклических ссылок (ситуация, при которой объект А ссылается
на объект В, а объект В ссылается на объект А). Если появление циклических ссылок
было обусловлено логикой программы, компилятор VB не распознавал их, в результате
чего память, занимаемая этими объектами, не освобождалась. Система сборки
мусора, встроенная в .NET CLR, решает проблему циклических ссылок иначе
— интеллектуальный алгоритм обнаруживает циклические ссылки, разрывает их и
освобождает занимаемую память. Конечно, за дополнительные возможности приходится
платить; достоинства и недостатки автоматической сборки мусора рассматриваются
в главе 4.
Во всех версиях
Visual Basic использовался механизм обработки ошибок, появившийся в самой первой
версии BASIC (с тех пор прошло почти 40 лет!). Мягко говоря, у него есть недостатки.
А если выражаться откровенно, использование в современном языке программирования
команды On Error Goto, неимоверно усложняющей логику программы, — сущий абсурд.
В VB .NET реализована структурная обработка ошибок (см. главу 7), самый
современный и мощный механизм обработки ошибок.
Многопоточная
программа выполняет несколько функций одновременно. Например, в почтовых клиентах
во время приема новых сообщений можно читать старую электронную почту. Пользователи
ценят подобные возможности, но в прежних версиях VB написание многопоточных
приложений было очень непростой задачей. В главе 10 мы рассмотрим достоинства
и недостатки этой новой, чрезвычайно мощной возможности VB .NET.
Возникает
заманчивая картина: вы запускаете программу преобразования, немного дорабатываете
полученный результат, и программа VB автоматически адаптируется для VB .NET!
Поверьте,
этот путь ведет в тупик. Чтобы в полной мере использовать преимущества VB .NET,
необходимо основательно разобраться в объектно-ориентированном программировании
и принципах работы .NET Framework. Вам не придется запоминать тысячи методов,
входящих в .NET Framework, но для сознательного чтения документации или использования
средств IntelliSense, встроенных в IDE, нужно знать, как работает .NET. Без
хорошего понимания этого материала вы попросту не сможете работать в IDE с дизайнерами
форм Windows и Web.
Чтобы представить
масштаб изменений, достаточно рассмотреть простейший пример — форму, на которой
находится кнопка. В прежних версиях VB весь код, связанный с кнопкой (и выполнявшийся
при ее нажатии), находился в процедуре события Click.
Сразу предупреждаю:
при размещении кнопки на форме VB .NET среда программирования генерирует значительно
больший объем кода. В этой книге мы постараемся показать, почему в этом
коде стоит разобраться — причем так, чтобы он казался не сложнее простого обработчика
Click.
Приведенный
ниже фрагмент (в основном автоматически сгенерированный) размещает кнопку на
форме и выводит окно сообщения при нажатии кнопки. Числа в скобках к программе
не относятся, они просто используются для ссылок на строки листинга в тексте
книги.
(1) Public Class
Form1
(2) Inherits
System.Windows.Forms.Form
(3) #Region
" Windows Form Designer generated code "
(4) Public Sub
New()
(5) MyBase.New()
' Вызов необходим
для работы дизайнера форм Windows
(6) InitializeComponent()
' Дальнейшая
инициализация выполняется ' после вызова InitializeComponent()
End Sub
' Форма переопределяет
Dispose для очистки списка компонентов.
(7) Protected
Overloads Overrides Sub Dispose(ByVal disposing As Boolean) If disposing Then
If Not (components
Is Nothing) Then
components.
Dispose() End If End If
MyBase.Dispose(disposing)
End Sub
(8) Friend WithEvents
Buttonl As System.Windows.Forms.Button
' Необходимо для работы дизайнера форм Windows
Private components
As System.ComponentModel.Container
' ВНИМАНИЕ: следующий фрагмент необходим для дизайнера форм Windows
' Для его модификации следует использовать дизайнер форм.
' Не изменяйте
его в редакторе!
(9) <System.Diagnostics.DebuggerStepThrough()> Private Sub _
InitializeComponent()
'
'Button1
'
Me.Buttonl.Location = New System.Drawing.Point(109, 224)
Me.Buttonl.Name
= "Buttonl"
Me.Button1.Size
- New System.Drawing.Size(200. 48)
Me.Button1.TabIndex
= 0,
Me. Button1.
Text = "Click me!"
'
'Form1
'
Me.AutoScaleBaseSize
= New System.Drawing.Size(5. 13)
Me.ClientSize
= New System.Drawing.Size(292. 216)
Me.Controls.AddRange(New
System.windows.Forms.Control() {Me.Button1})
Me.Name = "Forml"
Me.Text = "First
windows Application"
Me.ResumeLayout
(False)
End Sub #End
Region
(10) Private Sub Buttonl_C1ick(ByVal sender As System.Object._
ByVal e As System.EventArgs)
Handles Buttonl_Click
MsgBox("Welcome to Visual Basic .NET!")
End Sub
(11) End Class
Картина была
бы неполной, если бы мы не упомянули о С#. Большая часть .NET Framework написана
на С#, поэтому некоторые полагают, что именно С# является настоящим языком
.NET. Хотя С# чуть мощнее VB .NET, 99% программистов никогда не будут пользоваться
его дополнительными возможностями.
Тому, кто
никогда не программировал на C/C++, язык С# может показаться непонятным и более
сложным, чем VB .NET. Кроме того, VB .NET имеет ряд несомненных преимуществ
перед С#. Ниже перечислены пять из них, которые нам кажутся самыми важными:
Когда тот или иной физик использует понятие "физический вакуум", он либо не понимает абсурдности этого термина, либо лукавит, являясь скрытым или явным приверженцем релятивистской идеологии.
Понять абсурдность этого понятия легче всего обратившись к истокам его возникновения. Рождено оно было Полем Дираком в 1930-х, когда стало ясно, что отрицание эфира в чистом виде, как это делал великий математик, но посредственный физик Анри Пуанкаре, уже нельзя. Слишком много фактов противоречит этому.
Для защиты релятивизма Поль Дирак ввел афизическое и алогичное понятие отрицательной энергии, а затем и существование "моря" двух компенсирующих друг друга энергий в вакууме - положительной и отрицательной, а также "моря" компенсирующих друг друга частиц - виртуальных (то есть кажущихся) электронов и позитронов в вакууме.
Однако такая постановка является внутренне противоречивой (виртуальные частицы ненаблюдаемы и их по произволу можно считать в одном случае отсутствующими, а в другом - присутствующими) и противоречащей релятивизму (то есть отрицанию эфира, так как при наличии таких частиц в вакууме релятивизм уже просто невозможен). Подробнее читайте в FAQ по эфирной физике.
|
![]() |