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

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

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

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

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

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

§ класс может содержать экземпляр другого класса, независимо от того, на каких языках написан каждый из них;

§ объект может напрямую вызывать методы другого объекта, написанного на другомя зыке;

§ объекты (или ссылки на объекты) могут передаваться между методами;

§ при вызове методов между языками можно шагать в отладчике по вызовам, даже если это означает необходимость перемещения между фрагментами исходного кода, написанными на разных языках.

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