Forem: Sebastián Barrera Herrera

Programación Orientada a Objetos en TypeScript

Sebastián Barrera Herrera — Tue, 27 Aug 2024 15:14:46 +0000

La programación orientada a objetos es un paradigma de programación enfocado en organizar el desarrollo en objetos (clases) que sean flexibles y reutilizables a lo largo del software mediante datos y objetos que tienen sus atributos y comportamientos únicos.

Desde sus inicios, JavaScript era compatible con la programación orientada a objetos mediante prototipos, lo que lo hacía un poco problemático. Con la versión ES6 se incorporó una sintaxis más conocida (clases), brindando así una mejor experiencia al desarrollar con este paradigma. Por su parte, TypeScript, el superset de JavaScript, permite trabajar con esta sintaxis junto con otro tipo de reglas, lo que hace más atractivo y eficiente el desarrollo de aplicaciones con esta herramienta.

A continuación, las características más importantes de la programación orientada a objetos con su sintaxis y formas de trabajar:

Herencia:

Una clase hija puede heredar atributos o métodos de una clase padre mediante la palabra clave extends.

class Animal {
    nombre: string;
    raza: string;
    edad: number;

    constructor(nombre: string, raza: string, edad: number) {
        this.nombre = nombre;
        this.raza = raza;
        this.edad = edad;
    }
}

class Perro extends Animal {
    constructor(nombre: string, raza: string, edad: number, public vuela: boolean, public muerde: boolean) {
        super(nombre, raza, edad);
    }
}

Aquí podemos ver un ejemplo claro de herencia donde la clase Perro extiende de la clase Animal mediante extends, creando una instancia de la clase. La función del constructor se ejecuta cada vez que se instancia la clase, y super recibe las propiedades que se quieren heredar de la clase padre.

Encapsulamiento:

Define el acceso que se puede tener a una clase desde el exterior y en la instanciación de la misma. Estos permisos de acceso se definen por medio de niveles que definiremos a continuación:

Public: Es el nivel más bajo de protección y permite que toda clase que se extienda o desde el exterior pueda acceder a sus datos.
Private: Las propiedades o métodos definidos con este nivel solo pueden ser vistos dentro de la misma clase que los define; desde ningún otro lugar fuera de la misma se puede acceder.
Protected: No se puede acceder desde cualquier lugar, solamente permite el acceso a los métodos o propiedades desde la clase que se crea o en las clases que la heredan.

Polimorfismo:

Uno de los conceptos más importantes en la programación orientada a objetos se refiere a la capacidad de métodos o atributos con un mismo nombre y diferente firma, siendo llamados en otros objetos o clases instanciadas con un resultado distinto, adaptándose a la necesidad de la misma.

class Animal {
    hacerSonido(): void {
        console.log('Sonido del animal');
    }
}

class Gato extends Animal {
    hacerSonido(): void {
        console.log('Maúlla');
    }
}

Interfaces:

Las interfaces son como contratos que definen el tipo de datos que se puede aplicar a una clase o método mediante la palabra clave implements. Esta debe seguir la norma de que los atributos que contenga deben ser específicamente del tipo de dato definido en la interfaz. Esto ayuda a tener un mayor control del tipo de dato de cada atributo o método que se crea en la clase. Importante saber que las interfaces no crean instancias a comparación de las clases.

interface Automovil {
    marca: string;
    modelo: number;
    kilometraje: number;
}

class Mazda implements Automovil {
    private velocidad: string;
    private asientos: number;

    constructor(marca: string, modelo: number, kilometraje: number) {
        this.marca = marca;
        this.modelo = modelo;
        this.kilometraje = kilometraje;
    }
}

Clases Abstractas:

Las clases abstractas sirven como plantilla para que otras clases hereden los atributos y métodos de ella. Es importante saber que no pueden instanciarse; se pueden crear nuevas clases y extenderse de esta misma. Estas clases se definen con la palabra clave abstract.

abstract class Instrumento {
    abstract tipo: string;
    abstract tocar(): void;
}

class Guitarra extends Instrumento {
    tipo: string;

    tocar(): void {
        console.log('Tocando la guitarra');
    }
}

Constructores:

Este importante método de la programación orientada a objetos se dispara o se llama automáticamente cada vez que se crea una instancia de la clase. Como hemos podido observar en los ejemplos anteriores, el constructor es vital en la inicialización de las diferentes clases y su instanciación.

class Usuario {
    private nombre: string;
    private edad: number;

    constructor(nombre: string, edad: number) {
        this.nombre = nombre;
        this.edad = edad;
    }
}

SOLID Principles

Sebastián Barrera Herrera — Tue, 20 Aug 2024 20:08:10 +0000

When starting in programming, there are steps that need to be taken, and one of them is the SOLID principles, guidelines that will help you improve code quality, regardless of your experience level. For those of us starting on this path, keeping these concepts in mind and applying them to our code can be overwhelming. Often, the initial explanations we receive don’t even mention clean code, which makes sense at the beginning; what’s important are the basics and not scaring beginners with much more complex concepts. The problem arises when, over time, the basics are solid but the code starts to become a scroll due to its length. Bad practices and limited knowledge become constants, and from there, bad practices become the norm.

To change this reality, a bit more effort is required. You’ve learned the basics and know how to kick the ball; now you need a coach who talks about strategy and teaches you how to work as a team. This is similar to scrolls; instead of being sacred, they become a headache and start hindering your learning. As mentioned earlier, you need guidance, a good coach to guide you and show you the path they’ve already traveled. In the age of online courses, having a mentor who becomes your pillar seems impossible, but even if it’s through a recording, there are many who are dedicated, and you can always find someone who genuinely cares and does it very well.

I’m speaking from my experience and what I’ve seen in this process; I’m still on this journey, my code is still a scroll, and it will take time to become solid. For someone else, it might be different, they might have a different opinion, or they might not have had to make these extra miles, but for those who identify with this, I will share and provide examples of the recommendations that will be the principles of change in my code.

S: Single Responsibility Principle

This first principle is about independence and responsibilities. It tells us that, regardless of how large or small our construction is, each part should have a single responsibility. Not overloading a class, function, or object with more weight than it can bear helps us avoid future problems.

class Student {
    constructor(public name: string, public age: number) {}
}

class School {
    constructor(public nameSchool: string, public type: string) {}
}

class Certificate {
    constructor(private student: Student, private school: School) {}

    generateCertificate(): string {
        return `Certificate for ${this.student.name}, age ${this.student.age}, from ${this.school.nameSchool} (${this.school.type})`;
    }
}

O: Open/Closed Principle

This important principle tells us that every class should be open for extension but closed for modification. I can have a base class that serves as a reference in several places; this class, being efficient, can be extended, and thus the functioning of its child classes will improve. However, I should avoid modifying the main class so that the functioning of the child class is optimal. A tiger’s offspring looks like a tiger.

interface Car {
    inspect(): string;
}

class Mazda implements Car {
    constructor(public brand: string, public model: string) {}

    inspect(): string {
        return `Inspecting Mazda: ${this.brand} ${this.model}`;
    }
}

...More class

L: Liskov Substitution Principle

This principle is named after its creator, Barbara Liskov. Personally, it has been the most challenging for me to understand, but I will make the effort to be as clear as possible so that you understand it. Each class that inherits from another can be used as its parent class without needing to know the differences between them and should act without causing unexpected errors.

class Animal {
    makeSound(): void {
        console.log("The animal makes a sound");
    }
}

class Dog extends Animal {
    makeSound(): void {
        console.log("The dog barks");
    }
}

class Fish extends Animal {
    makeSound(): void {
        console.log("The fish makes no sound");
    }
}

function makeItSound(animal: Animal) {
    animal.makeSound();
}

const dog = new Dog();
const fish = new Fish();

makeItSound(dog);  
makeItSound(fish);

I: Interface Segregation Principle

One of the most important principles, this principle is key to bringing about change and reveals to us that it doesn’t matter to have many interfaces. If you have several clients with different arguments and behaviors, create interfaces that fit each one and do not force everyone to have a general interface with properties they will not use.

interface SportWithBall {
    ball: string;
}

interface SportWithPlayers {
    players: string[];
}

class Soccer implements SportWithBall, SportWithPlayers {
    players = ['Player1', 'Player2'];
    ball = 'Soccer ball';
}

class Swimming implements SportWithPlayers {
    players = ['Swimmer1', 'Swimmer2'];
}

D: Dependency Inversion Principle

We come to the last principle, which clearly states: “High-level classes should not depend on low-level classes but on interfaces or abstractions that define what they need.”

interface NotificationService {
    send(message: string): void;
}

class EmailService implements NotificationService {
    send(message: string) {
        console.log("Sending email:", message);
    }
}

class SmsService implements NotificationService {
    send(message: string) {
        console.log("Sending SMS:", message);
    }
}

class Notification {
    private service: NotificationService;

    constructor(service: NotificationService) {
        this.service = service;
    }

    notify(message: string) {
        this.service.send(message);
    }
}

These are the definitions I give; it might be better and more complete, but for now, on the path I’m traveling, it’s what I’ve understood. I hope these examples or the definitions of these principles can be useful to someone. I try to document my process and thus show the progress I’m making. Thank you very much for reading. Have a great day! 😀💪🎉

Principios SOLID

Sebastián Barrera Herrera — Tue, 20 Aug 2024 19:57:23 +0000

Al iniciar en la programación, hay pasos que es necesario recorrer, y uno de ellos son los principios SOLID, unas guías que te ayudarán a mejorar la calidad del código, sin importar el nivel de experiencia que tengas. Para los que comenzamos este camino, puede ser abrumador tener presente estos conceptos y aplicarlos en nuestro código. Muchas veces, las primeras explicaciones que recibimos ni siquiera mencionan el código limpio, y tiene sentido al principio; lo importante son las bases y no asustar a los principiantes con conceptos mucho más complejos. El problema surge cuando, con el tiempo, las bases son sólidas pero el código empieza a volverse un pergamino de lo largo que llega a ser. Las malas prácticas y el poco conocimiento del tema se convierten en constantes, y a partir de ahí, las malas prácticas se vuelven la norma.

Para cambiar esta realidad, se necesita un poco más de esfuerzo. Ya aprendiste las bases y sabes cómo chutar el balón, ahora se requiere un entrenador que hable de estrategia y te enseñe a trabajar en equipo. Así sucede con los pergaminos, lejos de ser sagrados, se convierten en un dolor de cabeza y te empiezan a frenar el aprendizaje. Como mencioné anteriormente, se requiere una guía, un buen entrenador que te oriente y te enseñe el camino que él ya recorrió. En los tiempos de los cursos en línea, parece imposible tener un sensei que se convierta en tu bastión, pero, aunque sea a través de una grabación, hay muchos que tienen la vocación y uno siempre encuentra a alguien que realmente se esmera y lo hace muy bien.

Hablo sobre mi experiencia y lo que he visto en este proceso; todavía lo estoy recorriendo, mi código aún es un pergamino y se va a demorar en ser sólido. Para otra persona puede ser distinto, puede tener otra opinión o quizá no les tocó hacer estas millas extras, pero para aquellos que se sientan identificados, les voy a comentar y poner ejemplos de las recomendaciones que serán los principios del cambio en mi código.

S: Single Responsibility Principle (Principio de Responsabilidad Única)

Este primer principio habla de independencia y responsabilidades. Nos dice que, sin importar lo grande o pequeña que sea nuestra construcción, cada parte debe tener una responsabilidad única. No cargar a una clase, función u objeto con más peso del que puede levantar nos ayuda a evitar problemas futuros.

