Hasta ahora con lo que aprendimos, en el diseño orientado a objetos, nos dimos cuenta de que hay casos en los que no podemos utilizar el sistema de tipos estáticos para establecer ciertas precondiciones. En su lugar, tendremos que depender de clausulas de guarda en tiempo de ejecución, como este chequeo que vimos en lecciones anteriores sobre el argumento nulo, por ejemplo.

En este punto de la serie que venimos viendo sobre objetos y algunas buenas prácticas de desarrollo, creo que es importante hacer un pequeño desvío y hablar sobre los tipos anulables (Nullable) y no anulables (Non-nullable).

En esta oportunidad, vamos a hablar sobre un tema relacionado de alguna manera con nuestra “Ley de Robustez” que vimos en el post anterior, particularmente de las “entradas” o “inputs” de nuestro sistema, ya sea en nuestros métodos, constructores, etc. La idea es que podamos observar una clase que vimos anteriormente en nuestro post sobre CQS, que si no lo viste todavía te invito a que te des una vuelta para poder complementar bien esta nueva lección. La idea es revisar nuestra clase FileStore y poder prestar atención a cómo está diseñada, para que no tengas que buscarla te la facilito en las próximas líneas. La idea es que, luego del snippet de código, puedas responder a la pregunta realizada debajo.

En nuestro post anterior, exploramos en profundidad el principio de Separación de Comandos y Consultas (CQS), una piedra angular para construir software de calidad. Como breve conclusión de ese post, sabemos que para aplicar CQS es necesario que sea una convención del equipo, donde decidimos si vamos a implementar o no nuestro principio CQS y en qué lugar. No podemos ir a medias tintas, ya que si hiciéramos eso, no sabríamos qué esperar de nuestras interfaces, básicamente porque terminaríamos consultando si realmente aplica o no el principio, lo cual es algo que queremos evitar.

• CQS nos dice que nuestras operaciones o deben ser comandos o consultas, pero no ambas.

Cuando llamamos a un método, normalmente se ejecutara sentencia a sentencia desde el principio hasta encontrar una sentencia con un return, o al encontrar el final del método. Si en algún punto quisieras prevenir que se siga ejecutando el método, podemos insertar un return, asegurandonos que todo el resto del método no se ejecutará.

Bienvenidos a otra lección en nuestra serie sobre Programación Orientada a Objetos. Hemos estado hablando de abstracciones, de simplificar la realidad y de representarla con objetos y clases según nuestro “modelo de dominio”. Pero, ¿qué significa exactamente modelar en este contexto? En esta lección, vamos a profundizar en cómo el modelado se relaciona con la abstracción y exploraremos cómo aplicar estos conceptos para simplificar la complejidad de la realidad.

Bienvenidos a una nueva lección de nuestra serie sobre Programación Orientada a Objetos. En nuestra lección anterior, exploramos el concepto de encapsulamiento y cómo nos ayuda a ocultar la complejidad innecesaria, como los detalles de implementación y la protección de invariantes en nuestro sistema. Hoy, avanzaremos un paso más y nos sumergiremos en el mundo de la Abstracción. Este principio es fundamental en POO, ya que nos permite centrarnos en lo que es relevante para un contexto específico, omitiendo los detalles que no son necesarios. Veremos cómo la abstracción nos ayuda a construir modelos más limpios y sostenibles de la realidad, facilitando el manejo de sistemas complejos.

Existe un principio fundamental pero a menudo malinterpretado: la encapsulación. Este concepto, más que un simple mecanismo técnico, es una filosofía de diseño que impregna cada línea de código que escribimos y cada objeto que creamos.

En nuestras lecciones anteriores, hemos explorado varios conceptos fundamentales de la programación orientada a objetos. Hoy, profundizaremos en el concepto de composición, un pilar esencial en el diseño de software robusto y flexible. La composición no solo es crucial para entender cómo los objetos pueden trabajar juntos de manera efectiva, sino que también es una piedra angular para lograr un código más limpio, sostenible y escalable. A través de ejemplos prácticos, veremos cómo la composición puede transformar nuestra manera de construir y estructurar nuestras aplicaciones.

El polimorfismo, uno de los conceptos centrales de la programación orientada a objetos, se refiere a la capacidad de que diferentes objetos sean tratados como instancias de la misma clase. Esencialmente, el polimorfismo permite que distintos objetos respondan a la misma interfaz o método de maneras distintas, facilitando la flexibilidad y extensibilidad en el diseño de software. En la práctica significa que si un parametro tiene un cierto tipo de clase, cualquier objeto que es una instancia de esa clase puede ser un argumento válido. Por ejemplo, cualquier instancia de Gateway puede ser pasado como un argumento del método prepare() como vemos en el siguiente ejemplo:

Es posible definir solo una parte de una clase y dejar a otros expandirla. Por ejemplo, podemos tener una clase sin propiedades y métodos, pero si lo que llamamos firmas de métodos o que algunos llaman contratos. Ese tipo de clase normalmente es llamado interface, y muchos lenguajes orientados a objetos permiten definir ese tipo de clase. Una clase luego puede implementar la interfaz y proveer la implementación concreta de los métodos que fueron declarados o definidos en la interfaz.

En esta serie sobre Programación Orientada a Objetos, hemos explorado varios conceptos clave. Hoy, nos sumergiremos en el mundo del manejo de dependencias, un aspecto crucial para escribir código limpio y mantenible.

Además de estados, un objeto también tiene comportamiento, que sus clientes, es decir, quienes usan los objetos, pueden utilizar. Estos comportamientos de nuestro objeto son definidos mediante métodos dentro de la clase. Los métodos públicos son los únicos accesibles para los clientes de nuestro objeto. Ellos pueden ser llamados en cualquier momento luego de que el objeto fue creado. Algunos métodos devuelven algo a quien los llama. En ese caso un return type debe ser declarado (en caso de utilizar lenguajes tipados). Otros métodos nos retornaran nada. En ese caso el tipo de retorno será el tipo especial void (de nuevo en caso de utilizar lenguajes tipados).

Ahora que hemos establecido una base sólida con clases y objetos, es hora de dar un paso más. En esta segunda lección de “Programando con Objetos”, nos centraremos en un aspecto crucial de cualquier objeto en la programación orientada a objetos: su estado.

Después de nuestra inmersión inicial en el mundo de las clases y los objetos, hoy vamos a dar un paso más en nuestra nueva serie “Programando con Objetos”. ¿Listos para sumergirnos aún más en la programación orientada a objetos con un toque práctico? Vamos a hacer exactamente eso, pero esta vez, con un poco más de acción mediante TypeScript, que esto no te asuste, ya que la idea es aprender conceptos y cosas generales de la mayoría de los lenguajes más comunes de nuestro día a día por lo tanto no creo que tengas dificultades si es que manejas otro lenguaje para el aprendizaje que nos encaminaremos.

Bienvenidos a este nuevo post, en la publicación anterior, comenzamos nuestra exploración del paradigma orientado a objetos, un pilar fundamental de la programación moderna. Hoy, nos vamos a enfocar en el concepto de “clase” y cómo se utiliza en la interpretación más común y ampliamente adoptada de este paradigma.

¿Qué es el Paradigma Orientado a Objetos?

La programación orientada a objetos es un paradigma que nos permite agrupar propiedades y métodos relacionados en un concepto llamado objeto. Estos objetos son construidos a partir de un “esquema (blueprint)”, definido por el programador, conocido como concepto de Clase.

Antes de comenzar algo muy común de pensar es: ¿De que estamos hablando cuando hablamos sobre un Paradigma de Programación? Bueno en realidad es bastante más sencillo de lo que parece, ya que no es más que un estilo de programación, es decir, son diferentes maneras de resolver problemas, utilizando enfoques de resolución diferentes según el paradigma que elijamos para realizar nuestras soluciones.

¡Bienvenidos nuevamente a la continuación de nuestra serie sobre Big O! Si esta es tu primera entrada al blog y estás interesado en este tema (muchas veces por necesidad debido a las entrevistas, pero interesado de alguna forma para mejorar…) es probable que te hayas hecho algunas de estas preguntas:

Ahora que tenemos una comprensión básica de la notación Big-O gracias al post anterior (te invito a que lo revises), podemos comenzar a buscar cálculos algo más costosos para ir entendiendo como se evaluan los algoritmos a grandes rasgos.

Diseñar y construir algoritmos es una parte integral del desarrollo de software. Aunque el objetivo principal de cada algoritmo es resolver un problema particular, es esencial considerar cómo un algoritmo realiza su trabajo y cuántos recursos necesita para hacerlo, ya que en definitiva esto en algún momento se transformará en costos para nuestro cliente. Estos recursos incluyen tanto el tiempo de cálculo, que se refiere a cuánto tiempo se necesita para ejecutar un algoritmo, como el espacio de memoria, que se refiere a cuánto almacenamiento requiere el algoritmo. Esta necesidad de analizar la eficiencia de los algoritmos da lugar al estudio de la complejidad algorítmica.