Principios SOLID con ejemplos en C#! (video completo)

[@HM-if5cu]

Muy bien explicado. Gracias por compartir

[@compartelo007]

La explicación superbien, pero el ver los atributos de las clases comenzando en mayúsculas al igual que las clases me destrozó, me entró el TOC y un para cardiaco. Ya se que en C# es así, pero me duele.

[@NicolasBattaglia]

Jajaj en relidad yo uso los atributos privados en minuscula o con _ adelante, y las properties en mayúscula. Es como una convencion implícita de la comunidad de c# pero seguro si venis de java esto te dará ganas de prender fuego mis videos jajajja. Me hiciste reir!!

[@compartelo007]

@@NicolasBattaglia Si amigo efectivamente, es el cambio de la convención entre la comunidad de C# y Java. Pero leyendo eso en internet y comparando ambas convenciones, mi opinión es que en c# por querer matizar tanto la convención es más rollo que en Java. Que si atributos privados una cosa que si son públicos otra ,etc, etc, Obviamente todo es práctica, pero de entrada me mató. Por su puesto eso no tiene nada que ver con la gran explicación y obviamente con mi like más que merecido

[@NicolasBattaglia]

Lo importante es el fin, no el medio (en este caso!) Me alegro que te sirva el video!! Saludos

[@compartelo007]

@11:46 una pregunta, en el diagrama UML veo que la clase cliente tiene una flecha con rombo relleno lo que indica que es una composición (no agrgación), si no estoy equivocado la composición es una forma fuerte te composición donde la vida de la clase Cliente debe coincidir con la de la clase Factura, pero no veo tan claro que si no hay factura un Cliente deje de ser cliente, deja de ser cliente para esa factura pero en realidad puede ser cliente de otras facturas. no es como por ejemplo una relación entre empleado y empresa donde si la empresa desaparece empleado ya no tiene sentido de ser. Me puedes matizar eso, porque bajo mi humilde opinión la relación debería de ser agregación, una composición más débil y por lo tanto el rombo debería de estar sin rellenar. Gracias por adelantado

[@NicolasBattaglia]

Hola Javier, es tal cual lo que indicas. La relación es agregacion, y no composición. El rombo de composición lo planteo como un rombo relleno color negro y la agregacion como un rombo blanco (sin rellenar) no recuerdo ahora, quizaa deba revisar, si use alguna composición en el video!! Espero ayudarte

[@compartelo007]

@@NicolasBattaglia Agradecido por la pronta respuesta y la sinceridad. Gracias

[@NicolasBattaglia]

@@compartelo007 por nada! hay otro video donde planteo la diferencia entre agregacion y composición y la manera de implementar ambos casos (clases con código). Lo que quiero transmitirte, además de intentar ayudarte, es que en este video de solid la relación del diagrama es agregacion y no composición como lo estas leyendo (en este caso, el.rombo esta sin rellenar). Un abrazo y a tu disposición

[@herik2542]

Gracias por la explicación, ya me quedó más claro.

[@MrChuyelChief]

Yo no se porque este video tiene tan pocas vistas y likes, todo esta muy claro y mas con los ejemplos en el código, te agradezco mucho tu tiempo y la buena explicación que diste. Saludos.

[@jimmy.cumbicos]

Excelente explicación.

[@compartelo007]

@43:30 Una pregunta, no me queda claro que los métodos imprimir que las clases hijas sobrescriben no puedan imprimir más o menos información sin que eso signifique romper el principio de sustitución. O sea, yo pensaba que si por ejemplo el método imprimir de nota de crédito quiere añadir más información que el de factura o nota de débito ya que el hecho de poder sobrescribirlo me daba la libertad de añadir una lógica de impresión diferente. Pero según he creído entender eso rompería el principio de sustitución pero no lo acabo de ver, porque ahora una vez refactorizado yo voy a poder hacer una llamada al método imprimir y pasarle la clase padre y no tiene nada que ver que cada uno de los imprimir de las clases hijas impriman lo que les vengan en gana. Si puede decirme algo al respecto. Gracias

[@NicolasBattaglia]

Hola Javi! Luego del refactoring del minuto 43.30, las clases derivadas no sobrescriben el metodo imprimir. Sino que generan una descripción polimórfica y la clsse padre tiene la operación imprimir que "imprime" la descripción que propone cada objeto de la jerarquia. Al tener la libertad de sobre escribir un metodo, pueden cometerse errores, entre los cuales podrias implementar un comportamiento no esperado em "imprimir" de un objeto específico y esto significa que ese objeto no podrías utilizarlo. Entre las buenas prácticas de LSP, se recomienda no dejar operaciones que se puedan sobreeescribir, tratando de encontrar comportamiento común implementable en superclases. Se entiende?

[@compartelo007]

@@NicolasBattaglia Cierto me equivoqué, pero la pregunta entonces es la misma pero refiriéndome entonces al método descripción() de las clases hijas, me pareció oir que no debíamos cambiar la lógica de ese método, y si eso es lo que oí entonces es lo que no comprendo porque no podría cambiar la lógica interna de cada una de las descripciones de cada clase hija. A no ser que no fuera eso lo que entendí. Para concretar, imaginemos que el método descripcion de la clase nota de crédito le aplica una lógica diferente a las demás para que dicha descripción muestra más o menos información según algunos condicionales. Entonces significa que según ese principio SOLID no puedo hacer eso en ese método descripcion()?

[@NicolasBattaglia]

La propuesta es evitar sobreescribir operaciones o cambiar la cohesion de las.clases. el mayor problema esta cuando las operaciones modifican el estado interno de los objetos, por esto se busca tratar que las operaciones que sean comunes se implementen en las clases de alto nivel, sin embargo puede suceder (por ejemplo, con el polimorfismo) que es necesario hacer cosas diferentes y concretas , pero hay que prestar mucha atención en seguir manteniendo el comportamiento segun el.contrato propuesto en la superclase!

[@compartelo007]

@@NicolasBattaglia Genial. Gracias

[@mauroorioni9327]

exelente video te mandaste! todo bien explicado y con ejemplos. Aclaras muchas dudas que en otras fuentes no se explican. Un grande!! Saludos.

[@germanhead]

Muy buena explicación, los ejemplos son muy claros. Me saco muchas dudas! muchas gracias Nicolas. saludos

[@ezequielellena]

Tenes el repo de este proyectito?

[@NicolasBattaglia]

hola Eze, lamentablemente no. Lo arme para el ejemplo y no lo subí. Voy a ver si lo encuentro y lo subo

[@francisco11820]

Nicolas, excelente aporte, justo lo que buscaba para entender.

[@freddvincent]

*Que buen video! Muchas gracias por tu tiempo*

[@NicolasBattaglia]

gracias por tu feedback!! Me alegro que te sirva.

[@federicobal3217]

Muy bien explicado!!

[@NicolasBattaglia]

Gracias! 😊

[@luisjavier5224]

Gracias, contenido de calidad es lo que se necesita.

[@pekediablo150]

Genial explicado. Enhorabuena por el canal. Como autodidacta agradezco mucho su labor. Saludos desde España.

[@NicolasBattaglia]

Muchísimas gracias por tu feedback!!!

[@VictorDavidMejiaRamirez]

Muchas gracias!

[@sebastianolarte8353]

Que dicha haberme encontrado este video y por ende su canal. De verdad que es la mejor explicación que he encontrado sobre este tema, una clara explicación seguida de una variedad de ejemplos. Le agradezco mucho por tan valioso aporte que nos hace con este tipo de videos. Desde ya me convierto en un subscriptor y seguidor más de su contenido, espero no deje de compartirnos más contenido de tan alta calidad. Mil gracias.

[@NicolasBattaglia]

te agradezco muchisimo por el tiempo dedicado al feedback. Muchas gracias. Sin duda que seguiré subiendo material que espero que sirva también!!!