O que é Component-Driven Development?

Question

Component-Driven Development termo está começando a se acostumar muito, esp. em conexão com inversão de controle.

1. O que é isso?
2. Quais os problemas que ele resolve?
3. Quando é apropriado e quando não?

Answer 1

O que é isso?

Eu acho que a definição na sua resposta abrange esta questão também. Embora, eu pergunta por que a definição inclui que um necessidades de componentes para definir explicitamente suas dependências. Um exemplo canônico de um componente é um controle ActiveX? - eles precisam definir explicitamente suas dependências

Quais os problemas que ele resolve?

Gerenciamento de complexidade. Destina-se a endereço que ao permitir que você sempre apenas pensar sobre a implementação do componente. Um só deve componentes autor, deve-se não ter que pensar sobre como combinar ou gerenciá-los. Isso é feito por alguma estrutura ou infra-estrutura externa ao componente, e sem importância para o autor componente.

Quando é apropriado e quando não?

Não necessariamente apropriado em um trival ou jogá-away aplicação. O mau cheiro em uma arquitetura de componentes, é se você está gastando tempo pensando ou trabalhando na infra-estrutura para gerenciar e combinar componentes, em vez dos próprios componentes.

Answer 2

Eu não estou certo de que é uma terminologia "generalizada", mas em VCS (Versão Control System), eu sei de duas maneiras de gerenciar um conjunto de arquivos necessários para construir um programa:

• baseado no sistema abordagem , onde o todo conjunto tem uma vida comum ciclo e deve ser marcado como um todo
• abordagem componente baseado, onde conjunto individual de arquivos têm seu próprio ciclo de vida, e onde um referências meta-etiquetar todos os rótulos dos componentes para designar o todo o sistema de composição e dependências entre esses componentes.

O aplicativo arquitetura é usado para identificar os componentes:

• domínio funcional e aplicações
• bibliotecas de terceiros
• estruturas

É aí que IoC vem, uma vez que está na base de qualquer quadro. O problema que resolve é permitir que você para melhor identificar a parte do seu aplicativo:
Suponha que você projetar uma PLR (lucros e perdas) da aplicação, encarregada de calcular o ganho e perdas (posição) de um comerciante.
Você rapidamente percebe que não é uma única aplicação, mas uma composição de vários:

• GUI
• lançador
• despachante (para despachar o cálculo através de diversos servidores, porque não teria memória suficiente para computar tudo!)
• e assim por diante

Você pode, então, identificar um quadro de computação (COI), que permitirá que você plug-in seus diferentes módulos, que, em seguida, são chamados no momento certo pelo seu quadro.

Ou você pode identificar puramente estruturas técnicas (KPI, registros, gerências de exceção), que pode então ser usado por qualquer um seu outro funcional componentes.

Em termos de gestão do projecto, que também permite que você desenvolva cada parte de forma independente, garantindo ao mesmo tempo uma coordenação global através do VCS.

Answer 3

Desenvolvimento Baseado em Componentes há nada realmente novo. Eu não sei de Desenvolvimento de Componentes-Driven, mas eu vou assumir que é CBD. É como Unix é projetado, grupo de pequenos programas substituíveis cada um fazendo uma coisa muito bem. Na arena de desktop, VCL do Delphi tem sido bem sucedida em usar componentes com ricos componentes reutilizáveis ??e mercado de terceiros como nenhum outro. Agora estamos vendo o renascimento da CBD como algumas tecnologias estão amadurecendo. Por exemplo aplicações web simples estão evoluindo para SOA e RESTful WS. Todos os caras Java sido falando é modularidade e IoC.

A resposta que você está procurando provavelmente serão encontradas em Por que eo que de Inversão de Controle por Ke Jin.

Além disso, o natural imperativo da essas linguagens de programação clássico OO tendem a perder a floresta (high-level arquiteturas / estruturas) para o árvores (controlo lógico de baixo nível código de procedimento). Desenvolvimento e engenheiros de manutenção que retomem uma aplicação existente tem que confiar em o seu fora do projeto de data / arquitetura documentos e código de baixo nível Comentários / padrões.

