ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

Троелсен Эндрю

ГЛАВА 1. Философия .NET

Каждые несколько лет программист должен быть готов кардинально обновлять свои знания, чтобы идти в ногу с новыми технологиями. Языки (C++, Visual Basic 6.0, Java), каркасы приложений (MFC, ATL, STL) и архитектуры (COM, CORBA, EJB), которые сегодня составляют "золотой фонд" разработки программного обеспечения, в будущем непременно уступят место чему-то более совершенному или, по крайней мере, более новому. Несмотря на разочарование, которое вы можете ощущать при обновлении своей базы знаний, это неизбежно. Платформа .NET -

это сегодняшнее предложение Microsoft в области разработки программного обеспечения.

Целью этой главы является построение концептуального фундамента, необходимого для успешного освоения всего остального материала книги. Слава начинается с обсуждения ряда вопросов .NET, относящихся к высокому уровню, – таких как компоновочные блоки, CIL (общий промежуточный язык) и JIT-компиляция (just-in-time – точно к нужному моменту). Вдобавок к вводному обзору некоторых ключевых возможностей языка программирования C#, будет также обозначена взаимосвязь между различными элементами каркаса .NET, такими как CLR (общая языковая среда выполнения), CTS (общая система типов) и CLS (общие спецификации языка). Как вы вправе ожидать, эти темы будут исследоваться более подробно в других частях книги.

Эта глава также содержит обзор возможностей, предлагаемых библиотеками базовых классов .NET, для обозначения которых иногда используют аббревиатуру BCL (Base Class Libraries – библиотеки базовых классов) или, как альтернативу, FCL (Framework Class Libraries – библиотеки каркасных классов). Наконец, в главе обсуждается независимая от языков и платформ сущность платформы .NET (это действительно так - .NET не замыкается на операционной системе Windows).

Предыдущее состояние дел

Перед рассмотрением специфики .NET будет полезно рассмотреть некоторые проблемы, стимулировавшие появление предлагаемой сегодня платформы Microsoft. Чтобы получить соответствующее представление, давайте начнем эту главу с краткого урока истории, чтобы напомнить об истоках и понять ограничения, существовавшие в прошлом (в конце концов, признание существования проблемы является первым шагом на пути ее решения). После этого мы обратим наше внимание на многочисленные преимущества, которые обеспечиваются языком C# и платформой .NET.

Подход C/Win32 API

Традиционно разработка программного обеспечения для операционных систем семейства Windows предполагает использование языка программирования C в сочетании с Windows API (Application Programming Interface – интерфейс программирования приложений). Несмотря на тот факт, что в рамках этого проверенного временем подхода было создано очень много вполне успешных приложений, мало кто станет оспаривать то, что процесс создания приложений непосредственно с помощью API оказывается очень трудоемким делом.

Первая очевидная проблема заключается в том, что C является очень лаконичным языком. Разработчики программ на языке C вынуждены "вручную" управлять памятью, использовать безобразную арифметику указателей и ужасные синтаксические конструкции. К тому же, поскольку C является структурным языком программирования,

ему не хватает преимуществ, обеспечиваемых объектно-ориентированным подходом (здесь можно вспомнить о "макаронных" программах). Когда вы объединяете тысячи глобальных функций и типов данных, определенных в рамках Win32 API, с языком, который и без того выглядит устрашающе, не следует удивляться тому, что среди используемых сегодня программ оказывается так много ненадежных.

Подход C++/MFC

Огромным шагом вперед по сравнению с подходом, предполагающим использование C/API, явился переход к применению языка программирования C++. Во многих отношениях язык C++ можно рассматривать, как объектно-ориентированную надстройку над C. Поэтому, хотя при использовании C++ уже можно использовать преимущества известных "краеугольных камней ООП" (инкапсуляция, наследование и полиморфизм), этот подход оставляет программиста во власти многих болезненных аспектов языка C (управление памятью "вручную", безобразная арифметика указателей и ужасные синтаксические конструкции).

Несмотря на сложность, сегодня существует множество каркасов программирования на C++. Например, MFC (Microsoft Foundation Classes – библиотека базовых классов Microsoft) снабжает разработчика набором C++-классов, упрощающих создание Win32-приложений. Главной задачей MFC является представление "разумного подмножества" Win32 API в виде набора классов, "магических" макросов и средств автоматического генерирования программного кода (обычно называемых мастерами). Несмотря на очевидную пользу указанного каркаса приложений (как и многих других средств разработчика, использующих C++), программирование на C++ остается трудной задачей, и на этом пути нелегко полностью избежать ошибок ввиду "тяжелой наследственности", обусловленной связью с языком C.

Подход Visual Basic 6.0

Благодаря искреннему желанию насладиться более простой жизнью, многие программисты ушли от "мира каркасов" приложений на базе C(++) к более дружественным языкам, таким, как, например, Visual Basic 6.0 (VB6). Язык VB6 стал популярным благодаря тому, что он дает возможность строить сложные интерфейсы пользователя, библиотеки программного кода (например, COM-серверы) и системы доступа к данным, затрачивая минимум усилий. В сравнении с MFC, VB6 еще глубже скрывает от глаз разработчика сложность Win32 API, используя для этого целый ряд интегрированных мастеров, внутренних типов данных, классов и специфических для VB функций.

Главным недостатком VB6 (который был устранен в Visual Basic .NET) является то, что VB6 является, скорее, "объектно-осведомленным" языком, а не полноценным объектно-ориентированным. Например, в VB6 программисту не позволяется связывать типы отношениями "подчиненности" (т.е. нет классического наследования) и нет внутренней поддержки конструкции параметризованных классов. Кроме того, VB6 не дает возможности строить многопоточные приложения, если только вы не готовы "спуститься" до низкоуровневых вызовов Win32 API (что в лучшем случае достаточно сложно, а в худшем – опасно).