Визуальное программирование и MFC
СОМ и многокомпонентные программы
За последние 35 лет конструкторы аппаратного обеспечения прошли путь от компьютеров размеров с комнату до маленьких "лэптопов" на основе крошечных, но мощных микропроцессоров. За те же самые 35 лет разработчики программ прошли путь от больших систем на ассемблере и COBOL до создания еще больших систем на С и C++. Это (вероятно) прогресс, но мир программного обеспечения все же развивается медленнее, чем мир “железа”. Что же есть такого у конструкторов аппаратного обеспечения, чего нет у конструкторов программ?
Компоненты — вот что. Проектировщик аппаратуры обычно создает систему из уже готовых компонентов, каждый из которых выполняет определенную функцию и предоставляет набор сервисов через тщательно определенные интерфейсы. Задача проектировщиков аппаратуры значительно упрощается, благодаря повторному использованию результатов, достигнутых другими.
Повторное применение — это также путь к созданию лучшего программного обеспечения. Сегодня разработчики программ частенько повторяют дорогу, уже проторенную до них сотнями программистов. Результат часто бывает очень хорошим, но ведь мог бы быть гораздо лучше. Создание новых приложений из существующих, протестированных компонентов, вероятно, должно приводить к более надежному коду. И — что не менее важно — оно может быть гораздо быстрее и дешевле.
Именно этот подход и реализуется в СОМ. Объекты СОМ являются эффективным механизмом применения повторного программного обеспечения, так как позволяют создавать дискретные, повторно используемые компоненты. Эти компоненты, каждый из которых предназначен для выполнения определенной функции, могут играть роль, аналогичную той, что играют различные микросхемы, используемые проектировщиками аппаратуры. Возможно, именно из-за подобной аналогии этот подход стал известен как компонентное программное обеспечение.
Идею трудно назвать новой. Существующие механизмы повторного применения, хотя и важны сами по себе, но не слишком мощны. Чтобы разобраться в этом, рассмотрим две наиболее распространенные схемы повторного применения: библиотеки и объекты.
Как механизм повторного применения, библиотеки могут дать многое. Это особенно верно для динамически подключаемых библиотек, которые могут загружаться по запросу и обычно используются программами совместно, а не компонуются статически с одним приложением. Библиотеки привычны и просты в использовании. Поскольку их можно распространять в двоичной форме, нет риска открыть секреты реализации исходного кода любопытным. Совсем немного усилий, и программа, написанная на одном языке, сможет вызывать из библиотеки процедуры, написанные на другом. Но библиотеки не лишены недостатков. Один из них — сложность расширения функциональных возможностей: как установить новую версию библиотеки и не повредить приложениям, ориентированным на старую? И где простой и легкий способ установить в системе более одной реализации одной и той же библиотеки, что может потребоваться в некоторых обстоятельствах? Библиотечный подход просто недостаточен.
Благодаря инкапсуляции данных и методов, объекты также способны предоставить ясный способ оформления повторно используемых функциональных элементов. Как и традиционные библиотеки, объекты, предназначенные для решения определенных проблем, можно создать только раз и многократно использовать. Но возможности объектов даже больше, чем у библиотек. Наследование позволяет объекту повторно задействовать определение интерфейса другого объекта, или его код, или и то и другое. Полиморфизм упрощает повторное применение, скрывая несущественные различия от клиентов объектов.
Несмотря на все эти преимущества, до максимума потенциальных возможностей объектной технологии по повторному применению программ еще далеко. На пути стоят три основные проблемы.
Первая и, вероятно, самая важная проблема заключается в том, что стандартов для компоновки двоичных объектов в единое целое фактически нет. Хотя можно скомпилировать объект C++ и затем использовать этот скомпилированный объект из библиотеки, это гарантированно сработает, только если и библиотека, и использующее ее приложение скомпилированы одним и тем же компилятором.
Для C++ отсутствует стандарт формата двоичных объектов, поддерживаемый всеми компиляторами, поэтому создание и распространение библиотек объектов в лучшем случае проблематично. Вследствие этого доступные сейчас библиотеки объектов C++ практически всегда поставляются с исходным текстом. С этим связана еще одна проблема: повторное использование кода через наследование реализации ведет к тому, что дочерний и родительский объект становятся тесно связанными друг с другом. Создателю дочернего объекта обычно необходим доступ к исходному тексту родительского объекта хотя бы для того, чтобы точно знать, что происходит при вызове наследуемого метода.
Вторая проблема в том, что, несмотря на свои доминирующие позиции в объектно-ориентированной области, C++ — не единственный язык в мире. Объект, написанный на C++, нельзя использовать в программе, написанной, скажем, на Smalltalk, без особых усилий. А что насчет таких инструментов, как PowerBuilder фирмы PowerSoft или Visual Basic фирмы Microsoft? Рынок должен предоставлять объекты, которые могут использоваться разными языками и средами разработки, но пока в приложении, написанном на одном языке, применить объект, написанный на другом, затруднительно.
Третья проблема такова: если создано приложение из объектов, написанных на языке типа C++, и затем решено их изменить один из них, в лучшем случае придется перекомпоновать (relink), а может быть, и перекомпилировать все приложение. Если измененный объект используется несколькими приложениями в системе, все они должны быть перекомпонованы или перекомпилированы. В идеале должна быть возможность так установить новую версию объекта, чтобы все приложения, работающие с ним, переключились на нее автоматически. И, конечно, это должно происходить без перекомпоновки или перекомпиляции любого из этих приложений.
Все эти проблемы решены в СОМ. Объекты СОМ можно собрать в библиотеки или исполняемые файлы и затем распространять в двоичном виде (без исходных текстов). Так как СОМ определяет стандартный доступ к этим двоичным объектам, то СОМ-объекты, написанные на одном языке, можно использовать на другом.
И так как экземпляры объектов СОМ создаются, только когда это действительно необходимо, то после установки в системе новой версии объекта все его клиенты автоматически получат новый вариант при следующем обращении к данному объекту. Преимущества повторного использования, предоставляемые СОМ, включают в себя преимущества как библиотек, так и объектов, а также и другие плюсы, которых ни библиотеки, ни объекты сами по себе предоставить не могут. И главный плюс — универсальный метод доступа ко всем типам программных сервисов.
СОМ привносит в программирование преимущества технологии всеобщего повторного применения, уже давно “работающей” в области проектирования аппаратуры. В WWW уже существуют узлы, полные компонентов, основанных на СОМ; рекламой компонентов забиты журналы. Рынок объектов становится реальностью — это позволяет программистам создавать продукты, хотя бы частично состоящие из повторно использованных частей. Универсальная архитектура сервисов СОМ применима ко многим задачам, но поддержка создания компонентного программного обеспечения была, возможно, важнейшей целью ее создателей.
