Что такое разработка, управляемая компонентами?

Что это?

Думаю, определение в вашем ответе хорошо отвечает на этот вопрос. Хотя я сомневаюсь, почему это определение включает то, что компонент должен явно определять свои зависимости. Каноническим примером компонента является элемент управления ActiveX - нужно ли им явно определять свои зависимости?

Какие проблемы решает?

Управление сложностью. Он пытается решить эту проблему, позволяя вам думать только о реализации компонента. Нужно только создавать компоненты, не нужно не думать о том, как их комбинировать или управлять ими. Это делается какой-то структурой или инфраструктурой, внешней по отношению к компоненту и неважной для автора компонента.

Когда это уместно, а когда нет?

Не обязательно уместно в заявке на выброс или выброс. Плохой запах компонентной архитектуры возникает, если вы тратите время на размышления или работу над инфраструктурой, чтобы управлять и комбинировать компоненты, а не сами компоненты.

Я не уверен, что это «широко распространенная» терминология, но в VCS (системе контроля версий) я знаю два способа управления набором файлов, необходимых для создания программы:

• системный подход, при котором весь набор имеет общий жизненный цикл и должен быть отмеченным как все
• компонентный подход, при котором отдельный набор файлов имеет свой собственный жизненный цикл, а мета-метка ссылается на все метки компонентов, чтобы обозначить всю систему по составу и зависимостям между этими компонентами.

Для идентификации этих компонентов используется прикладная архитектура:

• функциональная область и приложения
• сторонние библиотеки
• рамки

Здесь на помощь приходит IoC, поскольку он лежит в основе любого фреймворка. Проблема, которую он решает, позволяет вам лучше идентифицировать часть вашего приложения:
Предположим, вы разрабатываете приложение PLR (прибыль и убыток), отвечающее за вычисление прибыли и убытков (позиции) трейдера.
Вы быстро поймет, что это не одно приложение, а композиция из нескольких:

• Графический интерфейс
• пусковая установка
• диспетчер (для отправки вычислений по нескольким серверам, потому что у одного не хватит памяти, чтобы вычислить все!)
• и так далее

Затем вы можете определить платформу вычислений (Ioc), которая позволит вам подключать различные модули, которые затем вызываются в нужное время вашей структурой.

Или вы можете определить чисто технические рамки (KPI, журналы, управление исключениями), которые затем могут использоваться любым другим вашим < em> функциональные компоненты.

Что касается управления проектами, это также позволяет вам разрабатывать каждую часть независимо, обеспечивая при этом глобальную координацию через VCS.

В разработке на основе компонентов нет ничего нового. Я не знаю о разработке, управляемой компонентами, но предполагаю, что это CBD. Так устроен Unix: куча заменяемых небольших программ, каждая из которых очень хорошо выполняет одну задачу. На арене настольных ПК Delphi VCL, как никто другой, преуспела в использовании компонентов с богатым набором компонентов многократного использования и на стороннем рынке. Сейчас мы наблюдаем возрождение CBD по мере взросления некоторых технологий. Например, простые веб-приложения развиваются до SOA и RESTful WS. Все, о чем говорят Java-ребята, - это модульность и IoC.

Ответ, который вы ищете, вероятно, будет найден в Почему и что в инверсии управления пользователя Ke Jin.

Кроме того, императивное естество этих классических языков объектно-ориентированного программирования имеет тенденцию упускать из виду лес (высокоуровневые архитектуры / структуры) за деревьями (процедурный код низкоуровневого логического управления). Инженеры по разработке и обслуживанию, принимающие существующее приложение, должны полагаться на его устаревшие документы по дизайну / архитектуре и комментарии / шаблоны кода низкого уровня.

Парадигма компонентно-ориентированной разработки (CBD) решает две вышеупомянутые проблемы, перемещая логику подключения к фреймворкам, которые манипулируют компонентами и настраивают приложения на основе декларативных описаний, предоставленных пользователями / разработчиками. Вопреки распространенному заблуждению, такие декларативные описания не предназначены для использования в сценариях установки приложения. Скорее, их фундаментальное намерение состоит в том, чтобы явно выразить архитектуры / структуры приложений, не требуя их обязательных процедур сантехники (а именно, описать что, а не как). Целью парадигмы CBD является поддержка эффективных и гибких составов приложений с помощью этих фреймворков и сосредоточение разработчиков приложений на бизнес-логике и проблемах предметной области, не затрагивая низкоуровневые сложности сантехники.

Структуры CBD, сочетающие декларативные описания приложений и технику IoC, называются структурами IoC. В отличие от своих предшественников, инфраструктуры IoC являются неинвазивными и используют сценарий внедрения / настройки зависимости / конфигурации.

Согласно Википедии, компонентная разработка - это псевдоним для Компонентной разработки программного обеспечения (CBSE).

[Это] отрасль разработки программного обеспечения, приоритетом которой является разделение проблем в отношении широких функциональных возможностей, доступных во всей данной программной системе.

Это несколько расплывчато, поэтому давайте рассмотрим подробнее.

Отдельный компонент - это программный пакет или модуль, который инкапсулирует набор связанных функций (или данных).

Все системные процессы помещены в отдельные компоненты, так что все данные и функции внутри каждого компонента связаны семантически (как и с содержимым классов). Из-за этого принципа часто говорят, что компоненты являются модульными и связными.

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

Что касается общесистемной координации, компоненты взаимодействуют друг с другом через интерфейсы. [...] Этот принцип приводит к тому, что компоненты называются инкапсулированными.

Так что это все больше и больше похоже на то, как мы думаем о хорошем API или SOA.

Предоставленные интерфейсы представлены леденцом, а обязательные интерфейсы представлены символом открытого сокета, прикрепленным к внешнему краю компонента в UML.

_{(источник: wikimedia.org)}

Еще одним важным атрибутом компонентов является то, что они заменяемы, так что компонент может быть заменен другим (во время разработки или во время выполнения), если требования исходного компонента (выраженные через интерфейсы) выполняются компонентом-преемником.

Возможность повторного использования - важная характеристика высококачественного программного компонента. Программный компонент должен быть спроектирован и реализован так, чтобы его можно было повторно использовать во многих различных программах.

Возможность замены и повторного использования - вот что делает компонент компонентом. Так в чем разница между этим и объектно-ориентированным программированием?

Идея объектно-ориентированного программирования (ООП) заключается в том, что программное обеспечение следует писать в соответствии с ментальной моделью реальных или воображаемых объектов, которые оно представляет. [...]

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

Вот мое определение после небольшого исследования.

Компонентно-ориентированная разработка - это подход к разработке программного обеспечения, при котором код фрагментируется на повторно используемые и тестируемые компоненты, которые объединяются вместе, чтобы сформировать основу приложения для предоставления бизнес-функций. Комбинация компонентов и управление ими обычно делегируются контейнеру Inversion of Control.

Сам компонент - это класс, который реализует некоторый контракт службы и явно определяет зависимости, необходимые для выполнения этого контракта. Фактическая реализация скрыта от всех, кроме компонента.

Ссылки по теме:

• Компонентно-ориентированная разработка и контейнер IoC

Я рассматриваю компонентно-ориентированную разработку программного обеспечения как подход к разработке программных систем с использованием подключаемых компонентов; с компонентом, являющимся «единицей композиции только с указанными в контракте интерфейсами и явными зависимостями контекста», который «может быть развернут независимо и зависит от сторонней композиции». (Клеменс Шиперски, "Компонентное программное обеспечение: за пределами объектно-ориентированного программирования ")

На эту тему уже много лет проводится серьезное исследование. Флагманское мероприятие (Симпозиум ACM SIGSOFT по разработке программного обеспечения на основе компонентов) проводится уже 14-й год. появляется довольно много новых тенденций.

Кроме того, если вам нужен хороший пример повторно используемых, подключаемых и расширяемых компонентов, широко используемых сегодня в отрасли, взгляните на Библиотека MS Enterprise.

Если вы заинтересованы в объединении компонентов (или других повторно используемых ресурсов) в приложения, вам также следует взглянуть на линейки программных продуктов.

В линейке программных продуктов зависимости между компонентами (или элементами кода нижнего уровня) явно управляются вне этих компонентов. Обычно это делается с помощью модели функций, которая содержит такие правила, как

• Эти два компонента нельзя использовать вместе (взаимная исключительность)
• Если этот компонент используется, то должен использоваться этот другой компонент или (взаимозависимость)
• Может использоваться любая комбинация определенного набора компонентов (необязательно).

Возможны и другие более сложные правила в зависимости от сложности зависимостей, которые вы хотите смоделировать.

Другой подход, который иногда используется вместо моделирования функций, заключается в использовании генератора кода для настройки различных компонентов, которые должны быть собраны в готовое приложение. Также возможно комбинировать моделирование функций с генерацией кода.

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

Вы никогда не поймете, что такое разработка на основе компонентов, пока не попытаетесь использовать Unity 3D. Это не ActiveX или что-то, что вы когда-либо видели раньше, то, что вы видели раньше, имеет другое значение Компонента.

Компонентно-ориентированная разработка, о которой все говорят в последнее время, означает, что у вас есть 2 вещи:

1. Объект - похож на объект в ООП-программировании или объект реального мира.
2. Компонент объекта - что-то вроде части функциональности объекта или одной из его способностей.

Таким образом: Компонент - это не Объект. Это - Функциональность объекта.

Итак, в стандартном программировании ООП, когда вам нужно расширить базовый объект с помощью новой функциональности, вы должны создать новый производный объект путем наследования базового объекта.

При разработке, управляемой компонентами, когда вам нужен расширенный объект, вы просто создаете пустой объект и заполняете его различными компонентами без какого-либо наследования. В компонентно-ориентированной разработке нет классов, вместо них есть Prefabs - предопределенные объекты с предопределенными компонентами с дочерними объектами.

Как я уже сказал, вы никогда не поймете, пока не попытаетесь. При разработке, управляемой компонентами, вам не нужно всегда использовать программирование, вместо этого вы можете использовать графические редакторы, а также это освобождает вас от ада наследования типичного ООП. Сами компоненты запрограммированы с помощью обычного программирования, но система более высокого уровня, включая объекты, в основном нуждается только в использовании и объединении компонентов в редакторе и получении настраиваемого поведения объектов.

Таким образом: Компонентно-ориентированная разработка дает вам:

1. Великолепные возможности для создания логики вашей программы, используя только редактор, без программирования.
2. Освобождает ваш разум от ада наследования ООП. Делает разработку более простой и быстрой.
3. Делает вашу программу легко настраиваемой и масштабируемой, даже не касаясь кода. Меньше ошибок и багов.
4. Легче поддерживать код вашей программы, просто перепрограммируя определенные компоненты, без особого влияния на систему отдыха.
5. и т.д...

Я также хочу добавить, что программирование на основе компонентов (управляемое) не является заменой программирования ООП, оно находится на вершине ООП или обычного программирования. Обычное программирование все еще используется в CBP для реализации Компонента низкого уровня. Я думаю, что в этой статье также есть хорошее и краткое объяснение CBP: http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf