Speaker A
¿Qué tal? Mi nombre es Héctor de León y soy un programador que viene de la época donde el backend y el frontend eran uno. Hacíamos todo en un archivo, aunque los programadores de frontend exóticos quieren volver a eso. En este video vamos
Aprende a crear y entender componentes en programación para mejorar tu arquitectura de software con ejemplos prácticos en código.
Key Takeaways
- Un componente es una unidad funcional con funcionalidades relacionadas que facilita la organización del software.
- Minimizar el acoplamiento entre componentes es clave para mantener la independencia y facilitar cambios.
- Las interfaces permiten definir contratos claros sin depender de implementaciones específicas.
- El principio SOLID de inversión de dependencias mejora la modularidad y escalabilidad del código.
- Separar la lógica de negocio de la persistencia permite trabajar en paralelo y mantener el código más limpio.
Summary
- Introducción a la importancia del concepto de componente en la arquitectura de software.
- Definición de componente como unidad con funcionalidades relacionadas, como bibliotecas o módulos.
- Explicación del acoplamiento entre componentes y la importancia de minimizarlo.
- Diferenciación entre componentes de business (reglas de negocio) y repository (persistencia de datos).
- Uso de interfaces para definir contratos entre componentes sin depender de implementaciones concretas.
- Aplicación del principio SOLID de inversión de dependencias para mejorar la independencia entre componentes.
- Ejemplo práctico de cómo programar componentes con interfaces y clases concretas.
- Demostración de inyección de dependencias para manejar componentes en un proyecto de consola.
- Simulación de diferentes implementaciones para el componente repository sin afectar el componente business.
- Importancia de separar la lógica de negocio de la persistencia para facilitar el trabajo en equipo y mantenimiento.
Chapters
- 00:00Introducción y contexto histórico de backend y frontend
- 00:54Definición y ejemplos de componentes
- 01:59Concepto de acoplamiento y componentes repository y business
- 03:09Importancia del componente business y uso de interfaces
- 04:17Implementación y programación de interfaces y componentes
- 05:19Principio SOLID y dependencia de abstracciones
- 06:16Ejemplo práctico con métodos add y get en repository
- 08:14Inyección de dependencias y simulación de implementaciones
- 10:13Conclusión y recomendaciones para uso de componentes
Full Transcript — Download SRT & Markdown
Speaker A
a ver un tema que muchas personas que están adentrándose a la arquitectura de software desconocen o a veces no saben qué es un componente, pero sobre todo aquí no solamente vamos a explicar qué es un componente, vamos a programarlo. Así
Speaker A
que vamos a explicar por qué existe el concepto de componente y qué facilidades te va a dar este componente ya viéndolo en código. De hecho, estos videos de arquitectura de software deberían siempre tener la parte teórica y la
Speaker A
parte práctica. Por eso muchas personas no entienden la arquitectura de software. Así que en este canal vamos a verlo de esa manera. Así que veme dando un pulgar arriba. Ya sabes que los videos de arquitectura de software son escasos en
Speaker A
español en todo lo que es YouTube. Así que pulgarcito mañoso. Un componente es algo que vas a escuchar mucho en cualquier libro de arquitectura de software y un componente no es más que una unidad en la cual tú tienes
Speaker A
funcionalidades en común y estas funcionalidades en común, bueno, van a estar relacionadas, muy, muy relacionadas entre ellas. Por ejemplo, un componente podrá ser una biblioteca, una biblioteca matemática o podrá ser una biblioteca de cadenas, la famosa String. Y te fijas,
Speaker A
todos los métodos que están dentro de esa, de ese componente son relacionados sobre String, pero no solamente un componente es una biblioteca en sí, es una unidad que tú puedes dividir tu sistema en estas unidades de funcionamiento y este sería
Speaker A
un componente. ¿Por qué se hacen componentes o por qué existe el componente? El componente existe porque tú puedes trabajar con un equipo de programadores sobre ese componente y debe ser independiente de los otros componentes, es decir, no tienen que tener
Speaker A
relación fuerte con otros componentes, pero no deja de ver que tengas que tener cierta relación al final de cuentas. Y cuando un componente tiene relación con otro componente se le llama acoplamiento. Lo que vamos a tratar de hacer, aunque es
Speaker A
imposible hacerlo 100%, es quitar el acoplamiento entre componentes lo más que se pueda o el acoplamiento en sí. La dependencia del acoplamiento es que si un componente cambia, también cambiaría el que depende de ellos, por eso tenemos que evitar el acoplamiento, pero es
Speaker A
imposible completamente. Pero bueno, ¿qué es un componente en sí? Ya teóricamente vamos a dibujar algunos cuadritos. Tenemos aquí dos componentes, uno es la representación de repository, que vendría siendo la que tiene la persistencia, y tenemos el cuadrito de business. Business
Speaker A
sería las reglas de negocio. ¿Cuál es más importante? Estos dos cuadritos para la arquitectura de software, es más importante el business porque el business es lo que define que tu aplicación pueda cobrar, qué tu aplicación, qué es lo que hace tu
Speaker A
aplicación. Por ejemplo, en Uber, business es el que pueda dar un viaje y te busque el conductor. Por ejemplo, en la aplicación de buscar empleo, business es el que hace que tú busques los empleos, te regresa los resultados, te das
Speaker A
la cita con el empleador, etcétera. Business es esa parte. Repository simplemente es una parte que se va a encargar de guardar y modificar la información para business. Eso es
Speaker A
es algo secundario, es decir, es una herramienta simplemente. Repository, por lo cual
Speaker A
business es más importante que repository. Los componentes, cuando trabajamos de esta manera, tú podrías hacer en business interfaces las cuales tengan lo que necesitas de repository dentro de business. El componente business podremos tener una interfaz la cual tenga la
Speaker A
implementación, o no tenga la implementación, tenga los métodos que vamos a utilizar en business y podemos nosotros trabajar con esos métodos sin necesidad de haberlos creados, es decir, nosotros ya sabemos que para guardar necesitamos un método add, update, get, no
Speaker A
sé, delete, etcétera. Ya sabemos esos métodos, los conocemos, pero no sabemos si los vamos a guardar en archivos, si lo vamos a guardar en un servicio tercero, una base de datos, etcétera. Eso es secundario. Nosotros primero ya sabemos en business
Speaker A
que tenemos que hacer las reglas de negocio, que es la programación de hacer validar cosas, de hacer las políticas que necesitamos, todo eso es lo más importante en nuestra aplicación y lo secundario es el repositorio. Podemos nosotros trabajar en business
Speaker A
primeramente sin necesidad de tener la base de datos. Sabemos que esos métodos vamos a utilizar y sabemos cuántos son, cuáles son los parámetros que han de entrar y qué es lo que te regresa cada método, más la, más el cómo lo podría estar
Speaker A
programando otro equipo. Lo podemos programar después, es decir, el cómo lo va a tener repository esta parte del repository. Nosotros, cuando estemos trabajándolo, haremos esta interface. Nosotros en el componente repository tendremos las clases que hagan ese guardado. ¿Cómo se hace? Bueno,
Speaker A
ahí ya ser independiente a business. Business no le va a interesar cómo lo haces. Nosotros simplemente implementaríamos, nosotros la interface implementaremos la interface que es, pues esta, la repository, add, la, o inventar esta interface. Business sabe que
Speaker A
la hacemos, pero no le interesa, es decir, business de hecho ni siquiera sabe si vas a una base de datos, a un servidor externo, etcétera. Business lo único que le interesa es que implementes los métodos que él tiene en su interface repository,
Speaker A
porque esta interfaz internamente pues está trabajando con ella, ya independientemente de la implementación que hagas tú con tu componente de repositorio no le importa. De hecho, el único que se entera que existe business es repository. Business no se entera que
Speaker A
existe repository, más que sabe que hace cosas, no sabe cómo las hace y no le importa. Y aquí es donde entramos en la parte del código. ¿Cómo se hace un código? Primero nosotros vamos a depender de abstracciones y eso depende que la
Speaker A
abstracción puede ser una clase abstracta o una interface y eso, pues bueno, ¿por qué? Porque la interface, si te fijas, te dice qué es lo que haces, más no te dice cómo lo haces, es decir, a mí me
Speaker A
importa solamente saber que vamos a tener un repositorio que va a agregar cosas, que esas cosas va a tener un String y va a regresar cosas y esas cosas que me va a regresar va a ser un String. Es lo que me importa y es lo que
Speaker A
necesito yo para mi negocio. Mi negocio puede ser una clase que tenga administre cervezas, por ejemplo, una clase que internamente va a depender de una interface, de una abstracción. A mí lo único que me interesa de repository es
Speaker A
que va a agregar y va a obtener cosas y bueno, yo puedo eso meter y recibirlo en el constructor. De esta manera estamos respetando el principio SOLID de inversión de dependencias, en el cual solamente dependemos de abstracciones, no de implementaciones, siendo una
Speaker A
abstracción algo que define qué es lo que quieres hacer y una implementación es cómo lo estás haciendo y el cómo lo estás haciendo es cuando tú ya haces la clase. Entonces aquí estamos dependiendo de interface, por lo cual no sabemos cómo
Speaker A
se hace internamente y no me importa a mí. Solo lo único que me importa es que tengas un add que reciba un String y un get que me retorne un String. Cómo lo hagas a mí no me importa. De esta manera
Speaker A
yo puedo hacer mi método add dentro de beer manager, puedo poner validaciones, por ejemplo, si es null puedes mandar una excepción y si igual podría yo manejar una capa de errores, pero ahorita resolverlo con la excepción no es lo
Speaker A
mejor, obviamente. Y aquí vamos a ejecutar nuestro repository. Yo ya sé que repository tiene un método add que recibe un String. ¿Qué hace internamente? No me importa, si va a una base de datos, si va a un servicio externo, no me importa a
Speaker A
mí. Lo único que me importa es resolver el negocio y vamos a tener un método get que necesito, el String que me retorna el repositorio. Ahí está y le vamos a poner las cervezas son tal y de
Speaker A
esta manera yo ya puedo estar trabajando sin que esté implementado la fu...
Speaker A
tener el método que que es el add que recibe un String y ese add que recibe un String Pues yo igual puedo hacer que no tenga nada o sea simplemente para poder yo seguir trabajando con mi modelo de
Speaker A
negocio sin necesidad de hacer esto no Y podemos tener también el el este String que regresa la información y aquí simplemente vamos a poner que retorne un vacío Ahí está o algo ahí está de esta manera estamos cumpliendo con el
Speaker A
repositorio bien todo esto podemos tenerlo en el mismo en el mismo componente vamos a poner aquí unas unas llavecitas solamente para representar el mismo componente todo esto está dentro del mismo componente yo ya puedo estar trabajando sin necesidad de trabajar con
Speaker A
la base de datos Esto me va a resolver la base de datos como lo guarde etcétera y lo puedo ver después bien Entonces esto igual lo puede estar trabajando otro equipo de trabajo etcétera yo aquí yo puedo inyectar con inyección de
Speaker A
dependencia puedo inyectarlo que es algo que tienen todos los la mayoría de framework yo creo que ya todos los modernos lo tienen pero para eso necesitamos utilizar aquí una biblioteca que se llama dependency injection y con eso yo puedo inyectar las cosas vamos a
Speaker A
hacer un container el cual se puede hacer con service Collection en csar y este container es un proyecto de consola eh muchos no saben que aquí se puede utilizar inyección de dependencia vamos a agregarlo por singleton que singleton
Speaker A
aquí agrega los elementos e manera que sea único elemento por todo el sistema y si puedes observar aquí le decimos qué interfaz vamos a inyectar y le decimos qué implementación vamos a utilizar aquí estamos utilizando default eh repository
Speaker A
también vamos a agregar las clases que necesitan esa inyección en este caso be manager vamos a agregarla en transient que transient al al revés de singleton transient te crea una una una instancia una un objeto por cada vez que lo
Speaker A
necesites no es el mismo En cambio singleton es el mismo objeto y Aquí vamos a ponerle build service Provider para crear todo esto yo con container ya puedo crear objetos vamos a crear un be manager de la siguiente manera be
Speaker A
manager eh get service y pongo la clase que necesito en este caso be manager y que es la del negocio Vamos a ponerle aquí agregarle una cervezas vamos a agregar dos cervezas y vamos a ponerle que nos regrese las cervezas Aquí vamos
Speaker A
a imprimirlas no esto funciona esto ya está funcionando no he programado yo dónde se va a guardar esto pero esto ya funciona Porque estamos dependiendo de implementaciones es decir estamos dependiendo de un componente que no está no existe el componente todavía es decir
Speaker A
ese componente a lo mejor están trabajándolo en en Noruega no sé dónde pero ese ese componente pues está trabajándose pero mí para mí es irrelevante yo ya sé que necesito esos dos métodos y esos dos métodos si te
Speaker A
fijas aquí estamos las cervez son algo yo ya puedo estar trabajando con el negocio a pesar que tenga pues una clase ahí dumi que no est que simplemente esté trabajándose no est no esté implementando realmente código real pero
Speaker A
yo ya estoy haciendo el trabajo real que es el negocio recordemos en las aplicaciones el negocio es el que te va a generar dinero lo demás son simplemente cosas de la base de datos el framework tú lo que vas a utilizar para
Speaker A
para hacer operaciones Matemáticas bibliotecas etcétera todo eso es externo lo interesante es tu modelo de negocio qu es lo que hace tu tu sistema Por cuál es lo que te van a pagar y es donde tienes que estar trabajando No te tiene
Speaker A
que impedir que no está hecho todavía la parte de base de datos Bueno no te tiene que impedir Qué pasa cuando ya tienes que agregar el componente puede ser una biblioteca externa pero aquí vamos a simularlo como si fuera estas llaves
Speaker A
estas Este comentario va a simular como si fuera una biblioteca externa la cual se puede compilar desplegar desarrollar independientemente de este código pero aquí lo voy a poner para que quede todo junto Yo podría crear un proyecto de
Speaker A
biblioteca de clases Lo agrego aquí y sería lo mismo pero aquí no no seráa lo mismo ya en la práctica pero será lo mismo para la explicación yo aquí puedo tener una clase que implemente y repository pero ya sea algo real por
Speaker A
ejemplo Tenemos aquí b repository y b repository lo que hace tener una lista en memoria aquí agregamos a la lista aquí creamos la lista agregamos los elementos y retornamos con un aggregate es muy parecido es parecido al redus en
Speaker A
sí es su equivalente al redus de javascript lo que hace es hacer un recorrido por todos los elementos y hacer algo con esos elementos en cada interacción y retarte un valor escalar que en este caso es un String estamos
Speaker A
concatenando los valores de todas la cerveza separadas por coma bien entonces ya tenemos la implementación Ahora sí algo Real de lo que es el repository Qué pasa si llega al equipo que está trabajando con este componente y te dice
Speaker A
ya acabamos y tú dices Ah pero me acuerdo que respetémonos voy aquí le digo vamos a utilizar agrego la biblioteca la agregamos tan tan le decimos vamos a utilizar B repository yo no modifiqué el negocio yo no modifiqué
Speaker A
esta clase esta no la ha modificado nada yo simplemente fui a donde se hace la inyección de dependencia puse la implementación que es la real estuve trabajando con otra implementación que no era real y simplemente compilo y esto
Speaker A
Pues bueno va a trabajar ahora con una implementación real sin que moviera el negocio ahí vemos la cerveza son Corona eringer solamente esta comita x eh pero vemos que ahí está la implementación real esta comita I al final pero yo no
Speaker A
moví el negocio por eso es parte de la arquitectura es trabajar con componentes para que tú puedas trabajar con una forma como si quitaras piezas de Lego pusieras otra pieza de Lego y no te altera la pieza principal que es el
Speaker A
negocio es decir yo en un futuro A lo mejor esta pieza eh hago otro componente en el cual no trabaje en memoria trabaje A lo mejor con archivos y simplemente voy a hacer Voy a simularlo es se llama
Speaker A
bir dos y Simplemente ya estamos trabajando nosotros ya con todo con todo lo que es el negocio se va incrementando escalando el negocio y simplemente Aquí hacemos bir do la interfaz nunca cambió es muy raro que cambien las interfaces
Speaker A
cuando ya tienes tu tus reglas de negocio son muy o cuando ya tienes definido tu diseño de software es muy raro que cambien podrían cambiar Claro pero bueno Tú ya sabes que esto pues no no cambió simplemente implementa la
Speaker A
funcionalidad distinta aquí aquí le vamos a poner la coma para que esté al final no aquí Aquí vamos a ponerla Así vamos a ponerla al final y yo llego aquí un día y digo ya tenemos nuestro nuevo componente que guarda una base de datos
Speaker A
o guarda un servicio vamos aquí a la inyección de dependencia lo ponemos y ya está no tenemos que cambiar nada de lo demás es por eso la importancia de la arquitectura de software es por eso la importancia de los componentes y podemos
Speaker A
observar que la comita Ahora sí salió bien no Bueno Este es un ejemplo Espero que quede claro ya con el código Cómo se utilizan los componentes obviamente esto tú lo puedes Separar en bibliotecas de clases para que se compile
Speaker A
independientemente y no te y no estén dentro del mismo código que eso lo realista solamente aquí por la explicación lo puse Aquí con separado de de de comentarios por los puristas que vengan a decirme Ay eso lo hubieras
Speaker A
puesto en me vale más y qué aprendiste algo si aprendiste algo decímelo en la caja de comentarios todos tus comentarios los voy a leer y también un pulgar arriba me ayuda bastante vamos a hacer más videos de arquitectura de
Speaker A
software en este canal sobre todo en esta misma temática de explicar la teoría explicar la práctica porque creo que es la manera más adecuada para que las personas se adentren a arquitectura de software sin tener miedo ya saben mi
Speaker A
nombre es sector de León [Música] adiós i
Topics:componentesarquitectura de softwareprogramacióninterfacesacoplamientoprincipio SOLIDinyección de dependenciasrepositorybusinessdesarrollo de software
