Net framework 5, а также среды Visual Studio 2012 и C#

196
Глава.6 .Основные.сведения.о.членах.и.типах
Компоненты, полиморфизм и версии
Объектно-ориентированное программирование (ООП) существует уже много 
лет. В поздние 70-е и ранние 80-е годы объектно-ориентированные приложения 
были намного меньше по размеру, и весь код приложения разрабатывался в одной 
компании. Разумеется, в то время уже были операционные системы, позволяющие 
приложениям по максимуму использовать их возможности, но современные ОС 
предлагают намного больше функций.
Сложность программного обеспечения существенно возросла, к тому же поль-
зователи требуют от приложений богатых функциональных возможностей — гра-
фического интерфейса, меню, различных устройств ввода-вывода (мышь, принтер, 
планшет), сетевых функций и т. п. Все это привело к существенному расширению 
функциональности операционных систем и платформ разработки в последние 
годы. Более того, сейчас уже не представляется возможным или эффективным 
писать приложение «с нуля» и разрабатывать все необходимые компоненты само-
стоятельно. Современные приложения состоят из компонентов, разработанных 
многими компаниями. Эти компоненты объединяются в единое приложение 
в рамках парадигмы ООП.
При компонентной разработке приложений (Component Software Programming, 
CSP) идеи ООП используются на уровне компонентов. Ниже перечислены неко-
торые свойства компонента.
‰
Компонент (сборка в .NET) можно публиковать.
‰
Компоненты уникальны и идентифицируются по имени, версии, региональным 
стандартам и открытому ключу.
‰
Компонент сохраняет свою уникальность (код одной сборки никогда статически 
не связывается с другой сборкой — в .NET применяется только динамическое 
связывание).
‰
В компоненте всегда четко указана зависимость от других компонентов (ссы-
лочные таблицы метаданных).
‰
В компоненте документированы его классы и члены. В C# даже разрешается 
включать в код компонента XML-документацию — для этого служит параметр 
/doc
командной строки компилятора.
‰
В компоненте определяются требуемые разрешения на доступ. Для этого в CLR 
существует механизм защиты доступа к коду (Code Access Security, CAS).
‰
Опубликованный компонентом интерфейс (объектная модель) не изменяется 
во всех его служебных версиях. 
Служебной версией
(servicing) называют новую 
версию компонента, обратно совместимую с оригинальной. Обычно служебная 
версия содержит исправления ошибок, исправления системы безопасности 

---

197
Компоненты,.полиморфизм.и.версии
и небольшие корректировки функциональности. Однако в нее нельзя добавлять 
новые зависимости или разрешения безопасности.
Как видно из последнего пункта, в компонентном программировании большое 
внимание уделяют управлению версиями. В компоненты вносятся изменения, 
к тому же они поставляются в разное время. Необходимость управления версиями 
существенно усложняет компонентное программирование по сравнению с ООП, 
где все приложение пишет, тестирует и поставляет одна компания.
В .NET номер версии состоит из четырех частей: 
основного 
(major) и 
дополни-
тельного
(minor) номеров версии, номера 
построения
(build) и номера 
редакции
(revision). Например, у сборки с номером 1.2.3.4 основной номер версии — 1, до-
полнительный номер версии — 2, номер построения — 3 и номер редакции — 4. 
Основной и дополнительный номера обычно определяют уникальность сборки, 
а номера построения и редакции указывают на служебную версию.
Допустим, компания поставила сборку версии 2.7.0.0. Если впоследствии по-
требуется выпустить сборку с исправленными ошибками, выпускают новую сборку, 
в которой изменяют только номера построения и редакции, например 2.7.1.34. То 
есть сборка является служебной версией и обратно совместима с оригинальной 
(2.7.0.0).
В то же время, если компания выпустит новую версию сборки, в которую вне-
сены значительные изменения, а обратная совместимость не гарантируется, нужно 
изменить основной и/или дополнительный номер версии (например, 3.0.0.0).