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

Question

Компонентно-ориентированная разработка термин начинает широко использоваться, особенно в связи с инверсией управления.

1. Что это?
2. Какие проблемы это решает?
3. Когда это уместно, а когда нет?

Answer 1

Что это?

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

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

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

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

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

Answer 2

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

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

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

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

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

• GUI
• пусковая
• dispatcher (для диспетчеризации вычислений на нескольких серверах, потому что одному не хватило бы памяти для вычисления всех!)
• и пр.

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

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

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

Answer 3

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

Ответ, который вы ищете, скорее всего, будет найден в Почему и что из обращения Инверсии Контроля Ке Джина.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 4

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

CBSE облегчает повторное использование кода и быструю сборку гибких / адаптируемых программных систем.

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

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

Answer 5

Вот мое определение после некоторых исследований.

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

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

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

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

Answer 6

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

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

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

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

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

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

Answer 7

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

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

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

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

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

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

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

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

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

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