Los principios de diseño y desarrollo de software aquí mencionados y descritos son tomados del siguiente sitio web:
http://joaquin.medina.name/web2008/documentos/informatica/documentacion/logica/OOP/Principios/2012_09_04_PDOOPrincipioDisenyo_Indice.html
Aplicar estos principios nos ayudarán, entre otras cosas, a crear un código que sea más legible, simple, reusable, escalable y mantenible, es decir, nos ayudarán a evitar los problemas con los que nos solemos encontrar a medida que nuestro código va creciendo.
<h1>KISS</h1>El principio KISS (abreviatura del inglés Keep It Short and Simple: «Manténgalo breve y simple») recomienda el desarrollo empleando partes sencillas, comprensibles y con errores de fácil detección y corrección, rechazando lo enrevesado e innecesario en el desarrollo de sistemas complejos en ingeniería.
La abreviatura KISS, también puede interpretarse como «Mantenlo simple, estúpido» (Keep It Simple, Stupid). Para evitar ser tosco, la abreviatura se hace corresponder con otras expresiones tales como «Manténgalo breve y simple» («Keep It Short and Simple») u otras similares, pero que mantienen la misma idea del principio.
<h1>DRY</h1>El principio No te repitas (en inglés Don’t Repeat Yourself o DRY, también conocido como Una vez y sólo una) es una filosofía de definición de procesos que promueve la reducción de la duplicación especialmente en programación. Según este principio toda pieza de información nunca debería ser duplicada debido a que la duplicación incrementa la dificultad en los cambios y evolución posterior, puede perjudicar la claridad y crear un espacio para posibles inconsistencias. Por “pieza de información” podemos entender, en un sentido amplio, desde datos almacenados en una base de datos pasando por el código fuente de un programa de software hasta llegar a información textual o documentación.
Cuando el principio DRY se aplica de forma eficiente los cambios en cualquier parte del proceso requieren cambios en un único lugar. Por el contrario, si algunas partes del proceso están repetidas por varios sitios, los cambios pueden provocar fallos con mayor facilidad si todos los sitios en los que aparece no se encuentran sincronizados.
<h1>SOLID</h1>Son unos principios que deberíamos tener como base antes de proponer una arquitectura de software para el desarrollo de nuestras aplicaciones.
Estos principios nos brindan formas de pasar del código estrechamente acoplado y pobremente encapsulado a los resultados deseados de las necesidades reales de una empresa. Siguiendo SOLID se desarrolla un código que pueda ser escalable en un futuro.
Éste acrónimo tiene estrecha relación con los patrones de diseño, en especial con:
Alta Cohesión:
La información que almacena una clase debe ser coherente, y debe estar, en la medida de lo posible, relacionada con la clase.
Bajo Acoplamiento:
Tener las clases lo menos ligadas entre sí, de tal forma que un cambio tenga la mínima repercusión posible, potenciando la reutilización.
En el siguiente enlace se encuentra una explicación detallada de los principios SOLID con TypeScript:
https://samueleresca.net/2016/08/solid-principles-using-typescript/
SRP dice“Cada módulo de software debe tener una sóla razón para cambiar”.
El principio Abierto/Cerrado dice “Un módulo/clase de software está abierto para extensión y cerrado para modificación”. Si queremos añadir nuevo código, lo ideal sería poder construir sobre lo que ya existe, sin tener que hacer modificaciones grandes.
LSP establece que “Debería poder utilizar cualquier clase derivada en lugar de una clase principal y hacer que se comporte de la misma manera sin modificaciones”. Asegura que una clase derivada no afecte el comportamiento de la clase principal.
ISP establece que “Los clientes no deben ser forzados a implementar interfaces que no usan. En lugar de una sóla interfaz, se prefieren muchas interfaces pequeñas basadas en grupos de métodos, cada uno de los cuales sirve a un submódulo”.
Una interfaz debe estar más relacionada con el código que la usa que con el código que la implementa.
Éste principio tiene dos ideas importantes de fondo:
a) Los módulos de alto nivel no deberían depender de módulos de bajo nivel, sino de abstracciones.
b) Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones.
Excelente tu aporte, de mucha ayuda!!