SOLID: Liskov substitution, Interface segregation y Dependency Inversion principle

• Liskov Substitution: Por ejemplo, cuando creamos una array, en Java sería List<Integer> nums = new ArrayList<>();. ArrayList implementa List (una interfaz o padre), por lo tanto al llamar los metodos de list estaremos llamando a los metodos implementados en ArrayList.

• Interface segregation: Por ejemplo, una interfaz ‘Television’ no debería tener un método llamado ‘transmitirEn(Laptop)’.

• Dependency Inversion: Por ejemplo, en vez enviar por parámetro un objeto específico (ej: new Corporacion(Ingeniero ing) ), debemos enviar un objeto más abstracto para que nuestra funcionalidad no este conectada a un tipo específico ya que esto puede causar problemas a la hora de arreglar bugs o añadir más features.

FATAL explicado la Interface Segregation… Mejor decir que si tienes una clase abstracta Ave y quieres añadir e instanciar una clase pingüíno, otra golondrina y otra gallina… En la clase abstracta Ave no deberían estar métodos como volar() o nadar() puesto que hay aves que no lo hacen… Por tanto, tendríamos una clase Ave y, por ejemplo, 3 clases abstractas más, con sus métodos específicos AveVoladora, AveNadadora, AveTerrestre. Y entonces extender o implementar Ave con cada una de las que se necesiten… Porque como nos toque implementar un método volar() a una gallina o nadar() a una golondrina…

Dependency inversion es distinto a Dependency Injection (lo que Anahi esta explicando es Dependency Injection no esta explicando Dependency inversion)

Injection vs Inversion
Dependency Injection is an Inversion of Control technique for supplying objects (‘dependencies’) to a class by way of the Dependency Injection Design Pattern. Typically passing dependencies via one of the following:

A constructor
A public property or field
A public setter
The Dependency Inversion Principle (DIP) is a software design guideline which boils down to two recommendations about de-coupling a class from its concrete dependencies:

‘High-level modules should not depend on low-level modules. Both should depend on abstractions.’
‘Abstractions should not depend upon details. Details should depend upon abstractions.’

Liskov substitution: Es cuando tienes una clase padre y una hijo, pero puedes instanciar la clase hijo, pero con tipo de la clase padre, no entiendo la utilidad de ello, espero en la practica entenderlo.

SOLID
Single Responsbility -> Una clase una responsabilidad.
Open/Closed Principle -> Organizar el código modularmente(Uso de interfaces).
Liskov substitution ->Definir una clase hija en una clase padre sin errores.
Interface segregation -> No añadir métodos ajenos a la función principal de la interfaz.
Dependency Inversion -> Depender de abstracciones, entra el uso de inyección de dependencias(Lo que explica Anahi)

me gusta mucho como explicas aqui dejo un contenido excelente que vi para Laravel (yo soy usuario) https://www.laraveltip.com/guia-definitiva-de-principios-solid-explicados-con-laravel/

S → Single Responsability → Una clase debe tener solo una responsabilidad.

• Evita la cascada en el código.

O → Open/Closed Principle → Busca organizar el código modularmente.

• Busca tener composición en la clase, esto quiere decir que la clase esta compuesta por elementos que se encuentran en otras clases, esto va a hacer el código más sencillo de entender.
• Se recomienda más utilizar la composición que la herencia.
• Se busca que la clase sea lo más abstracto posible.

L → Liskov substitution → Se debe poder sustituir una clase hija por una clase padre sin tener errores.

I → Interface segregation → Si una interfaz comienza a crecer demasiado se rompe el primer principio de SOLID.

• Busca que se dividan las funcionalidades que no pertenecen propiamente a la función de la clase o del método.

D → Dependency inversión → Depende de una abstracción, no de algo concreto.

• Se recomienda utilizar interfaces para poder dar comportamientos a diferentes clases.
• Se recomienda pasar parámetros abstractos.

MVP Model-View-Presenter

Básicamente, lo mas importante y útil son las interfaces.

es super interesante, me gusto mucho a la verdad que si es nuevo todoesto para mi ya que aprendi a codificar casi por instinto jajaja pero no hay cosa mas bonita que aprender como es y hacer las cosas a como son… te dan una mejor calidad como desarrollador y calidad en tus trabajos.

Aqui les dejo el link del curso de POO
https://platzi.com/clases/oop/

Los principios SOLID no son reglas son como guias para hacer buen codigo es dificil implementarlo correctamente

interesante, en especial la interface segregation nos hace replantear nustra interfaz para que sea mas util