Herencia y Composición en Patrones de Diseño
Contenido del curso
El software y la ingeniería
Diseño de software
Patrones de diseño
POO
Conclusiones finales
Herencia y Composición en Patrones de Diseño
Herencia y Composición en Patrones de Diseño
Contenido del curso
Rodrigo Spillere
Alvaro Eduardo Garzón Pira
Josshua Fletes
Alejandro Campuzano
Daniel Basulto
ProfesorAlejandro Campuzano
Leiber Bertel
Alejandro Zapata
Reinaldo Mendoza
Daniel Basulto
Profesor
Victor Hugo Vázquez Gómez
Daniel Basulto
Profesor
John Mejia
Daniel Basulto
ProfesorJohn Mejia
Fabiola Aracely Ramos Sandoval
Karen Heredia
Daniel Basulto
Profesor
Jorge Arias Argüelles
Cristian Javier Arenas Cogollo
Agustina Corvo
Daniel Basulto
ProfesorHerencia y composición
Composición sobre herencia.
Usar menos herencias para no crear taxonomías complejas.
Herencia:
Composición:
Es una relación entre 2 clases dónde una necesita de otra para funcionar.
“Carro” necesita “Motor” para
funcionar
En vez de heredar de una clase base que tenga el motor, podemos tener este elemento como parte de las propiedades de una clase. Así como tenemos motor, podemos tener llantas y asientos.
Hay un concepto muy parecido a la composición que es la agregación, el cual se abordará más adelante.
Aporte de Josshua Fletes
¡Hola!
Te dejo un ejemplo para que quede un poco más claro el concepto de composición de clases en TypeScript:
interface UserSettingsProps { workingDirectory: string; lastOpenFolder: Date; email: string; role: string; lastAccess: Date; name: string; gender: Gender; birthdate: Date; } /* Esta va a ser una composición, una clase que compone otras clases */ class UserSettings { public person: Person; public user: User; public settings: Settings; constructor({ name, gender, birthdate, email, role, lastAccess, workingDirectory, lastOpenFolder, }: UserSettingsProps) { this.person = new Person({ name, gender, birthdate }); this.user = new User({ email, role, lastAccess }); this.settings = new Settings({ workingDirectory, lastOpenFolder }); } }
Y recuerda: "favorecer la composición sobre la herencia".
Herencia y composición
Herencia:
Composición: Es una relación entre 2 clases dónde una necesita de otra para funcionar.
Justo me habia preguntado si era posible "remover" un parametro de la interface (typescript).
Veo que es posible con Omit, pero podemos decir que esto es una mala practica?
El uso de los utility types en TS es altamente recomendado, te dan limpieza, agregan legibilidad, practicidad y lo mejor de todo resuabilidad (tambien extensibilidad, pero me parece más claro lo primero)
grax Daniel!
En la programación orientada a objetos (POO), tanto la composición como la agregación son formas de asociación que describen relaciones entre clases. Sin embargo, tienen diferencias importantes en cuanto a la vida útil de los objetos involucrados:
Agregación: Es una relación "tiene-un" donde los componentes pueden existir independientemente. Por ejemplo, un equipo de fútbol tiene jugadores; si se disuelve el equipo, los jugadores siguen existiendo.
Composición: Es una relación "tiene-un" donde los componentes no pueden existir sin el conjunto. Por ejemplo, un libro tiene páginas; si se destruye el libro, las páginas también dejan de existir.
Mejor la composición ya que a futuro es mas fácil de mantener
Será una decisión de lo que es mejor o de lo que en ese momento nos ayuda a resolverlo de la forma que mejor modela la situación?
Actualmente ya uso composicion para mis componentes en React y es muy util. Hay que ver como se comporta en escenarios como una API con sus servicios que manejen Clases/Modelos/Tablas
La composición en la creación de componentes es de mis cosas favoritas!
Si entiendo bien, "composición" puede inferirse como el uso de un objeto o clase(s) para definir propiedades de otra clase. Esto no iría en contra de los principios SOLID tan recomendados para el manejo de clases?
Los principios SOLID son una guia que tiene su origen en la POO, la composición proviene del algebra y habla sobre la relacion que existe entre la aplicacion sucesiva de funciones matematicas, el famoso gof y fog (https://es.wikipedia.org/wiki/Funci%C3%B3n_compuesta).
La forma que me parece mas adecuada de definir la composicion en terminos de la programacion no es desde la optica de definir propiedades, sino de entender como las estructuras grandes estan compuestas de las mas chicas, ej. Un carro esta compuesto de un motor, el carro tiene su comportamiento unico, así como el motor, sin embargo existe una relacion entre estos, el carro esta compuesto del motor y no puede funcionar sin el.
Visto así, que principio SOLID, consideras John que no se esta cumpliendo, sabiendo que estos se enfocan mas en la implementacion de la solucion y no en la definicion de las reglas de relacion entre los entes abstractos (el carro y el motor)?
Gracias por la respuesta. Supongo que lo veo más desde la implementación como tal. Para el ejemplo, visualizaba la implementación de carro algo así como:
class carro { public motor : claseMotor; public function __construct() { $this->motor = new claseMotor(); ... } ... }
Y es en esa creación de motor donde me queda el conflicto de si tal aproximación cumple con los principios de independencia. Más adelante en el curso vi que los patrones Factory hacen precisamente algo similar, crear directamente el objeto "propiedad" (motor) dentro de la sueprclase (carro). Pero entonces, si es correcto este tipo de implementación?
¿Cuándo debería usar herencia en mi código?
Debes usar la herencia exclusivamente cuando exista una relación estricta de "es un" (por ejemplo, un Perro es un Animal). Es la herramienta perfecta cuando necesitas aplicar polimorfismo, es decir, cuando quieres que diferentes objetos respondan al mismo método de forma distinta, pero compartiendo una base lógica idéntica.
Si solo quieres reutilizar un fragmento de código o una función específica, la herencia es el camino equivocado. Utilízala cuando estés absolutamente seguro de que la subclase necesitará exponer toda la interfaz pública de la superclase y cuando el dominio del problema dicte que el comportamiento base no cambiará drásticamente en el futuro. Es un contrato fuerte, así que úsalo solo cuando la relación sea inquebrantable.
Con el ejemplo que dio sobre motor, y el carro, si bien hace referencia a conceptos parecidos con extensibilidad, no podria referirse tambien a la abstraccion?
Totalmente Karen, la abstraccion es el proceso que nos hara entender el problema, hallar los elementos de nuestro negocio que seran traducidos a una solucion a nivel tecnologico (codigo, servicios en la nube, etc).
Herencia:
Composición:
Recomendación: Usar la herencia con precaución y considerar la composición para evitar complejidades innecesarias.
Se menciona la composición, pero, ¿y donde queda el concepto de agregación? pues la composición y la agregación son dos cosas que me llegan a confundir al intentar identificar cuando están presentes estas relaciones entre clases y sobretodo al modelarla en UML.
¿Alguno me podría explicar?
La composición es un tipo de relación fuerte, como el ejemplo que se muestra en la clase. En cambio la agregación es un tipo de relación débil. Una pregunta que nos podemos hacer para decidir en un esquema de UML si la relación entre clases es de composición o agregación, es: si se elimina un objeto de esa clase, el objeto relacionado sigue existiendo? En caso de que sea así la relación es débil, y hablamos de una agregación. En caso contrario es una composición.
Muchas gracias Agustina por la explicacion!
Me permito agregar lo siguiente: Tienes un carro, en la linea de producion se le AGREGAN llantas, motor, cableria, todos estos ya creados previamente.
En codigo: Al crear un objeto de la clase carro, le paso al metodo constructor los objetos ya creados de las clases motor y ruedas.
Otro caso seria que dentro de la linea de produccion del carro tambien se creara el motor, en este caso la linea del carro, ademas de crear el motor, tambien se encarga del motor.
En código: Creo un objeto de la clase carro y dentro del metodo constructor, creo un objeto de la clase motor. Ya no se lo paso como parametro, sino que lo creo internamente.
Ambos tienen utilidad, ambos dependeran de lo que desees modelar del mundo real