Como sabemos la Programación Orientada a Objetos nos ayuda a diseñar software de una forma sencilla, pero,  ¿qué pasa cuando aún usando este enfoque de programación nuestro código se vuelve complejo y difícil de entender?
Esto es lo que SOLID resuelve, siendo una serie de principios o guías de diseño que nos ayudan en la labor de crear programas legibles y mantenibles.

S.O.L.I.D es un acrónimo de los primeros cinco principios de diseño orientado a objetos (OOD) de Robert C. Martin.

Estos principios, hacen que sea fácil para un programador desarrollar software que sea fácil de mantener y ampliar. También facilitan a los desarrolladores refactorizar fácilmente el código y forman parte del desarrollo ágil de software ademas de que favorece una mayor reusabilidad y calidad del código, así como la encapsulación.

Aquí te mostraré en que consiste cada uno de estos utilizando Typescript para ejemplificar cada uno.

S: Single Responsibility Principle


Establece que cada clase debe tener una sola función o tarea a cumplir.
Ejemplo:

Como vemos una misma clase ademas de tener los getters también tiene la función de paginado, así como de imprimir.

Forma correcta:

Se separan las funciones en diferentes clases.

O: Open Closed Principle


Establece que las clases o entidades deberían estar abiertos para su extensión, pero cerrados para su modificación.
Ejemplo:

Notamos que la clase Printer sufriría cambios cada vez que se agreguen más extensiones de archivos, lo que va en contra de este principio.

Forma correcta:

Ahora la clase Printer no necesitaría saber que extensión tiene el documento para poder imprimir.

L: Liskov Substitution Principle


Declara que una subclase debe ser sustituible por su superclase, y si al hacer esto, el programa falla, estaremos violando este principio.

Como vemos, Square sobrescribe la clase Rectangle en los setters, por lo que no cumpliría este principio 

Forma correcta:

Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas, asegurándonos que cuando extendemos una clase no alteramos el comportamiento de la clase padre.

I: Interface Segregation Principle

Este principio define que una clase no debe ser forzada a depender de interfaces (propiedades o métodos) que no usa.

Ejemplo:

Como vemos, Dog hereda el método fly, algo que no es coherente.

Forma correcta:

Ahora cada clase únicamente contiene las propiedades y métodos correspondientes

D: Dependency Inversion Principle


El principio DIP dice que si una clase depende de otras clases, esta relación debería estar en las interfaces.
Ejemplo:

La clase Building tiene que conocer la clase Cement para poder calcular el coste de la construcción

Forma correcta:

Cumple con el principio de inversión de dependencias

Como vemos, estas guías de diseño nos ahorran mucho trabajo. Ademas de que ayuda a obtener código reutilizable y fácil de entender sin mencionar que cada uno es sencillo de implementar de implementar.

Puedes encontrar el código aquí y no olvides darle star al repositorio.