inversion of control - dependency - ¿Qué es el desarrollo impulsado por componentes?
inversion of control spring (7)
El término de desarrollo impulsado por componentes está empezando a usarse ampliamente, esp. En relación con la inversión de control.
- ¿Qué es?
- ¿Qué problemas resuelve?
- ¿Cuándo es apropiado y cuándo no?
¿Qué es?
Creo que la definición en tu respuesta cubre bien esta pregunta. Aunque cuestiono por qué la definición incluye que un componente necesita definir explícitamente sus dependencias. Un ejemplo canónico de un componente es un control ActiveX: ¿necesitan definir explícitamente sus dependencias?
¿Qué problemas resuelve?
Gestión de la complejidad. Busca abordar eso permitiéndole solo pensar en la implementación del componente. Solo se debe tener que crear componentes, no se debe tener que pensar en cómo combinarlos o administrarlos. Esto se hace mediante algún marco o infraestructura externa al componente, y no es importante para el autor del componente.
¿Cuándo es apropiado y cuándo no?
No necesariamente apropiado en una aplicación trival o desechable. El mal olor en una arquitectura de componentes es si está gastando tiempo pensando o trabajando en la infraestructura para administrar y combinar componentes, en lugar de los componentes en sí.
Considero que la ingeniería de software basada en componentes es un enfoque para desarrollar sistemas de software mediante el uso de componentes conectables; siendo un componente " una unidad de composición con interfaces especificadas contractualmente y dependencias de contexto explícitas ", que " se puede implementar de forma independiente y está sujeta a la composición de terceros ". (Clemens Szyperski, " Software de componentes: más allá de la programación orientada a objetos ")
CBSE facilita la reutilización de códigos y el ensamblaje rápido de sistemas de software flexibles / adaptables.
Hay una investigación importante que se ha centrado en este tema durante años. El evento emblemático ( ACM SIGSOFT Symposium sobre ingeniería de software basada en componentes ) está en el 14º año y hay algunas nuevas tendencias emergentes.
Además, si desea un buen ejemplo de componentes reutilizables, enchufables y extensibles, muy utilizados en la industria actual, eche un vistazo a MS Enterprise Library .
El desarrollo basado en componentes no es nada realmente nuevo. No sé de desarrollo impulsado por componentes, pero voy a asumir que es el CDB. Es cómo está diseñado Unix, un montón de pequeños programas sustituibles que hacen una cosa muy bien. En el ámbito de las computadoras de escritorio, el VCL de Delphi ha tenido éxito en el uso de componentes con componentes reutilizables ricos y un mercado de terceros como ningún otro. Ahora estamos viendo la reactivación del CDB a medida que algunas tecnologías están madurando. Por ejemplo, las aplicaciones web simples están evolucionando a SOA y RESTful WS. Todos los chicos de Java de los que hemos estado hablando son de modularidad e IoC.
La respuesta que está buscando probablemente se encontrará en Por qué y qué de Inversión de control por Ke Jin.
Además, el imperativo natural de estos lenguajes de programación OO clásicos tiende a pasar por alto el bosque (arquitecturas / estructuras de alto nivel) para los árboles (código de procedimiento de control lógico de bajo nivel). Los ingenieros de desarrollo y mantenimiento que se hacen cargo de una aplicación existente tienen que confiar en sus documentos de diseño / arquitectura desactualizados y en los comentarios / patrones de código de bajo nivel.
El paradigma de desarrollo basado en componentes (CDB) aborda los dos problemas anteriores al cambiar la lógica de la plomería a marcos que manipulan componentes y configuran aplicaciones basadas en usuarios / desarrolladores que proporcionan descripciones declarativas. Contrariamente a la confusión común, tales descripciones declarativas no pretenden ser scripts de configuración de aplicaciones. Más bien, su intención fundamental es expresar explícitamente las arquitecturas / estructuras de aplicación sin exigir sus procedimientos de plomería imperativos (a saber, describir qué en lugar de cómo). El objetivo del paradigma de CBD es respaldar las composiciones de aplicaciones efectivas y flexibles con estos marcos y que los desarrolladores de aplicaciones se centren en la lógica de negocios y los problemas de dominio sin tener en cuenta las complejidades de la plomería de bajo nivel.
Los marcos de CBD que combinan las descripciones de aplicaciones declarativas y la técnica de IoC se conocen como marcos de IoC. Al contrario de sus predecesores, los marcos de IoC no son invasivos y utilizan el escenario de configuración / inyección de configuración / dependencia .
Según Wikipedia, el desarrollo basado en componentes es un alias para la ingeniería de software basada en componentes (CBSE) .
[Es] una rama de la ingeniería de software, cuya prioridad es la separación de inquietudes con respecto a la amplia funcionalidad disponible en un sistema de software determinado.
Esto es algo vago, así que veamos más detalles.
Un componente individual es un paquete de software, o un módulo, que encapsula un conjunto de funciones relacionadas (o datos).
Todos los procesos del sistema se colocan en componentes separados, de modo que todos los datos y funciones dentro de cada componente están relacionados semánticamente (al igual que con el contenido de las clases). Debido a este principio, a menudo se dice que los componentes son modulares y cohesivos .
Entonces, de acuerdo con esta definición, un componente puede ser cualquier cosa siempre y cuando haga una cosa realmente bien y solo una cosa.
Con respecto a la coordinación de todo el sistema, los componentes se comunican entre sí a través de interfaces . [...] Este principio resulta en componentes referidos como encapsulados .
Así que esto suena cada vez más como debería ser una buena API o SOA.
Las interfaces proporcionadas están representadas por una paleta y las interfaces requeridas están representadas por un símbolo de socket abierto adjunto al borde exterior del componente en UML.
Otro atributo importante de los componentes es que son sustituibles , por lo que un componente podría ser reemplazado por otro (en tiempo de diseño o en tiempo de ejecución), si el componente sucesor cumple los requisitos del componente inicial (expresados a través de las interfaces).
La reutilización es una característica importante de un componente de software de alta calidad. Un componente de software debe diseñarse e implementarse para que pueda reutilizarse en muchos programas diferentes.
Sustitución y reutilización es lo que hace que un componente sea un componente. Entonces, ¿cuál es la diferencia entre esto y la programación orientada a objetos?
La idea en la programación orientada a objetos (OOP) es que el software debe escribirse de acuerdo con un modelo mental de los objetos reales o imaginarios que representa. [...]
La ingeniería de software basada en componentes, por el contrario, no hace tales suposiciones y, en cambio, establece que el software debe desarrollarse pegando los componentes prefabricados como en el campo de la electrónica o la mecánica.
No estoy seguro de que sea una terminología "generalizada", pero en VCS (Sistema de control de versiones), conozco dos formas de administrar un conjunto de archivos necesarios para crear un programa:
- enfoque basado en el sistema , donde todo el conjunto tiene un ciclo de vida común y debe etiquetarse como un todo
- enfoque basado en componentes, donde los conjuntos de archivos individuales tienen su propio ciclo de vida y donde una etiqueta meta hace referencia a todas las etiquetas de los componentes para designar todo el sistema por composición y dependencias entre esos componentes.
La arquitectura aplicativa se utiliza para identificar aquellos componentes:
- dominio funcional y aplicaciones
- bibliotecas de terceros
- marcos
Ahí es donde entra IoC, ya que está en la base de cualquier marco. El problema que resuelve es permitirle identificar mejor la parte de su aplicación:
Supongamos que diseña una aplicación PLR (Ganancias y pérdidas), encargada de calcular las ganancias y pérdidas (posición) de un operador.
Rápidamente se dará cuenta de que no es una aplicación única, sino una composición de varias:
- GUI
- lanzacohetes
- despachador (para enviar el cómputo a través de varios servidores, porque uno no tendría suficiente memoria para computar todo)
- Etcétera
Luego puede identificar un marco de cómputo (Ioc) que le permitiría conectar sus diferentes módulos, que luego serán llamados en el momento adecuado por su marco.
O puede identificar marcos puramente técnicos (KPI, registros, gestión de excepciones) que luego pueden ser utilizados por cualquiera de sus otros componentes funcionales .
En términos de gestión de proyectos, que también le permite desarrollar cada parte de forma independiente, al tiempo que asegura una coordinación global a través del VCS.
Nunca entenderás lo que es realmente un desarrollo impulsado por componentes, hasta que trates de usar Unity 3D. No es ActiveX o algo que hayas visto antes, lo que has visto antes tiene otro significado de componente.
El desarrollo impulsado por componentes, sobre todos los que hablan últimamente, significa que tienes 2 cosas:
- Objeto - que es como un objeto en la programación OOP o un objeto del mundo real.
- El Componente del Objeto - que es como parte de la funcionalidad del Objeto o una de sus Habilidades.
Por lo tanto: Componente - no es un Objeto. Es - Funcionalidad de un objeto .
Por lo tanto, en la programación estándar de POO, cuando necesita extender el objeto base con una nueva funcionalidad, debe crear un nuevo objeto derivado al heredar el objeto base.
En el desarrollo controlado por componentes, cuando necesita un objeto extendido, simplemente crea un objeto vacío y lo llena con diferentes componentes, sin ninguna herencia. En el desarrollo impulsado por componentes no hay clases, en su lugar hay prefabs , que son objetos predefinidos con componentes predefinidos, con objetos hijos.
Como dije, nunca lo entenderás hasta que lo intentes. Con el desarrollo basado en componentes, no siempre tiene que usar la programación, puede usar editores gráficos en su lugar, y también lo libera de Inheritance Hell of OOP típico. Los componentes programados con la programación habitual, pero el sistema de nivel superior, incluidos los objetos, en su mayoría solo necesitan usar y combinar Componentes en el Editor y recibir el comportamiento personalizado de los objetos.
Por lo tanto: el desarrollo impulsado por componentes le ofrece:
- Gran poder para crear la lógica de su programa, usando solo un Editor, sin programación.
- Libera tu mente de OOP Herencia del infierno. Hace que el desarrollo sea más simple y rápido.
- Hace que su programa sea altamente personalizable y escalable sin siquiera tocar el código. Menos errores y errores.
- Mantenga el código de su programa de forma más sencilla, simplemente reprogramando componentes específicos, sin afectar mucho el sistema de descanso.
- etc ...
También quiero agregar, que la programación basada en componentes (basada en componentes) no reemplaza a la programación OOP, está en TOP of OOP o la programación habitual. La programación habitual todavía se utiliza en CBP para la implementación de componentes de bajo nivel. Creo que este artículo también tiene una buena y breve explicación de CBP: http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf
Si está interesado en combinar componentes (u otros activos reutilizables) en aplicaciones, también debería echar un vistazo a la metodología de líneas de productos de software .
En una línea de productos de software, las dependencias entre componentes (o elementos de código de nivel inferior) se gestionan explícitamente fuera de esos componentes. Esto se hace normalmente usando un modelo de características que contiene reglas como
- Estos dos componentes no deben usarse juntos (exclusividad mutua)
- Si se usa este componente, entonces se debe usar este otro componente o (interdependencia)
- Se puede usar cualquier combinación de un conjunto específico de componentes (opcionalidad)
Otras reglas más complejas son posibles dependiendo de la complejidad de las dependencias que desea modelar.
Otro enfoque que a veces se usa en lugar del modelado de características es usar un generador de código para configurar los diferentes componentes que se ensamblarán en la aplicación terminada. También es posible combinar el modelado de características con la generación de código.
Aparte de Code Generation, algunos otros términos que puede buscar como modelado de dominio específico, desarrollo de software basado en modelos, familia de software.
Aquí está mi definición después de hacer algunas investigaciones.
El desarrollo impulsado por componentes es un enfoque en el desarrollo de software en el que el código se fragmenta en componentes reutilizables y comprobables que se combinan para formar la base de la aplicación para brindar funcionalidad empresarial. La combinación y la gestión de los componentes generalmente se delegan al contenedor de control de inversión .
Un componente en sí mismo es una clase que implementa algún contrato de servicio y define explícitamente las dependencias que necesita para cumplir este contrato. La implementación real está oculta para todos los demás fuera del componente.
Enlaces relacionados: