anncode

[Android Native, Kotlin, Geek & Teacher]

Aprendiendo a analizar un problema Orientado a Objetos 0 (0)

Una de las habilidades más importantes que debes desarrollar en la Programación Orientada a Objetos es que aprendas a pensar en Objetos.

Los objetos pueden ser físicos o conceptuales

Los objetos físicos son todas las cosas que sí podemos ver y hasta tocar. Por ejemplo:

  • user
  • product
  • payment

Los conceptuales no existen fisicamente, existen imaginariamente o conceptualmente. Por ejemplo:

  • account
  • bag
  • session

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

Los objetos son sustantivos y no verbos

Esta es una de las principales claves para saber que el elemento en el que estoy pensando es un objeto. Los objetos nunca deben ser acciones o verbos, en su lugar son sustantivos.

Un sustantivo según este sitio es: «la palabra que designa personas, animales, plantas…»

Los objetos tienen características y funcionalidades

Los objetos deben tener características y/o funcionalidades.

Por ejemplo:

El objeto Mochila tiene como características: tamaño, color, tipo.

Al tratar de definir las características de un objeto se suele cometer el error de decir la respuesta a ella por ejemplo decir que una característica de Mochila es Verde. Debes ir a un nivel más arriba de abstracción y pensar lo que define a Verde como característica, esto sería el color.

Los objetos los detectaremos en Historias de Usuario

Al estár trabajando activamente en un proyecto real el primer concepto que conocerás son: Las Historias de Usuario (User Stories)

Estás provienen de las metodologías Agile y básicamente narran una sitiuación en el software con sus involucrados.

De aquí es de dónde partiremos para detectar nuestros objetos

Una Historia de Usuario se ve así:

  • Título: Registrarse
  • Cómo: Lector del Blog
  • Quiero: Suscribirme al Blog
  • Para: Poder realizar los comentarios a las entradas de mi interés

Detectemos los objetos:

  • User
  • Blog
  • Comment
  • Post

Sí, parece una locura que con tan poca información detectemos todo eso, pero por eso es tan importante aprender a analizar y sobre todo pensar en objetos.

Ahora te muestro cómo lo hicimos:

ObjetoExplicación
UserLo obtuvimos de Cómo: Lector del Blog nos indica que un Lector del blog puede ser un usuario
BlogLo obtuvimos de Quiero: Suscribirme al Blog
CommentLo obtuvimos de la sección Para: Poder … los comentarios pueden tener: título y descripción que son atributos
PostLo obtuvimos de Para: Poder … los comentarios estarán visualizandose en la entidad Post

Ahora ya sabes que usamos las historias de usuario para identificar objetos, estos pueden ser físicos o conceptuales, sus nombres siempre son adjetivos y tienen carácterísiticas y funcionalidades.

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.

😊 Gracias por comparitr haces un excelente trabajo divulgando conocimiento.

Principios SOLID 0 (0)

Los principios SOLID son un acrónimo recopilado por Robert C. Martín en su libro Clean Architecture.

Nacen de la Programación Orientada a Objetos y sirven para Diseñar Programas.

  • Tolerantes al cambio
  • Fácil de entender
  • Reutilizables

Para mí son recomendaciones y guías nos muestran cómo crear, Clases, Métodos, Interfaces, etc. correctamente y conforme a la POO.

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.

Objetivo de los Principios SOLID

Su principal Objetivo basado en la POO es:

Crear software de la forma más modular posible.

Al tener software y sus componentes con esta calidad nos permitirá ensamblarlo e intercambiarlo como si fueran Bloques de Lego.

Principios SOLID uno a uno de manera general

(S) Single Responsibility Principle

Significa: Responsabilidad Única pero, se entenderá mucho más si lo definimos como: «Que un elemento de un programa tenga solo una sola razón para cambiar»

Cada componente debe ser sumamente independiente pero al mismo tiempo tener las capacidades de conectarse con otros para trabajar y resolver tareas más complejas.

(O) Open / Closed Principle

«Abierto por extensión pero cerrado para modificación»

Aquí nos enfocamos en pensar cómo hacer crecer el software o en otras palabras, hacerlo Escalable.

El software debería poder crecer sin dolor, si añadir algo nuevo provoca una multitud de cambios puede ser que tengamos que abrir un montón de clases y modificarlas.

Precisamente para evitar este dolor el principio dice que los elementos deben ser Cerrados para Modificación.

Pero entonces, ¿cómo añado algo nuevo?

Si añadirlo significa ensamblarlo o conectarlo como un bloque de Lego, ¡Bingo! tu diseño es escalable.

(L) Liskov Sustitution Principle

Barbara Lizkov fue la creadora de este principio.

La definición compleja dice:

Por cada objeto O1 del tipo S existe un objeto O2 del tipo T, cuando O1 es sustituído por O2 entonces S es un subtipo de T.

Pero en otras palabras podemos decir que:

En una jerarquía de clases padre e hijos. Los hijos deben cumplir por completo con la naturaleza de su padre sin hacerse pasar por otras clases

(I) Interface Segregation Principle

Significa: Segregación de Interfaces.

Segregar Interfaces viene de la acción de dividir, y para dividir correctamente una Interfaz hay que seguir pensando en las responsabilidades que debe tener.

Cuando implementas una interfaz en una clase, esta debe estar diseñada para que a todos sus métodos les escribas un comportamiento.

Si por alguna razón al implementar una interfaz estás dejando métodos vacíos esta es una señal de que tal vez tiene muchas responsabilidades, por lo que necesitarás segregarla o dividirla.

(D) Dependency Inversion Principle

El principio dice:

Los módulos de alto nivel no deberían depender de los de bajo nivel.
Ambos deberían depender de abstracciones

Lo primero que hay que diferenciar es que la Inversión de Dependencias es diferente a la Inyección de Dependencias.

El Objetivo de la Inyección de Dependencias es suministrar objetos a un elemento en lugar de ser él mismo quien los cree.

Por otro lado el diferenciador del Principio de Inversión de Dependencias es su última parte: Ambos deberían depender de abstracciones.

A cualquier nivel que lleves este principio, desde un método, una clase, un módulo etc. La Inversión de dependencias se verá al depender de Abstracciones en lugar de cosas concretas.

Los elementos más abstractos que tenemos en Kotlin son: Clases Abstractas y las Interfaces.

apple fruit with plastic syringes

El objetivo de este Post es darte un panorama general sobre los Principios SOLID, visita todos y cada uno por separado en nuestro sitio web para que tengas más comprensión con ejemplos de código.

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.

😊 Gracias por comparitr haces un excelente trabajo divulgando conocimiento.

¿Qué es la Programación Orientada a Objetos? 0 (0)

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.

person writing on white paper

¿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.

Diseño de Software 0 (0)

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.

woman wearing black t-shirt holding white computer keyboard

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.

man wearing gray polo shirt beside dry-erase board

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.

blue and yellow plastic blocks

¿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.

child pointing to red interlocking brick toy

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.
red and purple coloring pencils on pink journal

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.

🏋️‍♀️ State Hoisting with Jetpack Compose 0 (0)

El término State lo estarás observando mucho cada vez que hablemos de Programación Funcional, por que tiene que ver o está involucrado con el principio de Inmutabilidad.

Un State puede ser cualquier cosa que cambie en el tiempo por ejemplo:

  • Un Archivo
  • Una Variable
  • etc.

En Jetpack Compose buscaremos tener Composables Stateless que traducido es Sin Estado.

En esta clase vamos a repasar el concepto de Recomposition para entender cómo con los keywords remember y rememberSaveable podemos integrar una variable «mortal» al Recomposition Tree de un Composable, ya que lograr que un elemento se recomponga a partir de una acción no es tan sencillo como setear el dato de una variable a un elemento.

Una vez que entendemos cuál es el rol de las variables en Jetpack Compose, es importante que sepas cómo aplicar el Patrón de Diseño:

  • State Hoisting

Este nos ayudará a crear Composables más inmutables o Stateless que sean más fáciles de testear. Te explico cómo hacer todo esto con un ejemplo en la clase 👇

Te dejo los slides y para que nunca se te olvide.

Aprendí un montón preparando esta clase, aplicando State Hoisting es muy fácil crear Composables que se puedan testear muy bien.

Cuentáme en los comentarios con tus palabras cómo le explicarías este concepto a otro programador?

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