anncode

La Programación Orientada a Objetos es una forma de pensar y ver las cosas en términos de objetos y responsabilidades.

Para lograr esto nos basamos en técnicas que componen esta metodología.

La Programación Orientada a Objetos es uno de los componentes principales para Diseñar Software.

Paradigma Orientado a Objetos

Seguramente haz visto este término cuando se intenta describir la Orientación a Objetos y es que se dice que es un Paradigma.

Un Paradigma es una forma de ejemplificar un problema.

Por lo tanto el Paradigma Orientado a Objetos hará que usemos estás técnicas de orientación a objetos para analizar y ejemplificar un problema con su solución.

¿Cómo resolvemos un problema Orientándolo a Objetos?

Nuestro objetivo como programadores es: Resolver un problema de la manera más creativa con código.

Dado que nuestra labor se centra en trasladar una solución a código, lo mejor para comenzar es Diseñar.

Mi primer consejo para iniciar este camino es Antes de programar Diseña.

Te recomiendo estos pasos antes de programar una solución:

• 1. Analiza el problema y detecta tus objetos

• 2. Diagrama y plasma gráficamente los objetos que identificaste

• 3. Genera abstracciones

• 4. Programarlo

Tal vez alguno de estos pasos no tengas claro cómo seguirlo, para eso te recomiendo mi Curso de Diseño Orientado a Objetos y Principios SOLID que encuentras a un precio especial en este enlace en el curso vemos todo desde cero y paso a paso, con las mejores prácticas.

Elementos de la Programación Orientada a Objetos

Lo siguiente son las herramientas que tiene la POO para que puedas crear una solución a un problema con código:

• Clases
• Atributos
• Métodos / Funciones
• Objetos

Estos son los elementos que nos servirán para expresar nuestra solución a otros programadores.

Pilares de la Programación Orientada a Objetos

• Herencia
• Abstracción
• Polimorfismo
• Encapsulamiento

Estas son las metodologías que nos guiarán a crear nuestra solución con los elementos anteriores

Recuerda que todo lo anterior son herramientas y guías en las que solo nos basamos para crear soluciones de la forma más creativa.

Nunca habrá una única solución para un problema, debes tomar en cuenta las circunstancias a tu alrededor.

No tomes de manera radical estas metodologías lo más importante es que seas lo suficientemente flexible para adaptarte y ser lo más creativo posible en tu solución.

En mi Curso de Diseño Orientado a Objetos y Principios SOLID te enseño todo desde cero y paso a paso accede a todo el contenido a un precio especial solo aquí en mi sitio web.

😊 Gracias por comparitr haces un excelente trabajo divulgando conocimiento.

Esto más que un Rol de un Programador Todo Poderoso, es un skill que todos debemos buscar.

El Diseño de Software es la clave para crecer más rápido en tu carrera como programador.

La programación es una de las profesiones más concurridas en la búsqueda de talento, pero desafortunadamente, no en todos los niveles.

Lo que se busca en realidad son personas que entiendan a profundidad cómo funciona el software y su crecimiento.

Básicamente crear software: Escalable y Fácil de mantener.

Las personas más demandadas en la carrera de programación son aquellas que saben Diseñar Software.

¿Por qué es importante el Diseño de Software?

Como programadores nuestro trabajo es muy valioso, impacta la vida de muchas personas todos los días. Nuestro trabajo tiene mucho valor.

Por lo tanto cuidar la calidad del código que generamos debe ser algo de lo que tienes que ocuparte.

El software crece muy rápido, es un Organismo Vivo:

• Se Crea
• Crece o Escala
• Cambia
• Algunas partes mueren
• etc.

Debes ser capaz de crear un código que tenga la calidad de cambiar así y MUY RÁPIDO.

¿Cómo Diseñar Software?

En mi carrera como programadora he detectado dos ingredientes que combinados hacen un gran primer paso para entender el mundo del Diseño del Software:

1. Programación Orientada a Objetos
2. Principios SOLID

Programación Orientada a Objetos

Entrenará tu mente para que cuando analices un problema aprendas a ver los elementos clave como objetos.

Objetos que tengan una responsabilidad, sean modulares e intercambiables.

Exacto, como piezas de LEGO.

Entiende cómo funciona la Programación Orientada a Objetos, en este post te lo explico.

Principios SOLID

Nacen de manera natural de la Programación Orientada a Objetos.

Estos son unos Principios recopilados por Robert C. Martín, muy famoso por sus libros sobre Clean Code y Clean Architecture

Son un conjunto de buenas prácticas al aplicar Programación Orientada a Objetos.

Básicamente te enseñan:

• Cómo crear una Clase y/o un método lo más modular posible
• Tips que debes tomar en cuenta para crear una interfaz
• Cómo hacer buenas abstracciones y aplicar Herencia
• Etc.

En mi Curso de Diseño Orientado a Objetos y Principios SOLID te enseño todo desde cero y paso a paso accede a todo el contenido a un precio especial solo aquí en mi sitio web.

😊 Gracias por comparitr haces un excelente trabajo divulgando conocimiento.

¿Inversión de Dependencias es lo mismo que Inyección de Dependencias? te suenan? la diferencia entre ellos suele ser una de las preguntas más concurridas en entrevistas de trabajo.

• Inyección de Dependencias es un Patrón de Diseño
• Inversión de Dependencias es un Principio SOLID (Dependency Inversion Principle DIP)

Dependecy Injection (Inyección de Dependencias)

Este es un Patrón de Diseño que nos dice que los objetos deben ser creados fuera y deben ser proveídos a un método, clase y/o módulo en partícular en lugar de ser él mismo quien los cree.

Por ejemplo, mira la clase Vehicle que en su método constructor necesita un objeto para existir, en este caso el objeto está siendo creado dentro del método, por lo tanto estaríamos violando el Patrón de Diseño Dependency Injection.

class Vehicle(
  val motor = GasMotor()
)

Arreglemos esto.

Extraemos la creación del objeto hacía fuera e independiente de la clase, de esta manera podemos crear un objeto fuera de la clase e inyectarlo.

class Vehicle(
  val motor: Movable
)

val motor = GasMotor()
val vehicle = Vehicle(motor)

Con esto ya estamos cumpliendo la Inyección de Dependencias ✅

He diseñado un Curso de Diseño Orientado a Objetos y Principios SOLID dónde te enseño a aplicar correctamente este principio en problemas reales, echale un ojo a este Cupón de Descuento.

Dependency Inversion Principle de SOLID

El principio dice:

Los módulos de alto nivel no deberían dependeer de los de bajo nivel.

Ambos deberían depender de abstracciones

Para entender este principio es necesario entender principalmente qué significa Alto y Bajo nivel.

Alto Nivel

Serán todas esas clases funciones y/o módulos que necesitan una dependencia, es decir, necesitan de otro objeto para poder crearse.

Por ejemplo: La clase Vehicle necesita un objeto motor para poder crearse, por lo tanto diríamos que Vehicle es una clase de Alto nivel.

class Vehicle(
  val motor: Movable
)

Bajo Nivel

Serán las dependencias en sí. Los objetos necesarios para crear una clase.

La característica principal para que sea de Bajo nivel es que no sea una abstracción (Interfaces y/o Clases Abstractas) sino objetos concretos.

Usando el ejemplo anterior.

Podemos identificar por su nombre, que Movable es una abstracción, y más específicamente una Interfaz.

Por lo tanto para que sea un objeto de bajo nivel necesitamos que motor sea un objeto concreto, es decir, motor podría ser de tipo ElectricMotor y GasMotor como se ve a continuación

class ElectricMotor : Movable()
class GasMotor : Movable()

Estas son clases de bajo nivel y si las instaciamos serían objetos de bajo nivel.

Violando el Principio de Inversión de Dependencias que dice en su primera parte: Los módulos de alto nivel no deberían dependeer de los de bajo nivel.

Instanciaríamos la clase Vehicle de Alto Nivel con un objeto de Bajo Nivel por ejemplo: GasMotor.

class Vehicle(
  val gasMotor: GasMotor
)

Esto hace que nuestra clase Vehicle esté acoplada a solo crear veículos con motor de gas, y cuando evolucionemos, hacer el cambio a motores eléctricos será muy doloroso.

Tener una clase con bajo acoplamiento nos ayuda a hacer software más flexible y escalable.

De hecho hay otro principio de diseño que nos dice que si tenemos «Bajo Acoplamiento y Alta Cohesión» nos ayuda a crear software más saludable.

Cómo detectar una Inversión de Dependencias vs una Inyección de Dependencias

Verás que ahora es muy fácil de entender y es que de acuerdo a la segunda parte del Principio de Inversión de Dependencias: Ambos deberían depender de abstracciones.

Para que exista una Inversión de dependencias necesitamos Depender de Abstracciones (Interfaz o Clase Abstracta)

Mientras que en la Inyección de dependencias simplemente es mantener la creación de objetos fuera de la clase, método y/o módulo e inyectarlos como dependencias.

Por ejemplo:

Aquí podemos ver que el Patrón de Inyección de Dependencias sí se cumple, ya que no estamos creando los objetos dentro de la clase, tenemos la posibilidad de crearlos fuera.

class Vehicle(
  val gasMotor: GasMotor
)

Sin embargo, el Principio de Inversión de Dependencias no se cumple por que no estamos dependiendo de Abstracciones.

Por lo tanto tenemos:

✅ Inyección de Dependencias

❌ Inversión de Dependencias

Otro Ejemplo:

Aquí vemos los dos principios aplicados pues podemos crear objetos fuera de la clase y además la clase dependende de una abstracción

class Vehicle(
  val motor: Movable
)

interface Movable { }

class ElectricMotor : Movable()
class GasMotor : Movable()

Por lo tanto tenemos:

✅ Inyección de Dependencias

✅ Inversión de Dependencias

Puedes explicarme en tu palabras cuál es la diferencia entre ellos? Explícame en los comentarios ✍

En mi Curso de Diseño Orientado a Objetos y Principios SOLID te enseño todo desde cero y paso a paso con ejemplos reales, te dejé un regalo en este link para que lo adquieras a un precio especial.

Si te gustó esta clase no olvides compartirla haces un excelente trabajo divulgando conocimiento ⚡