class Student {
    constructor(public name: string, public age: number) {}
}

class School {
    constructor(public nameSchool: string, public type: string) {}
}

class Certificate {
    constructor(private student: Student, private school: School) {}

    generateCertificate(): string {
        return `Certificate for ${this.student.name}, age ${this.student.age}, from ${this.school.nameSchool} (${this.school.type})`;
    }
}

O: Open/Closed Principle (Principio de Abierto/Cerrado)

Este importante principio nos dice que toda clase debe estar abierta a extenderse, pero cerrada a modificarse. Puedo tener una clase base que me sirva de referencia en varios lugares; esta clase, al ser eficiente, puede extenderse y así el funcionamiento de sus clases hijas mejorará. Sin embargo, debo evitar modificar la clase principal para que el funcionamiento de la clase hija sea óptimo. Hijo de tigre sale pintado.

interface Car {
    inspect(): string;
}

class Mazda implements Car {
    constructor(public brand: string, public model: string) {}

    inspect(): string {
        return `Inspecting Mazda: ${this.brand} ${this.model}`;
    }
}

...More class

L: Liskov Substitution Principle (Principio de Sustitución de Liskov)

Este principio lleva su nombre en honor a quien lo creó, Barbara Liskov. Personalmente, ha sido el que más me ha costado entender, pero haré el esfuerzo de ser lo más claro posible para que lo entiendas. Cada clase que hereda de otra puede usarse como su clase padre sin necesidad de conocer las diferencias entre ellas y debería actuar sin causar errores inesperados.

class Animal {
    makeSound(): void {
        console.log("The animal makes a sound");
    }
}

class Dog extends Animal {
    makeSound(): void {
        console.log("The dog barks");
    }
}

class Fish extends Animal {
    makeSound(): void {
        console.log("The fish makes no sound");
    }
}

function makeItSound(animal: Animal) {
    animal.makeSound();
}

const dog = new Dog();
const fish = new Fish();

makeItSound(dog);  
makeItSound(fish);

I: Interface Segregation Principle (Principio de Segregación de la Interfaz)

Uno de los más importantes, este principio es clave para generar ese cambio y nos revela que no importa tener muchas interfaces. Si tienes varios clientes con distintos argumentos y comportamientos, crea interfaces que se ajusten a cada uno y no obligues a todos a tener una interfaz general con propiedades que no van a utilizar.

interface SportWithBall {
    ball: string;
}

interface SportWithPlayers {
    players: string[];
}

class Soccer implements SportWithBall, SportWithPlayers {
    players = ['Player1', 'Player2'];
    ball = 'Soccer ball';
}

class Swimming implements SportWithPlayers {
    players = ['Swimmer1', 'Swimmer2'];
}

D: Dependency Inversion Principle (Principio de Inversión de Dependencias)

Llegamos al último principio, que claramente nos dice: “Las clases de alto nivel no deben depender de las clases de bajo nivel, sino de interfaces o abstracciones que definan lo que necesitan.” En el siguiente ejemplo se ve más claro.

interface NotificationService {
    send(message: string): void;
}

class EmailService implements NotificationService {
    send(message: string) {
        console.log("Sending email:", message);
    }
}

class SmsService implements NotificationService {
    send(message: string) {
        console.log("Sending SMS:", message);
    }
}

class Notification {
    private service: NotificationService;

    constructor(service: NotificationService) {
        this.service = service;
    }

    notify(message: string) {
        this.service.send(message);
    }
}

Estas son las definiciones que yo le doy; quizá pueda estar mejor y ser más completo, pero hasta ahora, en el camino que estoy recorriendo, es lo que he entendido. Espero que estos ejemplos o la definición de los mismos principios puedan servir a alguien. Trato de documentar mi proceso y así evidenciar el avance que estoy teniendo. Muchas gracias por la lectura. ¡Feliz día! 😀💪🎉