Что такое компонентно-управляемая разработка?
Термин "Компонентно-управляемая разработка" начинает широко использоваться, особенно в связи с инверсией управления.
- Что это?
- Какие проблемы это решает?
- Когда это уместно, а когда нет?
7 ответов
Что это?
Я думаю, что определение в вашем ответе хорошо охватывает этот вопрос. Хотя я задаюсь вопросом, почему определение включает в себя то, что компонент должен явно определять свои зависимости. Каноническим примером компонента является элемент управления ActiveX - нужно ли им явно определять свои зависимости?
Какие проблемы это решает?
Управление сложностью. Он стремится решить эту проблему, позволяя вам думать только о реализации компонента. Нужно только создавать компоненты, не нужно думать о том, как их комбинировать или управлять ими. Это делается какой-то структурой или инфраструктурой, внешней по отношению к компоненту и неважной для автора компонента.
Когда это уместно, а когда нет?
Не обязательно уместно в обычном или одноразовом приложении. Плохой запах в архитектуре компонентов - это то, что вы тратите время на обдумывание или работу над инфраструктурой для управления и объединения компонентов, а не самих компонентов.
Я не уверен, что это "широко распространенная" терминология, но в VCS (системе контроля версий) я знаю два способа управления набором файлов, необходимых для создания программы:
- системный подход, где весь набор имеет общий жизненный цикл и должен быть помечен как все
- компонентный подход, когда отдельный набор файлов имеет свой собственный жизненный цикл, и где мета-метка ссылается на все метки компонентов для обозначения всей системы по составу и зависимостям между этими компонентами.
Аппликативная архитектура используется для идентификации этих компонентов:
- функциональная область и приложения
- сторонние библиотеки
- рамки
Вот где IoC входит, так как он лежит в основе любого фреймворка. Проблема, которую он решает, позволяет вам лучше идентифицировать часть вашего приложения:
Предположим, вы разрабатываете приложение PLR (Прибыль и Убыток), отвечающее за расчет прибылей и убытков (позиции) трейдера.
Вы быстро поймете, что это не одно приложение, а набор из нескольких:
- графический интерфейс пользователя
- пусковая установка
- диспетчер (для отправки вычислений на несколько серверов, потому что у одного не хватит памяти, чтобы вычислить все!)
- и так далее
Затем вы можете идентифицировать вычислительную среду (Ioc), которая позволит вам подключать различные модули, которые затем будут вызываться в нужный момент вашей средой.
Или вы можете определить чисто технические структуры (KPI, журналы, управление исключениями), которые затем могут быть использованы любыми другими вашими функциональными компонентами.
С точки зрения управления проектами, это также позволяет вам разрабатывать каждую часть независимо, обеспечивая при этом глобальную координацию через VCS.
Компонентная разработка не является чем-то действительно новым. Я не знаю о компонентно-управляемой разработке, но я собираюсь предположить, что это КБР. Это то, как спроектирован Unix, куча заменяемых небольших программ, каждая из которых выполняет одну вещь очень хорошо. В области настольных компьютеров Delphi VCL успешно использует компоненты с богатыми компонентами многократного использования и сторонним рынком, как никто другой. Сейчас мы наблюдаем возрождение КБР, поскольку некоторые технологии развиваются. Например, простые веб-приложения развиваются в SOA и RESTful WS. Все о парнях Java говорили о модульности и IoC.
Вероятно, ответ, который вы ищете, будет найден в статье "Почему и что из обращения с контролем " Ке Джина.
Кроме того, естественный императив этих классических языков программирования ОО имеет тенденцию пропускать лес (высокоуровневые архитектуры / структуры) для деревьев (низкоуровневый процедурный код логического управления). Инженеры по разработке и обслуживанию, принимающие существующее приложение, должны полагаться на его устаревшие документы по дизайну / архитектуре и комментарии / шаблоны кода низкого уровня.
Парадигма разработки на основе компонентов (CBD) решает две вышеупомянутые проблемы путем переноса логики подключения в структуры, которые манипулируют компонентами и настраивают приложения на основе предоставленных пользователями / разработчиками декларативных описаний. Вопреки распространенному заблуждению, такие декларативные описания не должны быть сценариями установки приложения. Скорее, их фундаментальное намерение состоит в том, чтобы явным образом выразить архитектуры / структуры приложений без обязательного выполнения их обязательных процедур сантехники (а именно, описать что вместо вместо как). Целью парадигмы CBD является поддержка эффективных и гибких композиций приложений с помощью этих платформ, и при этом разработчики приложений должны сосредоточиться на бизнес-логике и проблемах предметной области, не обращая внимания на сложности сантехники низкого уровня.
Платформы CBD, которые объединяют декларативные описания приложений и методику IoC, называются инфраструктурами IoC. В отличие от своих предшественников, платформы IoC неинвазивны и используют сценарий зависимости / настройки / настройки.
Согласно Википедии, разработка на основе компонентов - это псевдоним для разработки программного обеспечения на основе компонентов (CBSE).
[Это] является отраслью разработки программного обеспечения, приоритетом которой является разделение интересов в отношении широкого спектра функциональных возможностей, доступных в данной программной системе.
Это несколько расплывчато, поэтому давайте посмотрим на более подробно.
Отдельный компонент - это программный пакет или модуль, который инкапсулирует набор связанных функций (или данных).
Все системные процессы размещаются в отдельных компонентах, так что все данные и функции внутри каждого компонента семантически связаны (так же, как с содержимым классов). Из-за этого принципа часто говорят, что компоненты являются модульными и связными.
Таким образом, согласно этому определению, компонент может быть чем угодно, если он действительно хорошо выполняет одну вещь и только одну.
Что касается общесистемной координации, компоненты взаимодействуют друг с другом через интерфейсы. [...] Этот принцип приводит к тому, что компоненты называются инкапсулированными.
Так что это все больше и больше напоминает то, что мы думаем о хорошем API или SOA.
Предоставленные интерфейсы представлены леденцом на палочке, а необходимые интерфейсы представлены символом открытого сокета, прикрепленным к внешнему краю компонента в UML.
Другим важным атрибутом компонентов является то, что они являются заменяемыми, так что компонент может быть заменен другим (во время разработки или во время выполнения), если компонент-преемник удовлетворяет требованиям исходного компонента (выраженным через интерфейсы).
Возможность повторного использования является важной характеристикой высококачественного программного компонента. Программный компонент должен быть спроектирован и реализован таким образом, чтобы его можно было повторно использовать во многих различных программах.
Заменимость и возможность повторного использования - вот что делает компонент компонентом. Так в чем же разница между этим и объектно-ориентированным программированием?
Идея объектно-ориентированного программирования (ООП) состоит в том, что программное обеспечение должно быть написано в соответствии с мысленной моделью реальных или воображаемых объектов, которые оно представляет. [...]
В отличие от этого, разработка программного обеспечения на основе компонентов не делает таких предположений и вместо этого утверждает, что программное обеспечение следует разрабатывать путем склеивания готовых компонентов, как в области электроники или механики.
Вот мое определение после некоторых исследований.
Компонентно-управляемая разработка - это подход в разработке программного обеспечения, при котором код фрагментируется на повторно используемые и тестируемые компоненты, которые объединяются вместе, образуя основу приложения для предоставления бизнес-функциональности. Комбинация и управление компонентами обычно делегируются Inversion of Control Container.
Сам компонент - это класс, который реализует некоторый контракт на обслуживание и явно определяет зависимости, которые ему необходимы для выполнения этого контракта. Фактическая реализация скрыта от всех остальных за пределами компонента.
Ссылки по теме:
Я рассматриваю компонентную программную инженерию как подход к разработке программных систем с использованием сменных компонентов; с компонентом, являющимся "единицей композиции с указанными в контракте интерфейсами и только явными зависимостями контекста", которая "может быть развернута независимо и зависит от сторонней композиции". (Клеменс Шиперски, " Компонентное программное обеспечение: помимо объектно-ориентированного программирования")
CBSE облегчает повторное использование кода и быструю сборку гибких / адаптируемых программных систем.
Есть существенное исследование, которое было сосредоточено на этой теме в течение многих лет. Флагманское мероприятие ( Симпозиум ACM SIGSOFT по разработке программного обеспечения на основе компонентов) проводится уже 14-й год, и появляется немало новых тенденций.
Кроме того, если вы хотите получить хороший пример многоразовых, подключаемых и расширяемых компонентов, которые сегодня широко используются в промышленности, посмотрите MS Enterprise Library.
Если вы заинтересованы в объединении компонентов (или других повторно используемых ресурсов) в приложениях, вам также следует взглянуть на методологию программных продуктов.
В линейке программных продуктов зависимости между компонентами (или элементами кода более низкого уровня) явно управляются вне этих компонентов. Обычно это делается с помощью модели объектов, которая содержит такие правила, как
- Эти два компонента не должны использоваться вместе (взаимная исключительность)
- Если этот компонент используется, то этот другой компонент должен использоваться или (взаимозависимость)
- Может использоваться любая комбинация определенного набора компонентов (необязательно)
Другие более сложные правила возможны в зависимости от сложности зависимостей, которые вы хотите смоделировать.
Другой подход, который иногда используется вместо моделирования функций, заключается в использовании генератора кода для настройки различных компонентов, которые должны быть собраны в готовое приложение. Также возможно объединить моделирование объектов с генерацией кода.
Помимо генерации кода, некоторые другие термины, которые вы можете искать в качестве предметно-ориентированного моделирования, разработки программного обеспечения на основе моделей, семейства программ.
Вы никогда не поймете, что такое разработка на основе компонентов, пока не попробуете использовать Unity 3D. Это не ActiveX или что-то, что вы когда-либо видели раньше, то, что вы видели раньше, имеет другое значение компонента.
Компонентно-управляемая разработка, о которой все говорят в последнее время, означает, что у вас есть 2 вещи:
- Объект - который подобен объекту в программировании ООП или объекту реального мира.
- Компонент объекта - который является частью функциональности объекта или одной из его способностей.
Таким образом: Компонент - это не Объект.Это - Функциональность Объекта.
Таким образом, в стандартном программировании ООП, когда вам необходимо расширить Базовый объект с помощью новой функциональности, вы должны создать новый производный объект путем наследования базового объекта.
В разработке, управляемой компонентами, когда вам нужен расширенный объект, вы просто создаете пустой объект и заполняете его различными компонентами без какого-либо наследования. В компонентно-управляемой разработке нет классов, вместо них есть префабы - предопределенные объекты с предопределенными компонентами, дочерние объекты.
Как я сказал, вы никогда не поймете, пока не попробуете. При разработке на основе компонентов вам не всегда нужно использовать программирование, вместо этого вы можете использовать графические редакторы, а также это освобождает вас от Inheritance Hell типичного ООП. Компоненты сами программируются с помощью обычного программирования, но системе более высокого уровня, включая объекты, в основном нужно только использовать и комбинировать компоненты в редакторе и получать настроенное поведение объектов.
Таким образом: Компонентно-управляемая разработка дает вам:
- Большая сила для создания логики вашей программы, используя только редактор, без программирования.
- Освобождает ваш разум от ООП Наследственного Ада. Делает разработку более простой и быстрой.
- Делает вашу программу легко настраиваемой и масштабируемой, даже не касаясь кода. Меньше ошибок и ошибок.
- Проще поддерживать код вашей программы, просто перепрограммируя определенные компоненты, без особого влияния на остальную систему.
- так далее...
Я также хочу добавить, что компонентное (управляемое) программирование не является заменой для ООП-программирования, оно находится в ТОП ООП или обычного программирования. Обычное программирование все еще используется в CBP для реализации Компонента низкого уровня. Я думаю, что в этой статье также есть хорошее и краткое объяснение CBP: http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf