¿Hay alguna diferencia entre un componente y un módulo?

Tengo un pequeño problema con los términos módulo y componente. En mi opinión, un módulo son clases agrupadas, a las que solo se puede acceder a través de una interfaz bien definida. Ocultan todos los detalles de implementación y son reutilizables. Los módulos definen módulos de los que dependen.

¿Cuál es la diferencia con los componentes? Lo busqué en algunos libros, pero la descripción de los componentes es muy similar.

Los términos son similares. Generalmente pienso que un "módulo" es más grande que un "componente". Un componente es una sola parte, generalmente de alcance relativamente pequeño, posiblemente de uso general. Los ejemplos incluyen controles de IU y "componentes de fondo" como temporizadores, asistentes de subprocesos, etc. Un "módulo" es una parte más grande del conjunto, generalmente algo que realiza una función primaria compleja sin interferencia externa. Podría ser la biblioteca de clases de una aplicación que proporciona integración con el correo electrónico o la base de datos. Puede ser tan grande como una sola aplicación de una suite, como el "módulo de Cuentas por cobrar" de una plataforma ERP / contable.

También pienso en los "módulos" como más intercambiables. Los componentes se pueden replicar, y los nuevos se parecen a los viejos pero son "mejores" de alguna manera, pero generalmente el diseño del sistema depende más estrictamente de un componente (o un reemplazo diseñado para ajustarse al comportamiento muy específico de ese componente). En términos no informáticos, un "componente" puede ser el bloque del motor de un automóvil; puede jugar dentro del motor, incluso reemplazarlo por completo, pero el automóvil debe tener un motor, y debe cumplir con especificaciones muy rígidas como dimensiones, peso, puntos de montaje, etc., para reemplazar el motor "original" que el automóvil fue originalmente diseñado para tener. Un "módulo", por otro lado, implica la funcionalidad de tipo "plug-in"; cualquiera que sea ese módulo, se puede comunicar de una manera tan liviana que el módulo se puede quitar y / o reemplazar con un efecto mínimo en otras partes del sistema. El sistema eléctrico de una casa es altamente modular; puede enchufar cualquier cosa con un enchufe de 120V15A en cualquier receptáculo de 120V15A y esperar que funcione lo que está conectando. Al cableado de la casa no le importa lo que esté enchufado, siempre que las demandas de energía en cualquier rama del sistema no excedan los límites de seguridad.

El significado genérico de módulo es un grupo de código reutilizable, no vinculado a un programa específico. Esto podría ser todo, desde un conjunto completo de bibliotecas GUI hasta una sola clase.

El significado genérico de componente es un módulo con la restricción adicional de sustituibilidad utilizando una interfaz específica. Si crea un componente de widget de GUI, se puede usar en cualquier lugar donde se espere un widget, sin tener que hacer nada especial en el código de llamada. Los módulos en general no tienen esa restricción. Qt y GTK + son módulos, pero no puedo intercambiar uno por otro sin un trabajo considerable en el código que lo llama, por lo tanto, no son componentes.

Muchos frameworks o lenguajes de programación usan los términos para significar algo mucho más específico, por eso la gente pregunta sobre el contexto. Algo puede ser un componente en el sentido genérico, pero si no implementa una IComponentinterfaz muy específica , puede no considerarse un componente en contexto. En python, moduletiene el significado técnico muy específico de algo que puedes obtener usando un importcomando. Por lo general, las personas se refieren a estos significados específicos del contexto.

Si vamos a abstraer de lenguajes particulares, marcos y sus propias interpretaciones, la jerarquía de granularidad de software abstracta es la siguiente:

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

• Producto

Claro y simple, el Producto es una colección funcional de módulos funcionales conectados.

• Módulo

Como su propio nombre lo indica, la motivación de un Módulo es la modularidad. Al contrario de lo que muchos afirman, en realidad no implica la reutilización del código. Hay muchos módulos que no son realmente reutilizables y no encajan con nada para lo que no fueron diseñados.

Es importante separar las diferentes capas de software, lo que hace que el software sea mucho más fácil de implementar y mantener, y en caso de que sea necesario volver a implementar algo como un front end a un marco de GUI diferente, la modularidad permite que eso suceda de una manera fácil y segura, sin interrupciones código por todo el lugar.

Un módulo encapsula una colección de componentes que cumplen un propósito común según lo definido por los requisitos del módulo. Un módulo debe ser autónomo y completo, y aunque no sea realmente utilizable por sí solo, debe poder funcionar junto con cualquier implementación conforme.

• Componente

En términos de granularidad, el Componente se encuentra entre el Módulo y el Objeto. El propósito de un componente es reunir una colección de objetos de propósito general para formar una unidad específica de propósito.

Como su nombre lo indica, a diferencia del Módulo, el Componente no es "autónomo", es parte de un todo funcional más grande.

• Objeto

Los objetos son los bloques de construcción más pequeños de componentes. Los objetos son colecciones de primitivas y las unen para servir a un nivel inferior, más universal y con un propósito específico.

• Primitivo

Las primitivas son el nivel más pequeño, más simple y más bajo de granularidad de desarrollo de software. Básicamente es solo números enteros y reales y funciones / operadores, aunque la mayoría de los idiomas tienen sus propios "ciudadanos de primera clase" adicionales.

Es muy poco lo que puedes hacer con los primitivos, y al mismo tiempo, es a un nivel tan bajo que puedes lograr prácticamente todo con él. Es muy, muy detallado, increíblemente complicado e imposiblemente tedioso de lograr mientras se trabaja directamente con los primitivos.

• ¿Cuál es el punto de todo esto?

Como ya se mencionó anteriormente, trabajar con primitivas directamente es una idea extremadamente mala. No solo porque es imposiblemente complejo, lento y tedioso de hacer para el desarrollo de software moderno, sino que también es extremadamente molesto y obstructivo para las pruebas y el mantenimiento.

Tener todas esas partes conceptuales incorporadas en el desarrollo de software lo hace más fácil, más rápido, más simple y más seguro. No haces una casa con átomos, independientemente de cuán versátiles y universales sean los átomos. Eso sería un ejercicio de futilidad. Sus átomos son sus primitivos, la arcilla es su objeto, los ladrillos son sus componentes, las paredes, el piso y el techo son sus módulos, ensamblados juntos manifiestan el producto final.

Los humanos realmente no inventamos nada, solo descubrimos cosas que ya existen en el universo, y luego las copiamos y aplicamos a nuestras vidas. La misma jerarquía de granularidad es intrínseca al universo mismo, desde los átomos e incluso debajo, hasta las moléculas orgánicas, proteínas, tejidos, órganos, organismos y superiores, la realidad misma obedece al mismo principio: combinar cosas abstractas pequeñas, simples, de función limitada y propósito en Cosas más grandes, más complejas, más funcionales y más específicas.

• Advertencias de terminología

Técnicamente, todos son "objetos", son todos "componentes" del desarrollo de software, son todos lo suficientemente "modulares" para poder encajar, son todos "productos" en el sentido de que han sido producidos, etc. ..

No se trata de terminología o nomenclatura, se trata de cómo la ampliación de las cosas afecta a varios aspectos de la creatividad y la productividad. Y sobre la importancia de no solo usar todos esos niveles diferentes, sino también la importancia de no tratar de lograr un objetivo en el nivel incorrecto, que solo puede ser contraproducente.

Depende de tu contexto. El módulo ya se usa para referirse a grupos de nivel de DLL en algunos idiomas, como 'paquete' o 'ensamblado' en otros. Component se usa para cosas COM, así como para componentes basados ​​en entidades comunes en el desarrollo de juegos.

En términos arquitectónicos generales, módulo y componente tienden a referirse a algún paquete de código detrás de una interfaz bien definida. En general, el módulo tiende a referirse a paquetes más grandes. A menudo hay un conjunto de interfaces y el módulo tiende a ser independiente.

Los componentes, por otro lado, tienden a ser paquetes de código más pequeños, a menudo más pequeños que una clase completa. Por su nombre, tienden a ser un componente de algo más grande. A veces, esa es la aplicación en sí, pero con el uso creciente de la composición en el diseño de clase, con mayor frecuencia significa un componente de un objeto más grande. Las interfaces bien definidas para componentes también tienden a permitir que la aplicación intercambie componentes entre sí. Los módulos tienden a no tener esa capacidad de intercambio.