Что такое разработка, основанная на компонентах?
================================================

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

* Что это такое?
* Какие проблемы он разрешает?
* Когда это подходит, а когда нет?

 

>  Что это?
> 
> 
> 

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

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

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

>  Когда это подходит, а когда нет?
> 
> 
> 

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

 

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

Ответ, который вы ищете, скорее всего, будет найден в [Почему и что из-за инверсии управления](http://www.pocomatic.com/docs/whitepapers/ioc/) Ke Jin.

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

Согласно Википедии, компонентное развитие является псевдонимом для [Разработка программного обеспечения на основе компонентов (CBSE)](http://en.wikipedia.org/wiki/Component-based_software_engineering).

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

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

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

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

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

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

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

 [alt text http://upload.wikimedia.org/wikipedia/en/2/25/Component-based\_Software\_Engineering\_%28CBSE%29\_-\_example\_2.gif](http://upload.wikimedia.org/wikipedia/en/2/25/Component-based_Software_Engineering_%28CBSE%29_-_example_2.gif)

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

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

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

 

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

* [системный подход](/questions/6502/vendor-branches-in-git/49431#49431), где весь набор имеет общий жизненный цикл и должен быть помечен как все
* компонентный подход, где отдельный набор файлов имеет собственный жизненный цикл и где мета-метка ссылается на все метки компонентов для обозначения всей системы по составу и зависимостям между этими компонентами.

Адаптивная архитектура [используется для идентификации этих компонентов:](/questions/7069/software-design-vs-software-architecture/52747#52747)

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

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

Предположим, вы разработали приложение PLR (Profit and Loss), отвечающее за вычисление прибыли и убытков (позиции) трейдера.   

Вы бы быстро поняли, что это не одно приложение, а состав нескольких:

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

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

Или вы можете идентифицировать чисто [технические рамки](/questions/7070/should-application-architects-write-code) (KPI, журналы, управления исключениями), которые затем могут использоваться любым из ваших других функциональных компонентов.

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

 

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

Разработка с использованием компонентов - это подход к разработке программного обеспечения, в котором код фрагментирован в многоразовые и тестируемые компоненты, которые объединены вместе, чтобы сформировать основу приложения для предоставления бизнес-функций. Комбинация и управление компонентами обычно делегируются [Inversion of Control](http://abdullin.com/wiki/inversion-of-control-ioc.html) Контейнер.

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

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

* [Разработка компонентов и контейнер IoC](http://abdullin.com/journal/2009/5/31/component-driven-development-and-ioc-containers.html)

 

Я рассматриваю программную инженерию на основе компонентов как подход к разработке программных систем с помощью подключаемых компонентов; с компонентом, являющимся "единицей композиции с контрактными интерфейсами и явными контекстными зависимостями", которые "могут быть развернуты независимо и подчинены третьей стороне". (Clemens Szyperski, " [Компонентное программное обеспечение: вне объектно-ориентированного программирования](http://rads.stackoverflow.com/amzn/click/0201178885)" )

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

Там есть существенные исследования, которые были посвящены этой теме в течение многих лет. Флагманское событие ([Симпозиум ACM SIGSOFT по разработке программного обеспечения на основе компонентов](http://cbse-conferences.org/2011/)) уже на 14-м году, и появилось немало новых тенденций.

Кроме того, если вы хотите хороший пример многоразовых, подключаемых и расширяемых компонентов, которые сегодня широко используются в промышленности, посмотрите  [**MS Enterprise Библиотека**](http://msdn.microsoft.com/en-us/library/ff953181%28PandP.50%29.aspx).

 

Если вы заинтересованы в объединении компонентов (или других многоразовых активов) в приложения, вы также должны взглянуть на [программные продукты](http://www.software-acumen.com/about-product-lines/) методология.

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

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

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

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

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

 

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

Развитие, основанное на компонентах, о каждом разговоре в последнее время, означает, что у вас есть 2 вещи:

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

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

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

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

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

Таким образом: Разработка с использованием компонентов дает вам:

* Отличная возможность создавать вашу программную логику, используя только редактор, без программирования.
* Освобождает ваш ум от афоризма. Делает разработку более простой и быстрой.
* Делает вашу программу очень настраиваемой и масштабируемой, даже не касаясь кода. Меньше ошибок и ошибок.
* Проще всего сохранить программный код, просто перепрограммируя определенные компоненты, не оказывая большого влияния на систему отдыха.
* и т.д...

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