El diseño de bajo nivel (LLD) es una fase crítica en el desarrollo de software que cierra la brecha entre el diseño de alto nivel y la implementación real. Mientras que el diseño de alto nivel se centra en planos arquitectónicos, LLD se ocupa de cómo se implementa cada componente, clase o función para cumplir con los requisitos generales del sistema.

En términos más simples, LLD implica diseñar clases, métodos, interfaces e interacciones entre ellos, asegurando que el código sea eficiente, mantenible y escalable. Es una habilidad esencial para los ingenieros de software, especialmente cuando construyen sistemas que deben ser robustos, reutilizables y fáciles de modificar con el tiempo.

Este blog le presentará los conceptos, principios y técnicas clave involucrados en el diseño de bajo nivel y le mostrará cómo pueden ayudarle a escribir un código mejor y más fácil de mantener.

La primera pregunta que nos viene a la mente es:

¿Por qué es importante el diseño de bajo nivel?

1. Mantenibilidad: un diseño bien pensado facilita el mantenimiento, la ampliación y la depuración del código. Un diseño deficiente genera deuda técnica, lo que hace que los cambios futuros sean costosos.
2. Escalabilidad: Un buen LLD garantiza que su código sea escalable, tanto en términos de rendimiento como de compatibilidad con nuevas funciones a medida que el sistema evoluciona.
3. Reutilizabilidad: Los componentes bien diseñados se pueden reutilizar en diferentes partes de un sistema o en proyectos completamente diferentes.
4. Claridad: con un diseño bien definido, los ingenieros pueden comprender cómo encajan varias partes del sistema, lo que facilita la colaboración.

Para cerrar la brecha entre los conceptos LLD y el código real, analicemos el proceso de diseño de un diagrama de bajo nivel mediante los siguientes pasos:

Paso 1: Principios orientados a objetos
Paso 2: Principios SÓLIDOS
Paso 3: Patrones de diseño

Principios orientados a objetos

Concepto de programación orientada a objetos. 4 pilares son imprescindibles para empezar a aprender diseño de bajo nivel. Ya cubrí este concepto en un breve blog de pago

Principios SÓLIDOS

S: Principio de Responsabilidad Única (SRP)

• Cada unidad de código debe tener una sola responsabilidad.
• Una unidad puede ser una clase, módulo, función o componente.
• Mantiene el código modular y reduce el acoplamiento estrecho.

Ejemplo: Imagine una clase que maneja tanto la autenticación como el registro de usuarios. Si necesitamos cambiar cómo funciona el registro, terminaríamos modificando también la clase de autenticación. Esto viola el SRP. En su lugar, deberíamos tener dos clases separadas: una para la autenticación de usuarios y otra para el registro, de modo que cada clase tenga una única responsabilidad.

O: Principio abierto/cerrado (OCP)

• Las unidades de código deben estar abiertas para extensión pero cerradas para modificación.
• Amplíe la funcionalidad agregando código nuevo, sin modificar el código existente.
• Útil en sistemas basados ​​en componentes como una interfaz de React.

Ejemplo: Considere un sistema de procesamiento de pagos que maneja pagos mediante tarjetas de crédito. Si necesita agregar soporte para PayPal, en lugar de modificar el código existente, debe ampliarlo agregando una nueva clase para pagos de PayPal. Esto garantiza que el sistema existente permanezca estable y al mismo tiempo permite agregar nuevas funciones.

L: Principio de sustitución de Liskov (LSP)

• Las subclases deben ser sustituibles por sus clases base.
• La funcionalidad de la clase base debería ser utilizable por todas las subclases.
• Si una subclase no puede usar la funcionalidad de la clase base, no debería estar en la clase base.

Ejemplo: Si tenemos una clase Bird que tiene un método fly() y creamos una subclase Penguin, que no puede volar, esto viola LSP. La clase Penguin no debería heredar fly() ya que cambia el comportamiento esperado. En cambio, la clase Bird debería refactorizarse para manejar aves que pueden y no pueden volar de manera diferente.

I: Principio de segregación de interfaz (ISP)

• Proporcione múltiples interfaces específicas en lugar de algunas de propósito general.
• Los clientes no deberían depender de métodos que no utilizan.

Ejemplo: Supongamos que tenemos una interfaz Animal con los métodos fly(), swim() y walk(). Una clase Perro que implemente Animal se vería obligada a definir fly(), lo cual no necesita. Para cumplir con el ISP, debemos dividir la interfaz Animal en interfaces más pequeñas como Flyable, Swimmable y Walkable para evitar forzar métodos irrelevantes en las clases

D: Principio de inversión de dependencia (DIP)

• Depende de abstracciones, no de clases concretas.
• Usa abstracciones para desacoplar dependencias entre partes del sistema.
• Evite llamadas directas entre unidades de código, utilice interfaces o abstracciones.

Ejemplo: en una aplicación de comercio electrónico, si el proceso de pago (módulo de alto nivel) depende directamente de una pasarela de pago específica como PayPal (módulo de bajo nivel), cambiar la pasarela de pago requiere modificar el proceso de pago. Al introducir una abstracción, como una interfaz PaymentProcessor, el proceso de pago puede funcionar con cualquier método de pago sin necesidad de conocer los detalles de PayPal o de cualquier otro servicio.

Patrones de diseño

Los patrones de diseño son soluciones comprobadas a problemas comunes que surgen en el diseño de software. Son mejores prácticas que los desarrolladores pueden seguir para resolver problemas de diseño específicos de manera eficiente y sistemática. En lugar de reinventar la rueda, los patrones de diseño proporcionan un enfoque estándar para resolver problemas recurrentes.

Los patrones de diseño se pueden clasificar en tres tipos:

1. Patrones creativos: ocuparse de la creación de objetos

   • Patrón de diseño de fábrica
   • Patrón de diseño de fábrica abstracto
   • Patrón de diseño del constructor
   • Patrón de diseño de prototipo
   • Patrón de diseño singleton

2. Patrones estructurales: trata la composición y las relaciones de los objetos

   • Patrón de adaptador
   • Patrón de puente
   • Patrón compuesto
   • Patrón decorador
   • Patrón de fachada
   • Patrón de peso mosca
   • Patrón de proxy

3. Patrones de comportamiento: lidiar con la interacción y la responsabilidad del objeto

   • Patrón de cadena de responsabilidad
   • Patrón de comando
   • Patrón de intérprete
   • Patrón del mediador
   • Patrón de recuerdo
   • Patrón de observador
   • Patrón de estado
   • Patrón de estrategia
   • Patrón de método de plantilla
   • Patrón de visitantes

Ahora que hemos sentado las bases explorando los principios SOLID e introducido el vasto panorama de los patrones de diseño, ¡estamos listos para profundizar más! En la próxima serie, desglosaré cada patrón de diseño con ejemplos prácticos y escenarios del mundo real. Ya sea que recién esté comenzando su viaje de diseño o esté buscando perfeccionar sus habilidades, estos patrones lo ayudarán a escribir código más limpio y escalable. Estén atentos al próximo blog, donde desentrañaremos el primer patrón de diseño, ¡paso a paso!

Si has llegado hasta aquí, no olvides darle a Me gusta ❤️ y dejar un comentario a continuación con cualquier pregunta o idea. ¡Tus comentarios significan mucho para mí y me encantaría saber de ti!