O que é desenvolvimento orientado a componentes?

O termo Desenvolvimento Orientado a Componentes está começando a ser usado amplamente, esp. em conexão com a Inversão de Controle.

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

    O que é isso?

    Eu acho que a definição na sua resposta cobre bem essa questão. Embora eu questione por que a definição inclui que um componente precisa definir explicitamente suas dependencies. Um exemplo canônico de um componente é um controle ActiveX – eles precisam definir explicitamente suas dependencies?

    Que problemas isso resolve?

    Gestão de complexidade. Ele procura resolver isso permitindo que você pense apenas na implementação do componente. É preciso apenas criar componentes, não se deve pensar em como combiná-los ou gerenciá-los. Isso é feito por algum framework ou infraestrutura externa ao componente, e sem importância para o autor do componente.

    Quando é apropriado e quando não?

    Não necessariamente apropriado em um aplicativo trival ou descartável. O cheiro ruim em uma arquitetura de componentes é se você está gastando tempo pensando ou trabalhando na infraestrutura para gerenciar e combinar componentes, em vez dos próprios componentes.

    Eu não tenho certeza se é uma terminologia “generalizada”, mas no VCS (Sistema de Controle de Versão), eu sei de duas maneiras de gerenciar um conjunto de arquivos necessários para construir um programa:

    • abordagem baseada no sistema , onde o conjunto tem um ciclo de vida comum e deve ser marcado como um todo
    • abordagem baseada em componente, em que um conjunto individual de arquivos tem seu próprio ciclo de vida e em que um meta-label faz referência a todos os labels dos componentes para designar todo o sistema por composição e dependencies entre esses componentes.

    A arquitetura aplicativa é usada para identificar esses componentes:

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

    É aí que entra o IoC, já que está na base de qualquer framework. O problema que ele resolve é permitir que você identifique melhor a parte do seu aplicativo:
    Suponha que você projete uma aplicação de PLR ​​(Lucro e Perda), encarregada de computar o ganho e as perdas (posição) de um negociante.
    Você perceberia rapidamente que não é um aplicativo único, mas uma composição de vários:

    • GUI
    • lançador
    • dispatcher (para despachar o cálculo através de vários servidores, porque um não teria memory suficiente para computar tudo!)
    • e assim por diante

    Em seguida, você pode identificar uma estrutura de computação (IOC) que permite que você conecte seus diferentes módulos, que são chamados na hora certa pelo seu framework.

    Ou você pode identificar estruturas puramente técnicas (KPI, logs, gerenciamento de exceções) que podem ser usadas por qualquer um de seus outros componentes funcionais .

    Em termos de gerenciamento de projetos, isso também permite que você desenvolva cada parte de forma independente, assegurando uma coordenação global através do VCS.

    O desenvolvimento baseado em componentes não é nada realmente novo. Eu não conheço Desenvolvimento Orientado a Componentes, mas vou assumir que é CBD. É como o Unix é projetado, um monte de pequenos programas substituíveis, cada um fazendo uma coisa muito bem. Na área de desktops, o VCL da Delphi tem obtido sucesso no uso de componentes com componentes reutilizáveis ​​ricos e mercado de terceiros como nenhum outro. Estamos vendo agora o renascimento da CDB à medida que algumas tecnologias estão amadurecendo. Por exemplo, os aplicativos da web simples estão evoluindo para SOA e RESTful WS. Todos os caras de Java estão falando sobre modularidade e IoC.

    A resposta que você está procurando provavelmente será encontrada em Por que e o que dizer de Inversão de Controle por Ke Jin?

    Além disso, o imperativo natural dessas linguagens de programação clássicas OO tendem a perder a floresta (arquiteturas / estruturas de alto nível) para as trees (código processual de controle lógico de baixo nível). Os engenheiros de desenvolvimento e manutenção que assumem um aplicativo existente precisam confiar em seus documentos de design / arquitetura desatualizados e comentários / padrões de código de baixo nível.

    O paradigma de desenvolvimento baseado em componentes (CBD) aborda os dois problemas acima, deslocando a lógica de encanamento para estruturas que manipulam componentes e configuram aplicativos baseados em descrições declarativas de usuários / desenvolvedores. Ao contrário da confusão comum, essas descrições declarativas não devem ser scripts de configuração de aplicativos. Em vez disso, sua intenção fundamental é expressar explicitamente arquiteturas / estruturas de aplicativos sem impor seus procedimentos imperativos de encanamento (ou seja, descrever o que, em vez do como). O objective do paradigma CBD é oferecer suporte a composições de aplicativos eficazes e flexíveis por essas estruturas e fazer com que os desenvolvedores de aplicativos se concentrem na lógica de negócios e nos problemas de domínio sem se preocupar com complexidades de encanamento de baixo nível.

    Estruturas CBD que combinam as descrições de aplicativo declarativo e a técnica IoC são chamadas de estruturas IoC. Ao contrário de seus predecessores, as estruturas IoC não são invasivas e usam o cenário de configuração / injeção de dependência / configuração .

    Segundo a Wikipedia, o desenvolvimento baseado em componentes é um alias para a engenharia de software baseada em componentes (CBSE) .

    [It] é um ramo da engenharia de software, cuja prioridade é a separação de preocupações em relação à ampla funcionalidade disponível em um determinado sistema de software.

    Isso é um tanto vago, então vamos ver mais detalhes.

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

    Todos os processos do sistema são colocados em componentes separados, de modo que todos os dados e funções dentro de cada componente sejam semanticamente relacionados (assim como o conteúdo das classs). Devido a esse princípio, costuma-se dizer que os componentes são modulares e coesos .

    Então, de acordo com essa definição, um componente pode ser qualquer coisa, desde que faça uma coisa realmente bem e apenas uma coisa.

    No que diz respeito à coordenação de todo o sistema, os componentes comunicam entre si através de interfaces . […] Este princípio resulta em componentes referidos como encapsulados .

    Então isso está soando mais e mais como o que achamos da boa API ou SOA deve ser.

    As interfaces fornecidas são representadas por um pirulito e as interfaces necessárias são representadas por um símbolo de soquete aberto conectado à borda externa do componente na UML.

    texto alternativo http://sofpt.miximages.com/components/Component-based_Software_Engineering_(CBSE)_-_example_2.gif

    Outro atributo importante dos componentes é que eles são substituíveis , de modo que um componente poderia ser substituído por outro (em tempo de design ou em tempo de execução), se os requisitos do componente inicial (expressos pelas interfaces) forem atendidos pelo componente sucessor.

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

    Substituibilidade e reutilização é o que faz de um componente um componente. Então, qual é a diferença entre isso e programação orientada a objects?

    A idéia na programação orientada a objects (OOP) é ​​que o software deve ser escrito de acordo com um modelo mental dos objects reais ou imaginários que ele representa. […]

    A engenharia de software baseada em componentes, ao contrário, não faz tais suposições e, em vez disso, afirma que o software deve ser desenvolvido pela colagem de componentes pré-fabricados juntos, assim como no campo da eletrônica ou da mecânica.

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

    O desenvolvimento orientado a componentes é uma abordagem no desenvolvimento de software na qual o código é fragmentado em componentes reutilizáveis ​​e testáveis ​​que são combinados para formar a base de aplicativos para fornecer funcionalidade de negócios. A combinação e o gerenciamento de componentes geralmente são delegates ao Inversion of Control Container.

    Um componente em si é uma class que implementa algum contrato de serviço e define explicitamente as dependencies de que necessita para cumprir este contrato. A implementação real é ocultada de todos os outros fora do componente.

    Links Relacionados:

    • Desenvolvimento Orientado a Componentes e Recipiente IoC

    Eu vejo a Engenharia de Software Baseada em Componentes como uma abordagem para o desenvolvimento de sistemas de software através do uso de componentes conectáveis; com um componente sendo ” uma unidade de composição com interfaces contratualmente especificadas e dependencies de contexto explícitas apenas “, que ” podem ser implantadas independentemente e estão sujeitas à composição de terceiros “. (Clemens Szyperski, ” Software de componentes: além da programação orientada a objects “)

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

    Há uma pesquisa substancial que tem sido focada neste tópico há anos. O evento principal ( ACM SIGSOFT Symposium on Component Based Software Engineering ) está no 14º ano e há algumas novas tendências surgindo.

    Além disso, se você quiser um bom exemplo de componentes reutilizáveis, plugáveis ​​e extensíveis, muito utilizados atualmente pela indústria, dê uma olhada na MS Enterprise Library .

    Se você estiver interessado em combinar componentes (ou outros ativos reutilizáveis) em aplicativos, você também deve dar uma olhada na metodologia de linhas de produtos de software .

    Em uma linha de produtos de software, as dependencies entre componentes (ou elementos de código de nível inferior) são explicitamente gerenciadas fora desses componentes. Isso geralmente é feito usando um modelo de recurso que contém regras como

    • Estes dois componentes não devem ser usados ​​juntos (exclusividade mútua)
    • Se este componente é usado, então este outro componente deve ser usado ou (interdependência)
    • Qualquer combinação de algum conjunto especificado de componentes pode ser usada (opcional)

    Outras regras mais complexas são possíveis dependendo da complexidade das dependencies que você deseja modelar.

    Outra abordagem que às vezes é usada em vez de modelagem de resources é usar um gerador de código para configurar os diferentes componentes que devem ser montados no aplicativo finalizado. Também é possível combinar modelagem de resources com geração de código.

    Além da Geração de Código, alguns outros termos que você pode pesquisar como modelagem específica de domínio, desenvolvimento de software orientado por modelo, família de software.

    Você nunca entenderá o que é realmente Desenvolvimento orientado a componentes, até tentar usar o Unity 3D. Não é ActiveX ou qualquer coisa que você já viu antes, o que você viu antes tem outro significado de Componente.

    O desenvolvimento baseado em componentes, sobre cada um falando ultimamente, significa que você tem duas coisas:

    1. Object – que é exatamente como um object na programação OOP ou no object do mundo real.
    2. Componente do Objeto – que é como parte da funcionalidade do Objeto ou uma de suas Habilidades.

    Assim: Componente – não é um object. É – Funcionalidade de um Objeto .

    Portanto, na programação OOP padrão, quando você precisa estender o Objeto Base com a nova Funcionalidade, é necessário criar um novo Objeto Derivado por Herdando Objeto Base.

    No desenvolvimento baseado em componentes, quando você precisa de um object estendido, basta criar um Objeto vazio e preenchê-lo com componentes diferentes, sem nenhuma inheritance. No desenvolvimento orientado a componentes não há Classes, existem prefábricas pré- fabricadas – que são objects pré-definidos com componentes predefinidos, com objects filhos.

    Como eu disse, você nunca vai entender até que você tente. Com o desenvolvimento orientado a componentes, você não tem que usar sempre programação, você pode usar editores charts, e também libera você do Inheritance Hell do típico OOP. Os próprios componentes são programados com programação usual, mas o sistema de nível superior, incluindo objects, geralmente só precisa usar e combinar Componentes no Editor e receber comportamento de objects personalizados.

    Assim: O desenvolvimento orientado a componentes oferece:

    1. Grande poder para criar a lógica do seu programa, usando apenas um editor, sem programação.
    2. Liberta a sua mente do inferno de inheritance OOP. Torna o desenvolvimento mais simples e rápido.
    3. Torna o seu programa altamente personalizável e escalável sem sequer tocar no código. Menos erros e erros.
    4. Mais fácil manter o código do seu programa, apenas reprogramando componentes específicos, sem muito efeito do sistema de descanso.
    5. etc …

    Eu também quero acrescentar, que a programação baseada em componentes (orientada) não é substituta para a programação OOP, está no TOP da OOP ou na programação usual. Programação usual ainda usada no CBP para implementação de componentes de baixo nível. Eu acho que este artigo também tem uma boa e breve explicação do PFC: http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf