Aplicando Herencia a nuestro proyecto Uber

Clase 16 de 37 • Curso de Programación Orientada a Objetos: POO

Maria Gabriela Rangel

student•

Una pregunta y no se deberia crear otra dos clase una que CarBasic y tenga los atributos de brand y model, y otra que sea CarAdvanced que tenga typeCarAceppeted y seatsMaterail, estas dos clases heredarian de Car y las clases Uber* heredarian de CarBasic y CarAdvanced

Ann Code

teacher•

Efectivamente Mary, podemos abstraer esto todavía y generar estas dos clases hijas. Esto significa agregar una capa más al diagrama.
Bien hecho!

Álvaro Soria

student•

Al agregar la capa de CarBAsic y CarAdvanced en el diagrama, estos quedarían como las ultimas clases de las que se crearan los objetos UberX, UberPool y UberBlack, UberVan respectivamente ¿Verdad!?? o estoy equivocado?

Francisco Javier Suarez Verdugo

student•

Estupenda clase instructora Anahí, por medio de estos diagramas se puede apreciar los atributos que compartirán las superclases con las subclases y, además servirán como base para la documentación de la aplicación que estemos creando. Acá realice unos con Draw.io, los compartirlo por si le es útil a alguno de los compañeros

Clase Account
Clase Payments
Clase Car
Diagrama Uber

Wilson Alexander Caal Pacay

student•

Donde puedo aprender mas sobre los diagramas, mas sobre la diagrama numero 4 que hiciste "4 Diagrama Uber"

Francisco Javier Suarez Verdugo

student•

Buenas, en cuanto a los diagramas yo me guié de los ejemplos que nos planteó la instructora Anahí. Si quieres aprender un poco más sobre las técnicas de UML, te recomiendo el libro UML y Patrones de Craig Larman, acá te dejo un enlace: https://amzn.to/2OrDgsH

Marcos Sebastián Imfeld

student•

![](

Ann Code

teacher•

Excelente aporte Marcos!
Me encanta tu iniciativa de por hacer este diagrama.

Moisés Manuel Morín Hevia

student•

Buen diagrama!

Carlos Eduardo Gomez García

teacher•

Me gusta como queda al final el diagrama, algo importante a resaltar es la parte de pagos, aunque las clases no comparten atributos, por buena práctica, es bueno que hereden de una clase Payments, porque sabemos que implicitamente esas 3 son pagos, ¿Pasa algo malo si no hacemos esto? No, pero a futuro podremos querer implementar algo que sea común entre esos 3 tipos de pagos, y lo mejor es hacerlo sobre una clase Payment ^^

Jossie Steeven Quintero Giron

student•

Entendido!

Sebastián Arredondo Posada

student•

Thanks for your explanation. Good point.

Juan Camilo Lezcano Benitez

student•

Para los que no han hecho el curso de bases de datos, con esta herramienta se pueden crear este tipo de diagramas.
https://www.draw.io/

Gianluca Reyes Cisneros

student•

EXCELENTE GRACIAS POR TU APORTE

Oscar Mauricio Acevedo Porras

student•

Es más cómodo trabajar con Genmymodel

Aldo Sandoval

student•

Hice un diagrama UML integrando las propiedades de cada clase, si identifican un error por favor comenta. Les dejo el template y el sitio donde pueden crear el suyo y añadir nuevas clases, propiedades y comportamientos. -Template -Sitio para editar template (select open existing diagram)

Manuel Alejandro Aguilar Téllez Girón

student•

A mi parecer está bien el diagrama, no cambiaría nada, quizás agregar alguna propiedad para que driver y user no sean tan iguales pero es puro capricho. 😂

Pablo Coronel

student•

me parece correcto que hayas agregado el atributo 'cost' a 'Payment'

Andres Antonio Santisteban Lino

student•

Hola aquí os comparto mis apuntes

Edgard Ernesto Ortiz Ortiz

student•

Gracias Bro

Carlos Ivan Garcia Fougerat

student•

Muchas gracias!!

Lizie Consuelo Perez Torres

student•

Hacer una clase por cada tipo de vehículo me parece poco eficiente porque tendría que crear una nueva clase si es que se agregara un nuevo tipo de carro. No seria mejor crea una clase llamada typeCar y relacionarla a la clase car?

Ronald Cuello

student•

estoy totalmente de acuerdo, yo le colocaria type servicio

Julio Cesar de la Lima López

student•

También estoy de acuerdo pero asumo que el objetivo ahora es entender los conceptos. Es igual cuando uno normaliza, en algún punto se tiene que analizar la eficiencia y ejecutar la denormalización.

Silvana Rolón

student•

Jhoan Sebastián Lopera Gallego

student•

Tremendo!

Juan Cruz Rivera

student•

Por si la duda, en Trip hay composición, de ahí los rombos oscuros, que quiere decir que tiene una relación compenetrada, que dependen y que una de estas clases no podría vivir sin la otra. Car, route y Payment depende de trip, y trip depende de ellos.

Referencia: https://platzi.com/clases/1474-oop/17219-uml/

Kevin Andres Rosales Marquez

student•

Hola, en el caso de Uber X y Uber Pool se puede crear otra clase padre en donde este la marca y modelo de los carro?

Erik Elyager

student•

No veo porqué no, siempre puedes expander tu jerarquía de clases.

Gerald Zamora

student•

Esta es mi version

con este archivo lo pueden modificar es un archivo .drawio en esta pagina se modifica; o pueden hacer el suyo

Mario Emiliano Gordon Pico

student•

Gracias por la sugerencia de aplicacion para crear el diagrama esta super bueno!

Xavier Sebastian Vaca Ordoñez

student•

Te recomendaria escribir la relacion que existe entre Driver y Car. como por ejemplo. Un driver have car. No se si escribir la relacion rompe con el estandar establecido por UML. Tambien agragale la cardinalidad como por ejemplo un Driver puede tener muchos carros o un usuario realiza 0 a muchos viajes

Usuario anónimo

user•

🤔 La abstracción es esencial para aplicar de forma correcta la herencia.

Jesús Enrique García

student•

Esta muy bien estructurado solo podría agregar que en el caso de la clase account falto el atributo typeaccount porque hace falta un atributo que pueda diferenciar una cuenta de otra, por otro lado en la clase payments faltaría la clase paymethod ya que se necesitaría especificar en la factura el método de pago para vincularlo a la transacción, si no es imposible tener una relación.

Vanesa Percy

student•

Buenas observaciones compañero.

Jhoan Sebastián Lopera Gallego

student•

Completamente de acuerdo

Rigoberto Maldonado

student•

Muy resumido.. Increible

JOHN HEDER GIRALDO GIRALDO

student•

Muy buena Clase!!!

El rombo negro implica una Composición (Relación totalmente compenetrada. Una no puede vivir sin la otra.)

Wilfrido Muratalla

student•

Moisés Manuel Morín Hevia

student•

Buen diagrama de la herencia !

Manuel Peñaloza

student•

perfecto

Emel GM

student•

En en editor de código VSC se puede instalar una extensión que permite realizar los diagramas.

Instalar extensión Drawio Integration.

La extensión de este archivo se guarda con ".dio" para el entorno gráfico.

Wilson Marino Pablo Mendez

student•

Una herramienta para hacer diagramas UML "StarUML"

Mateo Cano Ceballos

student•

¿ Por qué no quitar 'id' de card, payPal y Cash?

Oscar Eduardo Palomino Cárdenas

student•

Porque son subclases y deben de ser identificadas. No importa si es una Súperclase o una Subclase,todo debe ser identificado con un id, no solo por buena práctica sino también en caso de manejar una base de datos.

Cristian Jose

student•

Lo que dice oscar es falso , debió borrarlo ya las clases card, paypal y cash contrendran el atributo Id desde su clase padre, Si usted vuelve a declarar id desde cada una de las clases hijo lo que esta haciendo es ocultar el miembro heredado de la clase padre.