Existe uma diferença entre um componente e um módulo


31

Estou com um pequeno problema com os termos módulo e componente. Na minha opinião, um módulo são classes agrupadas, que só são acessíveis através de uma interface bem definida. Eles ocultam todos os detalhes da implementação e são reutilizáveis. Módulos definem módulos dos quais eles dependem.

Qual é a diferença para os componentes? Procurei em alguns livros, mas a descrição dos componentes é muito semelhante.


5
Qual língua? Qual arquitetura? Sua definição de módulo funciona. Penso em um componente como algo que se conecta a algo como, por exemplo, uma GUI, enquanto um módulo não pode se conectar a uma GUI; Os módulos podem funcionar em uma GUI, se agrupados / suportados pelas construções da GUI.
Guy Coder

3
Consulte Classe vs. Componente vs. Controle Nota: Não estou respondendo porque sua pergunta não menciona linguagem ou arquitetura.
Guy Coder

Sim, neste caso, penso nas definições em geral
Mirco

2
Não estou atrás de pontos, mais depois de ter certeza de obter uma resposta válida. Se você achar isso válido, fique à vontade para editar sua pergunta e adicionar o link como a resposta preferida. Não a postarei como resposta, porque a pergunta é muito geral e uma resposta específica pode causar problemas a outras pessoas.
precisa

Sim, acho que minha pergunta é muito geral e a resposta realmente depende do idioma ou do ambiente usado. Nerver achou que havia muitas definições diferentes para esses termos.
Mirco

Respostas:


12

Os termos são semelhantes. Eu geralmente penso em um "módulo" como sendo maior que um "componente". Um componente é uma parte única, geralmente com escopo relativamente pequeno, possivelmente de uso geral. Os exemplos incluem controles da interface do usuário e "componentes de segundo plano", como cronômetros, assistentes de segmentação etc. Um "módulo" é uma parte maior do todo, geralmente algo que executa uma função primária complexa sem interferência externa. Pode ser a biblioteca de classes de um aplicativo que fornece integração com email ou banco de dados. Pode ser do tamanho de uma única aplicação de um conjunto, como o "módulo Contas a Receber" de uma plataforma de ERP / contabilidade.

Eu também penso em "módulos" como sendo mais intercambiáveis. Os componentes podem ser replicados, com os novos parecidos com os antigos, mas sendo "melhores" de alguma forma, mas geralmente o design do sistema depende mais estritamente de um componente (ou de uma substituição projetada para estar em conformidade com o comportamento muito específico desse componente). Em termos não relacionados a computadores, um "componente" pode ser o bloco do motor de um carro; você pode mexer no motor, até mesmo substituí-lo completamente, mas o carro deve ter um motor e deve estar em conformidade com especificações muito rígidas, como dimensões, peso, pontos de montagem etc. para substituir o motor "em estoque" que o carro foi originalmente projetado para ter. Um "módulo", por outro lado, implica a funcionalidade do tipo "plug-in"; qualquer que seja esse módulo, ele pode ser comunicado de maneira tão leve que o módulo pode ser removido e / ou substituído com um efeito mínimo em outras partes do sistema. O sistema elétrico de uma casa é altamente modular; você pode conectar qualquer coisa com um plugue de 120V15A a qualquer tomada de 120V15A e esperar que o que você está conectando funcione. A fiação da casa não se importava com o que está conectado onde, desde que as demandas de energia em qualquer ramo do sistema não excedam os limites de segurança.


4
Todas as respostas realmente me ajudaram, mas só posso aceitar uma. Então eu aceito o KeithS porque ele tem o menor representante
Mirco

12

O significado genérico de módulo é um grupo de código reutilizável, não vinculado a um programa específico. Isso pode ser tudo, desde um conjunto inteiro de bibliotecas da GUI até uma única classe.

O significado genérico de componente é um módulo com a restrição adicional de substituibilidade usando uma interface específica. Se você criar um componente GUI Widget, ele poderá ser usado em qualquer lugar que um Widget seja esperado, sem precisar fazer nada de especial no código de chamada. Os módulos em geral não têm essa restrição. Qt e GTK + são módulos, mas não posso trocar um pelo outro sem um trabalho considerável no código que o chama, portanto, não são componentes.

Muitas estruturas ou linguagens de programação usam os termos para significar algo muito mais específico, e é por isso que as pessoas estão perguntando sobre o contexto. Algo pode ser um componente no sentido genérico, mas se não implementar uma IComponentinterface muito específica , pode não ser considerado um componente no contexto. Em python, moduletem o significado técnico muito específico de algo que você pode obter usando um importcomando. Geralmente, as pessoas estão se referindo a esses significados específicos do contexto.


Sua definição é boa, mas seu exemplo (Qt vs. GTK +) é falho (embora eu concorde que não chamaria nenhum deles de componente também). O IMHO Qt e o GTK + contêm centenas de pequenos componentes, resultando em uma coleção muito ampla de interfaces. Isso torna muito improvável que alguém invista tempo para criar uma substituição compatível com a interface para um deles, e esse é o IMHO o motivo pelo qual eles não são componentes. No entanto, o fato de duas partes do software não poderem ser trocadas não as desqualifica como componentes, apenas como componentes com uma interface comum.
Doc Brown

9

Se quisermos abstrair de linguagens, estruturas e suas próprias interpretações particulares, a hierarquia de granularidade de software abstrato é a seguinte:

Product - application, library, service
  Module - GUI, core logic, data, etc...
    Component - purpose specific collection of objects
      Object - collection of primitives
        Primitive - numbers, functions, etc...
  • produtos

Puro e simples, o Produto é uma coleção de módulos funcionais conectados.

  • Módulo

Como o próprio nome indica, a motivação de um módulo é modularidade. Ao contrário do que muitos afirmam, não implica realmente a reutilização de código. Existem muitos módulos que não são realmente reutilizáveis ​​e não se encaixam em nada para o qual não foram projetados.

É importante separar diferentes camadas de software, o que facilita muito a implementação e a manutenção do software e, caso seja necessário reimplementar algo como um front end para uma estrutura de GUI diferente, a modularidade permite que isso aconteça de maneira fácil e segura, sem quebrar código em todo o lugar.

Um módulo encapsula uma coleção de componentes que servem a um propósito comum, conforme definido pelos requisitos do módulo. Um módulo deve ser independente e completo e, embora não seja realmente utilizável por si só, deve poder trabalhar em conjunto com qualquer implementação em conformidade.

  • Componente

Em termos de granularidade, o Componente fica entre o Módulo e o Objeto. O objetivo de um componente é reunir uma coleção de objetos de uso geral para formar uma unidade específica de objetivo.

Como o nome indica, ao contrário do Módulo, o Componente não é "autônomo", é parte de um todo funcional maior.

  • Objeto

Os objetos são os blocos menores de componentes. Os objetos são coleções de primitivos e os unem para servir a um nível mais baixo, mais universal e, ainda assim, a um propósito específico.

  • Primitivo

As primitivas são o nível mais pequeno, mais simples e mais baixo de granularidade no desenvolvimento de software. É basicamente apenas números inteiros e reais e funções / operadores, embora a maioria dos idiomas tenha seus próprios "cidadãos de primeira classe".

Há muito pouco que você pode fazer com os primitivos e, ao mesmo tempo, é em um nível tão baixo que você pode realizar praticamente tudo com ele. É apenas muito, muito detalhado, insanamente complicado e impossivelmente tedioso de se realizar enquanto trabalha diretamente com os primitivos.

  • Qual o sentido disso tudo?

Como já mencionado acima, trabalhar com primitivas diretamente é uma péssima idéia. Não apenas porque é impossivelmente complexo, lento e tedioso para o desenvolvimento de software moderno, mas também é extremamente invasivo e obstrutivo para testes e manutenção.

A incorporação de todas essas partes conceituais no desenvolvimento de software torna mais fácil, rápido, simples e seguro. Você não cria uma casa com átomos, independentemente de quão versáteis e universais sejam os átomos. Isso seria um exercício de futilidade. Seus átomos são suas primitivas, a argila é seu objeto, os tijolos são seus componentes, paredes, piso e teto são seus módulos, reunidos para manifestar o produto final.

Os seres humanos realmente não inventam nada, apenas descobrimos coisas que já existem no universo e as copiamos e aplicamos em nossas vidas. A mesma hierarquia de granularidade é intrínseca ao próprio universo, de átomos e até abaixo, a moléculas orgânicas, proteínas, tecidos, órgãos, organismos e acima, a própria realidade obedece ao mesmo princípio - combinando coisas abstratas pequenas, simples, com funções limitadas e com propósitos. coisas maiores, mais complexas, mais funcionais e coisas mais específicas.

  • Advertências de terminologia

Tecnicamente, todos são "objetos", todos são "componentes" do desenvolvimento de software, são todos "modulares" o suficiente para serem capazes de se encaixarem, são todos "produtos" no sentido de que foram produzidos e assim por diante. ..

Não se trata de terminologia ou nomenclatura, mas de como a ampliação e ampliação das coisas afeta vários aspectos da criatividade e da produtividade. E sobre a importância de não apenas usar todos esses níveis diferentes, mas também a importância de não tentar atingir uma meta no nível errado, o que só pode ser contraproducente.


11
Sua versão do módulo parece um pacote.
JM Becker

11
@JMBecker não é realmente, em termos de granularidade, um pacote pode consistir em qualquer coisa, de uma coleção de objetos a um produto independente completo. O empacotamento é mais uma conveniência para a reutilização de código do que um link na cadeia de granularidade.
dtech

3

Depende do seu contexto. O módulo já é usado para se referir a grupos de níveis de DLL em alguns idiomas, semelhante a 'package' ou 'assembly' em outros. Component é usado para itens COM, bem como para componentes baseados em entidades, comuns no desenvolvimento de jogos.

Em termos de arquitetura geral, módulo e componente tendem a se referir a algum pacote de código por trás de uma interface bem definida. Em geral, o módulo tende a se referir a pacotes maiores. Muitas vezes, há um conjunto de interfaces e o módulo tende a ser independente.

Os componentes, por outro lado, tendem a ser pacotes menores de código, geralmente menores que uma classe completa. Pelo nome, eles tendem a ser um componente de algo maior. Às vezes, esse é o próprio aplicativo, mas com o aumento do uso da composição no design de classes, significa mais frequentemente um componente de um objeto maior. As interfaces bem definidas para componentes também tendem a permitir que o aplicativo troque componentes entre si. Os módulos tendem a não ter essa capacidade de troca.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.