Aplicando Herencia a nuestro proyecto Uber

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

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

1. Clase Account
   
   
2. Clase Payments
   
   
3. Clase Car
   
   
4. Diagrama Uber
   
   

![](

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 ^^

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/

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)

Hola aquí os comparto mis apuntes

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?

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/

Esta es mi version

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

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

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.

Muy resumido… Increible

.

Muy buena Clase!!!

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

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.

Una herramienta para hacer diagramas UML "StarUML"

Por fn entendí Herencia!

Recuerden que en la sección de archivos y enlaces encontraran las imagenes adjuntas de esta clase 😉
Si quieren hacer un diagrama propio, puede ayudarse con Lucidchart

Hice el UML por si alguien quiere ver como se ve todo en conjunto,

La herramienta que ocupe es: https://app.diagrams.net/

Programa Usado: Star UML

Mis modelos hechos en Draw

Información resumida de esta clase
#EstudiantesDePlatzi

• Importante realizar el diagrama UML de manera visual y organizada

• Revisamos que atributos en común tenemos dentro de las clases para tener herencia

• Con esto logramos crear una superclase y los atributos de las subclases se borran y se unen con la flecha de asociación en sentido de hijo a padre

• Podemos observar si algunas clases comparten entre sí cierta característica dentro del modelo de negocio y crear una superclase, así no tengan atributos en común

• Esta herencia es por lógica del negocio

• Importante entender el modelo de negocio

Sería perfecto que Platzi implementara uno o varios cursos para realizar Diagramas UML ya que por supuesto este tema es muy clave. Buen curso este…

hacer todo esto se parece a normalizar una base de datos.

Odiaba la poo que casi la reprobaba, y este curso me esta haciendo amarla.

Acá les dejo este link para realizar sus diagramas UML de forma gratuita.
https://app.diagrams.net/

Tal vez sea mas practico que tanto **User **como Driver, sean solamente User. Y podríamos tener un **UserType **para indicar si el usuario es **Driver **o no.

Excelente manera de entender la herencia, si quieren hacer los diagramas UML hay una página que se llama lucidchart es bastante buena.

mi diagrama pretende tener en cuenta los minimos casos en que el cliente no paga por lo que sea.

imagen

@startuml
!theme sketchy
class Account  {
  {field} id 
  {field} name
  {field} document
  {field} email
  {field} password
  {method} Some method
}

class User extends Account {}
class Driver extends Account {}

class Trip {
   {field} user
   {field} route
   {field} car
   {field} payment
}

Trip::user --> User

class Payment {
   {field} id
}

class Card extends Payment{
  {field} number
  {field} cvv
  {field} date
}
class Paypal extends Payment{
  {field} email
}
class Cash extends Payment{}

class Car {
  {field} id
  {field} license
  {field} driver
  {field} passenger
}

Car::driver --> Driver

class UberX extends Car {
  {field} brand
  {field} model
}
class UberPool extends Car {
  {field} brand
  {field} model
}
class UberBlack extends Car {
  {field} typeCardAccepted
  {field} seatMaterial
}
class UberVan extends Car {
  {field} typeCardAccepted
  {field} seatMaterial
}



class Route {}
Route --* Trip::route
Payment --* Trip::payment
Car --* Trip::car
@enduml

Una duda: ¿no debería quitarse el atributo id de las clases hijas de la clase Payments?

muy buena la explicación, aplicare este paso a paso para mi trabajo de la Uni sobre Diagramas UML

Mi aporte haciendo el diagrama:

Mi diagrama quedó asi:
![](

Extension de VSC para crear UML:

• UMLet
  Solo debes crear un archivo con el siguiente nombre y extension:
  "-filename=someinputfile.uxf"

Ej:

-uber=someinputfile.uxf

Mis apuntes #16

Así me quedo el mapa en UML, está bien chido el software que uso XD se llama StarUML

Este es el diagrama que hice, Perdón si las flechas no se entienden, Aún no logro diagramar bien en UML 😕 , ¿Alguna Opinión?

Comparto mi diagrama de clases:

También podemos crear una clase payments con dos atributos id y forma de pago (aqui escogemos si es por TDC, Paypal y/o efectivo)

Este es mi resumen del ejemplo del curso hasta este punto, tal vez le puede ser útil a alguien mas. Si observan algún error o tienen alguna sugerencia por favor brindar la info 😉
Resume ejemplo UBER

Las herencias, para la normalización de una base de datos.

aplicando herencia a el modelo uber

tambien se podria generar una subclase con los vehiculos uber black y uber van

como sugerencia, veo que en la clase Payments es conveniente agregar también un atributo para definir el valor del pago realizado o de la transacción

Les comparto mi diagrama UML de Uber

Mi diagrama UML
![](

Si estas clases quedan vacias: User y Driver no es mejor dejar como general la de Account.
O en todo caso, se les añade el tipo de usuario especifico:

Tengo una pregunta…
Cuando se hace herencia las clases hijas pueden ser igual a otra hija? lo digo por el caso de conductor y usuario, ya que creia que no pueden ser iguales, siempre debe haber alguno más que otro.
Gracias

No encuentro en esta clase la sección enlaces para buscar el diagrama, alguien sabe donde está?

14. Mis apuntes sobre: “Aplicando Herencia a nuestro proyecto Uber”

Les comparto cómo me quedó el diagrama por el momento:

Y si analizaramos whats app, como quedaría ?.

clases :

• User
• Chats
• Estados
  -Contactos
  -Llamadas

Y así es como algo que parecía muy complejo se vuelve súper entendible!

Hola chicos!!, mi pregunta es:
De acuerdo a lo ya visto hasta esta aplicacion, creen que sea bueno identitificar los atributos de cada objeto para posteriormente comenzar a pensar en una supeclase?

ESTO ES UNA SUPER CLASE!!! ANNCODE

La fiesta viene ahora al programar xD

Es importante destacar que las clases siempre se nombran en singular 😃.

Una pregunta. A pesar de que los tipos de auto heredan varios atributos de la superclase CAR, todavía hay redundancia entre las clases. Tanto UberX y UberPool, así como UberBlack y UberVan comparten los mismos atributos. ¿Esto es así? ¿Debería pensarse en una especie de clase intermedia? ¿o cómo se resuelve este problema de redundancia en POO?

Check a herencia.

Para la parte de la herencia, siempre es bueno que alcancemos un maximo numero de comportamientos dentro de una clase, o se prodrian hacer hasta con dos si uno quiciera?

Podría ser que la clase UberX y UberPool, se unieran en una clase llamada UberBasic y agregar una propiedad llamada type.
Ustedes que opinan?

Me encantó este curso. Es tan sencillo entender como relizar un UML, al igual que todos los conceptos.
Y además, una excelente profesora.

Esto se va poniendo mas interesante…

En mi opinión, la clase payment debería tener un atributo “fee” o “ammount” que es común para todos los métodos de pago. Esto porque, independientemente del método, el valor a pagar es el mismo.

Creo que en si, la clase de pagos, si pueden tener algo en común: el costo del viaje

Las clases deberían estar definidas en singular. Por ejemplo Payments debería ser Payment aunque yo hubiera elegido PaymentMethod.

Account

Payment

Car

Tengo en cuenta dos cosas el DRY y que no necesariamente tiene que heredar todos los atributos del Padre.

UberBlock-Herencia

muchas gracias

Podemos aplicar el concepto de herencia a nuestro proyecto Uber para mejorar la estructura de nuestras clases y reducir la redundancia de código. Aquí hay algunos ejemplos de cómo podríamos usar la herencia en nuestro proyecto:

• Podemos tener una clase User como nuestra superclase y luego crear subclases como Driver y Passenger que hereden los atributos y métodos de la clase User.
• Podemos tener una clase Car como nuestra superclase y luego crear subclases como UberX, UberPool, UberBlack y UberVan que hereden los atributos y métodos de la clase Car.
• Podemos tener una clase Route como nuestra superclase y luego crear subclases como UberXRoute, UberPoolRoute, UberBlackRoute y UberVanRoute que hereden los atributos y métodos de la clase Route.

El uso de la herencia en nuestro proyecto Uber puede ayudarnos a tener una estructura de código más clara y fácil de entender, además de ayudarnos a evitar la redundancia de código.

Excelente clase =)

Pienso que el curso podría ser mas eficiente si se utiliza directamente UML.

Herencia por lógica de negocios

Mi aporte 😄 :

Hey, aquí hice el diagrama UML, espero que lo vean para ver si tienen algo que corregirme! 😄 , con todo les dejo una imagen en donde no se aprecia completamente!

Estoy haciendo un curso en simultaneo de POO con Java, y vine a complementar con este curso, y terminar de entender lo que aún no entendía, y la verdad Anahí explica muy bien y es completo lo que el curso brinda

RESUMEN CLASE 16:
APLICANDO HERENCIA A
NUESTRO PROYECTO UBER

DIAGRAMA DE UBER

Me ha encantado como esta quedando

![](

Yo lo hice con los aportes de una compañera en la comunidad:

Hola compañeros,
También agregué otra herencia a la clase de vehicluos, una de **EconomicVehicles **y otra de PremiumVehicles.
cualquier aporte u observación es bien recibida!
![](

La herencia es un pilar importante de OOP (Programación Orientada a Objetos). Es el mecanismo en Java por el cual una clase permite heredar las características (atributos y métodos) de otra clase. Aprenda más a continuación.

En el lenguaje de Java, una clase que se hereda se denomina superclase. La clase que hereda se llama subclase. Por lo tanto, una subclase es una versión especializada de una superclase. Hereda todas las variables y métodos definidos por la superclase y agrega sus propios elementos únicos.

Terminología importante

Superclase: la clase cuyas características se heredan se conoce como superclase (o una clase base o una clase principal).
Subclase: la clase que hereda la otra clase se conoce como subclase (o una clase derivada, clase extendida o clase hija). La subclase puede agregar sus propios campos y métodos además de los campos y métodos de la superclase.
Reutilización: la herencia respalda el concepto de «reutilización», es decir, cuando queremos crear una clase nueva y ya hay una clase que incluye parte del código que queremos, podemos derivar nuestra nueva clase de la clase existente. Al hacer esto, estamos reutilizando los campos/atributos y métodos de la clase existente.

Además de Drawio que varias personas han recomendado, yo quiero recomendarles también StarUML.

sin embargo recomiendo usar mas drawio porque puedes hacer cualqueir tipo de grafico y para empezar con el tema de bases de datos relacionales es magnifico

Encontré un detalle con respecto al análisis de los ubers para transformar a la superclase car: existe la posibilidad de armar una superclase secundaria de una subclase? a lo que me refiero es que entre uberx y uberpool tienen atributos sobrantes como brand y model, que se sacaría otra clase padre para ellos 2; mientras que en uberblack y ubervan derivan otra clase padre donde comparten los atributos typeCarAccepted y seatMaterial;

Herencia múltiple
• Si una clase se puede refinar en varias dimensiones distintas e independientes, se usan las generalizaciones múltiples.
– Las subclases de la generalización pueden ser o no disjuntas.
– Una clase puede heredar de forma múltiple desde distintas generalizaciones o desde distintas clases dentro de una relación de generalización solapada, pero nunca desde dos clases en la misma generalización disjunta.
– El término herencia múltiple se puede referir tanto a la relación conceptual entre clases (generalización) como al mecanismo del lenguaje que implementa esa relación (herencia).

La herencia no es mala, solo hay que saber cuando usarla y sin abusar de ella ya que estas creando un nivel de dependencia en tu proyecto fuerte, y a la larga puede ser dificil de actualizar o administrar, cuando tengas duda de si usarla o no en su defecto usa composicion. en fin, es el tema durante años. Herencia vs Composición!

#FREEFREDDY

Al analizar las clases, vi que los atributos brand, model, typeCarAccepted y seatsMaterial se repetian, por lo que decidí separarlos por interfaces; por lo de Interface Segregation, ya que las clases UberBlack o UberVan pueden implementar ambas interfaces en un futuro, al contrario de que si fueran clases abstractas:

Además de Draw.io que varias personas han recomendado, yo quiero recomendarles también StarUML.