Relaciones entre clases
UML (Unified Model Language): Es mostrar visualmente el comportamiento y la estructura de un sistema, normalmente, a través de diagramas
-Relación de dependencia: Se da cuándo al realizar cambios en una clase se modifica otra
Relación de asociación: Se da cuándo una clase tiene acceso permanente a otra clase
Relación de implementación: Se da cuándo una clase define su comportamiento basado en cierto método
Relación de herencia: Similar a la anterior, pero puede extender su comportamiento
Relación de agregación: Se da cuándo una clase necesita de otras clases, pero no interfiere en su creación o eliminación. Simplemente las añade mientras sean útiles
Relación de composición: Se da cuándo una clase necesita de otras clases, pero interfiere en su creación y eliminación. Así mismo si el elemento mayor desaparece, las demás clases dejan de ser útiles
este es un codigo implementando todas las relaciones.
Genial Gustavo, lograste condensar de forma muy buena las relaciones, te felicito.
Una observación con miras a usar los recursos de una forma mas eficiente, las interfaces son útiles para implementar comportamiento, las veces que he tenido que usar propiedades definidas en una entidad en común he heredado de una clase que tenga la prop y voy cambiando su valor en la clase derivada.
Excelente explicación de las relaciones de Agregación y Composición. Nunca había visto un ejemplo tan claro.
Me alegra a mares que te haya parecido claro Jaime, gracias!
¡Hola! ¿Qué tal un curso dedicado solo para UML?
Gracias por el comentario Alvaro, hemos tomado nota de esto :)
Ese curso lo vengo pidiendo desde hace tiempo y nunca llega, aunque parece ser una herramienta vital también parece que es poco usado hoy en día.
Gracias por esta explicación, lo hiciste ver de manera muy sencilla y fácil de entender. Excelente maestro :-)
Gran noticia el saber esto, gracias Martha!
La mejor clase del curso
Es mi clase favorita de hecho, gracias Angello!
En la programación orientada a objetos (POO), existen diferentes tipos de relaciones que pueden establecerse entre clases para modelar las interacciones y dependencias entre ellas. Algunos de los tipos de relaciones más comunes son los siguientes: . Asociación: La asociación es una relación básica y general entre dos clases. En esta relación, una clase hace referencia a otra clase como un miembro o atributo. Puede ser una relación unidireccional o bidireccional. Por ejemplo, en un sistema de gestión de una escuela, la clase "Estudiante" puede tener una asociación con la clase "Curso", ya que cada estudiante está asociado con uno o más cursos. . Agregación: La agregación es una relación de todo a parte, donde una clase contiene una referencia a otra clase, pero la otra clase puede existir de manera independiente. En otras palabras, la clase "contenedora" tiene una asociación con la clase "contenido", pero el contenido puede existir sin el contenedor. Por ejemplo, en un sistema de gestión de una biblioteca, la clase "Biblioteca" puede tener una agregación con la clase "Libro", ya que los libros pueden existir por separado y también pueden ser parte de la biblioteca. . Composición: La composición es una relación más fuerte de todo a parte que la agregación. En esta relación, una clase contiene a otra clase y la parte no puede existir sin el todo. Es una relación de dependencia fuerte. Por ejemplo, en un sistema de una computadora, la clase "Computadora" puede tener una composición con la clase "Procesador", ya que un procesador es una parte esencial de una computadora y no puede existir sin ella. . Herencia: La herencia es una relación jerárquica entre clases, donde una clase llamada "clase derivada" hereda los atributos y métodos de otra clase llamada "clase base" o "superclase". La clase derivada puede agregar nuevos atributos y comportamientos específicos, además de heredar los de la clase base. Esto permite la reutilización de código y la creación de jerarquías de clases. Por ejemplo, en un sistema de gestión de una tienda, puede haber una clase base "Producto" y clases derivadas como "Ropa", "Electrónica" o "Alimentos". . Dependencia: La dependencia es una relación en la que una clase requiere o depende de otra clase en algún punto. Por ejemplo, si una clase A utiliza un objeto de una clase B como parámetro en un método, hay una dependencia entre ambas clases. La clase A depende de la clase B para realizar una determinada operación.
uno de los mejores cursos de la plataforma amigos... Pude reforzar y aprender mediante ejemplos claros los conceptos bases de POO
La diferencia entre extends e implements en programación orientada a objetos es fundamental:
extends: Se utiliza para heredar de una clase base. La clase hija hereda métodos y propiedades de la clase padre, permitiendo la reutilización de código y la posibilidad de extender su funcionalidad.
implements: Se utiliza para implementar una interfaz. Una clase que implementa una interfaz debe definir todos los métodos especificados en la interfaz, garantizando que la clase cumpla con un contrato específico.
Ambos conceptos son esenciales para la relación entre clases y la organización del código en POO, como se menciona en el contexto de UML y las relaciones entre clases.
Entiendo que extends (herencia) se usa si quieres que todos los hijos copien tanto los atributos como metodos y su real funcionamiento tal cual, y a la vez te permita extenderlo y crear nuevos atributos y metodos puntuales para el hijo.
Por otro lado, el implements se usa para asegurarse de que los hijos cumplan si o si, con cada uno de los metodos que tiene su padre (contrato inquebrantable), sin embargo, este no copia el funcionamiento de los metodos, solo los obliga a que lo tengan y el funcionamiento puede variar o ser el mismo, eso lo decide el hijo. Ejemplo moverse, puede ser volando, puede ser corriendo, caminando, etc.
Desafortunadamente, con la premisa de "esto se necesita para ya" no se me daba mucho tiempo para realizar diagramas UML o documentar las soluciones adecuadamente y después llegaban los reclamos y cargos de conciencia...
Yo vuelvo a lo mismo, yo no recuerdo haber utilizado alguno de estos, aunque si me gustaría repasar un poco sobre la programación orientada a objetos, donde seguramente me va a quedar un poco mas claro este asunto.
No conocía estos conceptos, pero todo me quedó super claro. ¡Gracias!
Me gusto esta ultima clases los junta todo y lo explica con ejemplos practicos.
Tenemos algún curso de estructura de datos en Platzi?
En este curso se ven varias estructuras de datos en Javascript: https://platzi.com/cursos/estructuras-datos/
Aportes: Qué es UML: https://platzi.com/clases/1474-oop/17219-uml/ Libro de UML: https://www.u-cursos.cl/ingenieria/2008/1/CC51H/1/material_docente/bajar?id_material=160144
Excelente aporte. 👏🤝
Está clase es genial. Conceptos de Spring que hace meses estudie me están quedando mucho más claros y entendibles. Muchísimas gracias!
Asociación y agregación me parece que son muy similares pero al leer más a fondo, la agregación parece más como un orquestador de clases dentro de sus métodos; mientras asociación lo integra a sus operaciones internas de la clase.
Aquí me corrijo: orquestar es más un comportamiento y no una estructura. Para que una relación pueda ser de agregación esta debe ser un contenedor (un arreglo)
Hola! Una pregunta: No me quedo full clara la diferencia entre composición y agregación
Entiendo que en composición una clase es creada con base en la otra, mientras que en agregacion una clase crea instancias de la otra. Esto implica que la composición es a nivel clase vs clase mientras que la agregacion es a nivel clase vs instancie?
Creo que la diferencia principal es que agregacion NO crea el objeto (instancia), sino que se le pasa como parametro (esto quiere decir que si destruyes un carro, no se destruye el motor.
Por otro lado, la composicion SI crea el objeto (instancia) al momento de crear el carro, y por tanto, si destruyes el carro, se destruye el motor.
Basicamente agregacion mantiene los objetos de manera independiente y su ciclo de vida es independiente. Si no necesitas unas motor si no tienes carro, pues Composicion; Si necesitas el motor aunque no tengas el carro (para usarlo en otro carro por ejemplo), entonces Agregacion. Puedes imaginar un proceso de creacion de un vehiculo completo, es decir, si decides crear un carro, creas las piezas para ese carro y listo o creas la carroceria y luego alguien te envia las partes para acoplarlo.
Comparto algunos ejemplos como ejercicios que realice:
// dependencia // su uso es momentaneo class Motor { encender() { console.log('Motor encendido') } } class Carro { encenderCarro(motor: Motor) { motor.encender() } } const unMotor = new Motor() const miCarro = new Carro() console.log(miCarro.encenderCarro(unMotor)) // una clase tiene usualmente como atributo a otra clase // es permanente su acceso a la otra clase class Comida { pollo() { console.log('pollo') } } class Plato { comida: Comida constructor(comida: Comida) { this.comida = comida } servir() { this.comida.pollo() } } const comida = new Comida() const plato = new Plato(comida) // implementacion, aqui las clases obedencen a una interfaz interface Animal { patas: number cabeza: number cola: boolean } class Gato implements Animal { patas: number cabeza: number cola: boolean constructor(patas: number, cabeza: number, cola: boolean) { this.patas = patas this.cabeza = cabeza this.cola = cola } } // en la herencia una clase hereda de otra class Mama { ojos: string cejas: string cabello: string constructor() { this.ojos = 'verdes' this.cejas = 'pobladas' this.cabello = 'rizado' } } class Hija extends Mama { nariz: string constructor(ojos: string, cejas: string, cabello: string) { super() this.nariz = 'chata' } } // agregacion, el elemento que llama al elemento padre no depende de este, su ciclo de vida es libre class ComboHamburguesa { hamburguesa: boolean papas: boolean refresco: boolean pure: boolean constructor( hamburguesa: boolean, papas: boolean, refresco: boolean, pure: boolean, ) { this.hamburguesa = hamburguesa this.papas = papas this.refresco = refresco this.pure = pure } } class Orden { orden: Array<any> constructor() { this.orden = [] } pedirOrden(combo: ComboHamburguesa) { this.orden.push(combo) } } const combo = new ComboHamburguesa(true, true, false, true) const orden = new Orden() orden.pedirOrden(combo) // composicion, de la clase padre dependera el ciclo de vida de las hijas, el objeto suele crear instancias dentro de su constructor, relacion ligada, fuerte class Pizza { ingredientes: { queso: string masa: string } constructor() { this.ingredientes = { queso: 'queso', masa: 'masa', } } } class PizzaHawaiana { base: Pizza insumoDistintivo: string constructor() { this.base = new Pizza() this.insumoDistintivo = 'piña' } getPizza() { console.log('La pizza contiene: ', { ...this.base.ingredientes, distintivo: this.insumoDistintivo, }) } }
la de depedencia me recordo igual un poco a la inversion de dependecias en cierto sentido. si teno un martillo y lo paso como objeto,, ahi esoty creando una dependecia directa del objeto en vez de hacer esa dependencia en builder, hago una interfaz tool que es un contrato para martillo , asi en builder le pasare el martillo pero en vez de definir como parametro hammer lo que algo es que el parametro que le pasare seria la interfaz y asi intercambiable con demas herramientas que implementer por decir de la interfaz sin un dependencia directa del objeto.