|
|
От: |
Сергей Губанов
|
http://sergey-gubanov.livejournal.com/ |
| Дата: | 23.12.05 11:33 | ||
| Оценка: | |||
Компонентный каркас — это собрание компонентных интерфейсов, которые образуют абстрактную схему решений для семейства связанных проблем.
Компонентный каркас — это собрание контрактов, то есть, правил, которые определяют, как объекты могут работать вместе. Некоторые из этих правил могут быть просто соглашениями. Другие правила может быть легко использовать, поскольку каркас предоставляет вместе с интерфейсами подходящий код. Например, каркасы GUI предоставляют стандартное поведение для приложений, окон, меню и т.п. Если стандартное поведение не заменено, оно может быть расширено соответственно правилам, например, для реализации основных принципов пользовательского интерфейса для базовой платформы. Другие правила могут действительно исполняться каркасом, например, средства рисования могут отсекать рисование за границами окон. Каркас предоставляет некоторые службы только через безопасный код, который гарантирует необходимые инварианты (например, инвариант "рисование всегда происходит внутри окон приложения"). Ключом к такому контролю, который обычно затрагивает несколько объектов, является информация, скрываемая между несколькими классами, что обсуждалось в предыдущем разделе.
В противоположность каркасам старых приложений, компонентный каркас определяет правила для независимо разрабатываемых и динамически загружаемых компонентов, а не для классов, которые компонуются вместе в монолитное приложение. Компонентный каркас может предоставлять интерфейсы, возможно вместе с некоторыми процедурами. В противоположность большинству прикладных каркасов, компонентные каркасы являются черными ящиками, то есть, их можно использовать без доступа к их исходному коду. Подобно отличному конракту, чистый интерфейс-"черный ящик" — это идеал, к которому на практике можно приближаться.
Прикладные каркасы, которые сильно опираются на наследование реализации, являются "белыми ящиками", которые публикуются вместе с их исходными кодами. В противоположность прикладным каркасам, компонентный каркас не обязан быть библиотекой классов. Фактически, компонентный каркас может вообще не содержать кода; он может быть только коллекцией интерфейсов. В этом отличие от старого понимания термина "каркас", в котором наличие реального кода играло очень важную роль. В компонентных каркасах фактический код существует большей частью для закрепления правил.
Много лет назад Microsoft опробовала стратегию "Windows повсюду", то есть, одна операционная система для всех возможных нужд. Сегодня Microsoft двигает стратегию "ActivePlatform". Одна из интерпретаций этого такова, что предоставление реального кода (т.е. Windows) не является обязательной, что лишь собрание интерфейсов (то есть, COM-интерфейсов, составляющих ActiveX Platform) имеет значение, если только существует некоторая реализация этих интерфейсов. Конструкторы аппаратуры поняли необходимость архитектуры против реализации во времена IBM 360 — шестидесятые; разработчики программного обеспечения только теперь достигают этого понимания.
Каркас содержит архитектуру, то есть, схему (design) расширяемых компонентов и их взаимодействий. Реализация расширенного компонента в соответствии со стандартом, определенным интерфейсами каркаса, является формой повторного использования: использования схемы. Поскольку разработка новой схемы гораздо более тяжела, чем реализация существующей, повторное использование схемы важнее, чем повторное использование кода. Создание новой схемы требует знания прикладной области, опыта конструирования, способности отличать существенные вопросы от незначительных и способности осознавать и изобретать подходы (patterns). Поскольку плохие схемы могут стать слишком дорогими, только самые опытные разработчики могут создавать каркасы. Другие программисты должны фокусироваться на хорошей реализации существующих схем, то есть, разработке компонентов, которые реализуют данные интерфейсы. Еще больше программистов будут концентрироваться на сборке компонентов.
В идеале инструментарий должен поддерживать полный жизненный цикл ПО. Сегодня пока нет средств, которые могли бы делать это для компонентного ПО, а традиционные объектно-ориентированные методы проектирования и CASE опираются на допущения "закрытого" типа для монолитного ПО. Инструменты, подходящие для компонентного ПО, должны поддерживать компоненты-черные ящики, исходный код которых недоступен, управление интерфейсом компонентов, конфигурирование во время выполнения и продолжительное инкрементное развитие.
Последний пункт необходим: жизненный цикл компонентной программной системы может быть значительно длиннее, чем любого из ее компонентов. Успешная компонентная система никогда не умрет, она просто будет постепенно расширяться, или обновляться заменой устаревших компонентов. В этом смысле компонентное ПО можно рассматривать как систематический способ работать с унаследованными частями.
Сборка компонентов и даже их конструирование легки по сравнению с проектированием новых компонентных каркасов. Поскольку управляемое развитие компонентного каркаса так сильно зависит от языковой поддержки гарантированной целостности и расширяемости, использовать не компонентно-ориентированный язык окажется слишком дорогим.
Очень простая быстрая проверка качества инструмента компонентной разработки заключается в том, построен ли сам инструмент из компонентов, то есть, "принимает ли собственные лекарства". В противном случае разработчики инструмента не уверены в его мощности.