O desenvolvimento baseado em componentes (CBD) paradigma aborda as duas questões acima deslocando lógica encanamento em quadros que manipulam componentes e configurar aplicações baseadas em usuários / declarativa desenvolvedores forneceu descrições. Ao contrário do comum confusão, tais declarativa as descrições não são destinadas a ser scripts de instalação do aplicativo. Em vez, sua intenção fundamental é expressar explicitamente aplicação arquiteturas / sem estruturas determinando seu encanamento imperativo procedimentos (nomeadamente descrever o que em vez do fazer). O objetivo da CBD paradigma é apoiar eficaz e As composições de aplicação flexíveis, estas estruturas e tendo desenvolvedores de aplicativos se concentrar em lógica de negócios e questões de domínio sem se preocupar encanamento de baixo nível complexidades.

estruturas CBD que combinam a descrições de aplicação declarativa ea técnica IoC são referidos como estruturas COI. Ao contrário do seu antecessores, frameworks de IoC são não-invasivo e use o dependência / configuração de injecção / cenário de configuração .

De acordo com a Wikipedia, Desenvolvimento Baseado em Componentes é um alias para componente de software (CBSE ) .

[Ele] é um ramo do software engenharia, cuja prioridade é separação de interesses no que diz respeito da funcionalidade ampla disponível em todo um determinado software sistema.

Este é um pouco vago, então vamos olhar para obter mais detalhes.

Um componente individual é um software pacote, ou um módulo, que encapsula um conjunto de relacionados funções (ou dados).

Todos os processos do sistema são colocadas em componentes separados, de modo que todo o dados e das funções dentro de cada componente são semanticamente relacionados (Assim como com o conteúdo do Aulas). Devido a este princípio, muitas vezes é dito que os componentes são modular e coesa .

Assim, de acordo com esta definição, um componente pode ser qualquer coisa, desde que ele faz uma coisa muito bem e apenas uma coisa.

Com relação a todo o sistema coordenação, componentes comunicam uns com os outros através de Interfaces . [...] Este princípio resulta em componentes referidos como encapsulada .

Então, isso está soando mais e mais parecido com o que pensamos de uma boa API ou SOA deve ser parecida.

O fornecido interfaces são representados por um pirulito e necessário interfaces são represented por um símbolo encaixe aberto ligado ao bordo exterior do componente em UML.

_{(fonte: wikimedia. org )}

Outro atributo importante de componentes é que eles são substituíveis , de modo que um componente Pode ser substituído por um outro (em projetar tempo ou tempo de execução), se o requisitos do componente inicial (Expresso através das interfaces) sejam satisfeitas pelo componente sucessor.

Reutilização é uma importante característica de uma alta qualidade componente de software. Um software componente deve ser concebido e implementado para que ele possa ser reutilizado em muitos programas diferentes.

A substituibilidade e reutilização é o que torna um componente a componente. Então, qual é a diferença entre este e Programação Orientada a Objetos?

A idéia de objeto orientado programação (OOP) é ??que o software deve ser escrita de acordo com uma modelo mental do real ou imaginado objetos que representa. [...]

componente de software

, por contraste, não faz tal suposições, e em vez estados que software deve ser desenvolvido pela colagem componentes pré-fabricados em conjunto muito como no campo da eletrônica ou mecânica.

Answer 4

Aqui está a minha definição depois de fazer alguma pesquisa.

Component-Driven Development é uma abordagem no desenvolvimento de software no qual o código está fragmentado em componentes reutilizáveis ??e testáveis ??que são combinados em conjunto para fundação aplicativo de formulário para a entrega de funcionalidade de negócios. A combinação e gestão dos componentes é geralmente delegada a inversão de controle recipiente.

Um componente em si é uma classe que implementa algum contrato de serviço e explicitamente define as dependências de que necessita para cumprir este contrato. implementação real está escondido de todo mundo fora do componente.

Links relacionados:

• Component-Driven Development e IoC Container

Answer 5

I ver Baseado em Componentes Engenharia de Software como uma abordagem para o desenvolvimento de sistemas de software através do uso de componentes conectáveis; com um ser componente " uma unidade de composição com interfaces contratualmente especificadas e contexto explícito dependências única ", que " pode ser implementado de forma independente e é sujeito a composição de terceiros ." (Clemens Szyperski, " software Componente: além de programação orientada a objetos ")

CBSE facilita a reutilização de código e rápida montagem de sistemas de software flexíveis / adaptáveis.

Há uma substancial de investigação que tem sido focada sobre este tema há anos. O evento principal ( ACM SIGSOFT Simpósio sobre baseada em componentes de engenharia de software ) está no 14º ano agora e há algumas novas tendências emergentes.

Além disso, se você quer um bom exemplo de componentes reutilizáveis, plugáveis ??e extensíveis, pesadamente em uso pela indústria de hoje, dar uma olhada em MS Enterprise Library .

Answer 6

Se você estiver interessado em combinar componentes (ou outros ativos reutilizáveis) em aplicações que você deve também dar uma olhada no linhas de produtos de software metodologia.

Em uma linha de produto de software as dependências entre os componentes (ou elementos de código de nível mais baixo) são explicitamente gestão fora desses componentes. Isso geralmente é feito usando um modelo de recurso que contém regras como

• Estes dois componentes não devem ser usados ??em conjunto (exclusividade mútua)
• Se este componente é usado, em seguida, esse outro componente deve ser usado ou (interdependência)
• Qualquer combinação de um conjunto específico de componentes pode ser utilizado (optionality)

Outras regras mais complexas são possíveis, dependendo da complexidade das dependências você deseja modelar.

Outra abordagem que é por vezes utilizado em vez de modelagem de recursos é usar um gerador de código para configurar as diferentes componentes que estão a ser montado na aplicação final. Também é possível combinar modelagem de recursos com a geração de código.

Além de geração de código, alguns outros termos que você pode procurar a modelagem específica de domínio, desenvolvimento de software orientado a modelo, família software.

Answer 7

Você nunca vai entender o que é realmente Component-Driven Development, até que você tente usar Unity 3D. Não é ActiveX ou qualquer coisa que você já viu antes, o que você tem visto antes tem outro significado componente.

desenvolvimento

Componente-Driven, sobre cada um falando ultimamente, meio, você tem 2 coisas:

1. objeto -. Que é como um objeto na programação OOP ou objeto mundo real
2. O Component Object -. Que é como parte da funcionalidade do objeto ou uma de suas habilidades

Assim: Component - não é um objeto. É -. Funcionalidade de um objeto

Assim, a programação OOP padrão, quando você precisa estender objeto de base com a nova funcionalidade, você tem que fazer um novo objeto derivado por objeto herdante Base.

desenvolvimento no componente-Driven, quando você precisa estendida Object, você acabou de criar objecto Vazio e preenche-lo com diferentes componentes, sem qualquer herança. No desenvolvimento Component-Driven não há aulas, há Prefabs em vez -. Que é predefinido objetos com componentes pré-definidos, com Crianças Objectos

Como eu disse que você nunca vai entender até que você tente. Com o desenvolvimento de componentes-drived você não tem que usar sempre a programação, você pode usar editores gráficos em vez disso, e também libera você de Herança Inferno de OOP típico. Componentes si programado com a programação de costume, mas o sistema de nível superior, incluindo objetos, a maioria só precisa de usar e combinar componentes no editor e receber comportamento objetos personalizados.

Assim: Component-Driven Development dá-lhe:

1. Great poder de criar a lógica do seu Programa, usando apenas um editor, sem programação.
2. Libera sua mente de OOP Herança Inferno. Torna o desenvolvimento mais simples e rápido.
3. Faz o seu programm altamente personalizável e escalonável sem código de sequer tocar. Menos erros e bugs.
4. Mais fácil manter o código do seu Programa, por apenas reprogramação componentes específicos, sem muita sistema de resto efetivação.
5. etc ...

Eu também quero acrescentar que, com base em componentes (driven) programação não é substituto para a programação OOP, ele está no topo da OOP ou programação habitual. programação de costume ainda usado em CBP para a implementação de baixo nível do componente. Acho que este artigo também têm boa e breve explicação da CBP: http: //acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf