2.3.3 COM и COM+

       С технической точки зрения СОМ  и СОМ+ не являются технологиями, нацеленными на .NET, поскольку компоненты, основанные на них, не могут компилироваться в IL (хотя в определенной степени это и можно сделать, применяя управляемый C++, если исходный компонент СОМ+ был написан на C++). Однако СОМ+ остается важным инструментом, потому что его средства не дублируют .NET. К тому же компоненты СОМ будут по-прежнему работать, и .NET включает средства взаимодействия с СОМ, позволяющие управляемому коду вызывать компоненты СОМ и наоборот (это обсуждается в главе 24). Однако в большинстве случаев удобнее кодировать новые компоненты как компоненты .NET, чтобы воспользоваться преимуществами базовых классов .NET, а также другими выгодами от запуска управляемого кода.

       3 ОСОБЕННОСТИ ПРОМЕЖУТОЧНОГО  ЯЗЫКА (IL)

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

       Важнейшие свойства IL могут быть сформулированы следующим образом:

• объектная ориентация и применение интерфейсов;
• строгое различие между типами значений и типами ссылок;
• строгая типизация данных;
• обработка ошибок через использование исключений;
• использование атрибутов.

       3.1 Поддержка объектной ориентации и интерфейсов

       Независимость .NET от языка имеет некоторые практические ограничения. IL неизбежно должен воплощать некоторую определенную методологию программирования, а это означает, что исходный язык также должен быть совместим с этой методологией. Принципы, которым руководствовалась Microsoft при создании IL: классическое объектно-ориентированное программирование с реализацией одиночного наследования классов.

       В дополнение к классической объектной  ориентации IL также вводит понятие интерфейсов, которые впервые были реализованы под Windows с СОМ. Интерфейсы, построенные с использованием .NET — это не то же самое, что интерфейсы СОМ; им не требуется поддержка со стороны инфраструктуры СОМ {так, например, они не наследуются от IUnknown и не имеют ассоциированных глобальных идентификаторов GUID). Однако они разделяют с интерфейсами СОМ идею предоставления контракта, и классы, реализующие заданный интерфейс, должны предлагать реализацию методов и свойств, специфицированных этим интерфейсом.

       Так как работа с .NET означает компиляцию в IL, а это, в свою очередь, значит, что нужно придерживаться объектно-ориентированной методологии. Однако только этого недостаточно, чтобы обеспечить межъязыковое взаимодействие. В конце концов, C++ и Java также используют объектно-ориентированную парадигму, но их нельзя назвать способными к взаимодействию. Нам нужно рассмотреть более подробно концепцию языкового взаимодействия.

       Для начала разберемся, что вообще подразумевается  под языковым взаимодействием. В конце концов, уже СОМ позволял писать компоненты на разных языках, обеспечивая их совместную работу, — в том смысле, что они могли вызывать методы друг друга. Однако СОМ, будучи бинарным стандартом, не позволял компонентам создавать экземпляры других компоненты и вызывать их методы и свойства, не заботясь о языке, на котором компоненты были написаны. Чтобы обеспечить такую возможность, каждый объект должен был быть создан через исполняющую систему СОМ и доступен через интерфейс. В зависимости от моделей потоков зависимых компонентов, они могли приводить к существенным потерям производительности, связанным с передачей данных между выполняющимися компонентами в разных потоках. В крайнем случае, когда компоненты размещались в исполняемых файлах, а не в DLL, приходилось запускать отдельные процессы, чтобы выполнить их. Постоянно подчеркивалось, что компоненты могут общаться друг с другом, но только через исполняющую среду СОМ. В СОМ не было способа организовать прямое взаимодействие компонентов, написанных на разных языках, или создавать экземпляры друг друга — все это делалось только при посредничестве СОМ. Мало того, архитектура СОМ не позволяла реализовать наследование, тем самым сводя на нет все преимущества объектно-ориентированного программирования.

       Еще одна связанная с этим проблема заключалась  в том, что отлаживать компоненты, написанные на разных языках, приходилось независимо друг от друга. Невозможно было в отладчике переходить от одного языка к другому. Поэтому в действительности под способностью языкового взаимодействия мы подразумеваем возможность для классов, написанных на одном языке, напрямую обращаться к классам, написанным на другом языке. В частности:

• класс, написанный на одном языке, может быть унаследован от класса, реализованного на другом языке;
• класс может содержать экземпляр другого класса, независимо от того, на каких языках написан каждый из них;
• объект может напрямую вызывать методы другого объекта, написанного на другом языке;
• объекты (или ссылки на объекты) могут передаваться между методами.
• при вызове методов между языками можно шагать в отладчике по вызовам, даже если это означает необходимость перемещения между фрагментами исходного кода, написанными на разных языках.

       Все это достаточно амбициозные цели, но как ни удивительно, благодаря .NET и IL, они были достигнуты. В случае перемещения между методами в отладчике эта возможность обеспечивается интегрированной средой разработки (IDE) Visual Studio .NET, а не самой CLR.

       3.2 Различие типов значений и типов ссылок

       Как и любой язык программирования, IL представляет множество предопределенных примитивных типов данных. Одна из особенностей IL, заключается в том, что он делает четкое различие значениями и ссылочными типами. Типы значений — это те, переменные которых непосредственно хранят их данные, в то время как ссылочные типы— это те, переменные которых просто хранят адрес, по которому соответствующие данные могут быть найдены.

       В терминах C++ ссылочные типы можно  рассматривать, как будто они  обращаются к переменным через указатель, в то время как для Visual Basic лучшая аналогия для ссылочных типов — это объекты, обращение к которым в Visual Basic 6 всегда осуществляется по ссылке. IL также устанавливает свою спецификацию относительно хранения данных: экземпляры ссылочных типов всегда хранятся в области памяти, известной как управляемая куча (managed heap), в то время как типы значений обычно хранятся в стеке (хотя, если типы значений объявлены как поля внутри ссылочных типов, то они также будут сохранены в куче). В главе 2 рассказывается о стеке, куче и о том, как они работают.

       3.3 Строгая типизация данных

       Один  из наиболее важных аспектов IL состоит в том, что он основан на исключительно строгой типизации данных. Это значит, что все переменные имеют четко определенный конкретный тип данных (так, например, в IL нет места для типа данных Variant, который существует в Visual Basic и сценарных языках). В частности, IL обычно не допускает никаких действий, которые дают в результате неопределенные типы данных.

       Например, разработчики Visual Basic 6 могут позволить себе передавать переменные, не особенно заботясь об их типах, поскольку Visual Basic автоматически выполняет необходимые преобразования. Разработчики C++ привыкли к приведению указателей к различным типам. Возможность выполнения таких действий полезна для производительности, но при этом нарушаются принципы безопасности типов. Поэтому такие действия допустимы лишь при некоторых обстоятельствах в некоторых языках, компилируемых в управляемый код. В самом деле, указатели (в отличие от ссылок) разрешены только в помеченных блоках кода С# и вовсе не допускаются в Visual Basic (хотя и разрешены в управляемом C++). Применение указателей в вашем коде приводит к тому, что проверки типов в памяти, выполняемые CLR, завершаются неудачей.

       Стоит отметить, что некоторые языки, совместимые  с .NET, такие как Visual Basic 2008, все еще допускают некоторую небрежность типизации, но это возможно лишь потому, что компиляторы, находящиеся "за кулисами", гарантируют безопасность типов в сгенерированном коде IL.

       Хотя  обеспечение безопасности типов  может поначалу принести ущерб производительности, все же во многих случаях преимущества, полученные от служб, предоставляемых .NET, которые полагаются на безопасность типов, намного превышают потери от некоторого снижения производительности. Эти службы включают следующие аспекты:

• способность межъязыкового взаимодействия;
• сборка мусора;
• безопасность;
• домены приложений.

       3.3.1 Важность строгой типизации данных для межъязыкового взаимодействия

       Если  некоторый класс унаследован  от другого либо содержит в себе экземпляры других классов, то он должен знать обо всех типах данных, используемых другими классами. Вот почему строгая типизация данных так важна. Действительно, недостаток информации в любой согласованной системе в прошлом всегда являлся настоящим барьером для наследования и взаимодействия между разными языками. Информация подобного рода попросту отсутствует в стандартном исполняемом файле или библиотеке DLL.

       Предположим, что один из методов класса Visual Basic 2008 определен как возвращающий тип Integer— один из стандартных типов, доступных в Visual Basic 2008. С# просто не имеет типа данных с таким именем. Ясно, что вы сможете наследовать от этого класса, вызывать этот метод и использовать возвращаемый тип из кода С# только в том случае, если компилятор будет знать, как отобразить тип Integer языка Visual Basic 2008 на некоторый тип, определенный в С#.

       3.3.2 Общая система типов

       Эта проблема с типами данных решается в .NET за счет применения общей системы типов (Common Type System — CTS). CTS описывает предопределенные типы данных, которые доступны в IL, поэтому все языки, ориентированные на среду .NET, генерируют компилированный код, который в конечном итоге базируется на этих типах.

       Что касается предыдущего примера, то Integer из Visual Basic 2008 — это на самом деле 32-битное целое со знаком, которое отображается непосредственно на тип, известный в IL как Int32. Потому это и будет тот тип, который специфицирован в коде IL. Поскольку компилятор С# знает об этом типе, здесь проблем нет. На уровне исходного кода С# ссылается на Int32 по ключевому слову int, поэтому компилятор просто будет трактовать этот метод Visual Basic 2008 так, как будто он возвращает int.

       CTS описывает не просто примитивные типы данных, а целую богатую иерархию типов, включающую хорошо определенные точки, в которых код может определять свои собственные типы. Иерархическая структура общей системы типов (CTS) отражает объектно-ориентированную методологию одиночного наследования IL и показана на рис. 1.1.

       В табл. 1.1 представлено описание типов, показанных на рис. 1.1. 

Рис. 1.1 Общая система типов (CTS) 

       Таблица 1.1. Описание типов, показанных на рис. 1.1