Fundamentos del Diseño Orientado a Objetos: Principios SOLID y el Rol de los Prototipos en el Desarrollo de Software

Principios Fundamentales del Diseño Orientado a Objetos: SOLID

Los principios SOLID son un conjunto de cinco directrices de diseño en la programación orientada a objetos, destinados a hacer que los diseños de software sean más comprensibles, flexibles y mantenibles.

1. Principio de Responsabilidad Única (Single Responsibility Principle - SRP)

No debería haber nunca más de una razón para cambiar una clase. Una clase debería concentrarse solo en hacer una cosa, de tal forma que cuando cambie algún requisito, en mayor o menor medida, dicho cambio solo afecte a dicha clase por una única razón. Su finalidad es evitar que el cambio de una responsabilidad en una clase pueda provocar fallos en las demás responsabilidades de la misma, y también evitar que los clientes de una clase carguen con elementos que no utilizan.

2. Principio Abierto/Cerrado (Open/Closed Principle - OCP)

Las entidades de software (clases, módulos, funciones, entre otras) deberían estar abiertas a la extensión, pero cerradas a la modificación. Es decir, se debe poder cambiar el comportamiento de una clase mediante herencia, polimorfismo y composición sin modificar su código fuente. Implica anticiparse al cambio, preparando el código para que los posibles cambios en el comportamiento de una clase se puedan implementar mediante extensión (herencia, composición) en lugar de modificación directa.

3. Principio de Sustitución de Liskov (Liskov Substitution Principle - LSP)

Las funciones que utilicen punteros o referencias a clases base deben ser capaces de usar objetos de clases derivadas de estas sin saberlo. Las subclases deben comportarse adecuadamente cuando sean usadas en lugar de sus clases base. Se deduce que cada clase que hereda de otra puede usarse como su clase base sin necesidad de conocer las diferencias entre ellas, manteniendo la corrección del programa.

4. Principio de Segregación de Interfaces (Interface Segregation Principle - ISP)

Los clientes no deberían ser forzados a depender de interfaces que no utilizan. Esto implica mantener interfaces pequeñas y cohesivas, que puedan coexistir unas con otras, en lugar de interfaces grandes y monolíticas. De esta forma, una clase solo implementará los métodos que realmente necesita.

5. Principio de Inversión de Dependencias (Dependency Inversion Principle - DIP)

Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones. Esto significa que, para conseguir robustez, flexibilidad y posibilitar la reutilización, el código debe depender de abstracciones (interfaces, clases abstractas) y no de implementaciones concretas. Es crucial exponer las dependencias, ya sea por constructor o por parámetros, utilizando estas abstracciones.

El Ciclo de Vida del Desarrollo de Software y el Uso de Prototipos

¿Qué es un Prototipo en el Desarrollo de Software?

Un prototipo es una versión inicial de un sistema, en la que se han incorporado solo algunas características del sistema final, o estas no se han implementado completamente. Se construye para comprender mejor el problema y sus posibles soluciones, permitiendo una validación temprana.

Momentos y Usos Clave de los Prototipos

Los prototipos se utilizan en un proceso de desarrollo para:

• Validar requerimientos, especificarlos o comprenderlos mejor.
• Probar funcionalidades o nuevas técnicas/tecnologías a implementar.
• Validar el diseño de la interfaz de usuario (UI) y la experiencia de usuario (UX).

Razones para Emplear Prototipos

Las principales razones para emplear prototipos en el desarrollo de software son:

• Aumentar la productividad del equipo de desarrollo al clarificar objetivos.
• Mejorar la planificación del desarrollo al identificar tempranamente posibles problemas.
• Fomentar el entusiasmo y la participación de los usuarios y stakeholders al permitirles interactuar con una versión tangible del sistema.

Ventajas del Prototipado

El uso de prototipos ofrece múltiples ventajas, entre las que destacan:

• Mejorar la especificación de requerimientos al facilitar la comunicación.
• Descubrir requisitos inconsistentes, ambiguos o incompletos de forma temprana.
• Servir como herramienta para capacitar al usuario antes de que el sistema final sea entregado.
• Permitir probar y refinar el sistema con un coste menor antes del desarrollo completo.