Principios SOLID

Los principios SOLID fueron diseñados para solucionar problemas de la programación orientada a objetos y permitir el desarrollo de código que pueda satisfacer los requerimientos presentes, así como también la implementación de requerimientos futuros sin mayor traumatismo. El paradigma de la programación orientada a objetos permite abstraer objetos del mundo real en código, es por esto, que los principios se aplican a este paradigma.

S: Single Responsibility

Nos permite definir una responsabilidad a una clase, entre más responsabilidades tenga una clase, mayor va a ser el impacto al momento de agregar nuevos requerimientos, por lo cual es recomendable mantener responsabilidades únicas. Un ejemplo es la integración con redes sociales, si de repente, la interacción realizada con la red social cambia debido a las políticas de la misma, se debería tener una clase encargada únicamente de la interacción para que al momento de presentarse esto, los cambios que se deban realizar no se extiendan y puedan dañar otras partes del programa.

O: Open-Closed

Nos indica que el código debe estar abierto a extensiones y cerrado a modificaciones. Un ejemplo de como lograr esto son las figuras geométricas como circulo, cuadrado, rectángulo, triangulo, etc., en donde todas tienen perímetro, área, posición, alto, ancho, entre otras propiedades, en este caso es recomendable tener una clase o interfaz “figura”, que tenga las propiedades y a partir de esta crear nuevas figuras geométricas con sus especificidades.

L: Liskov Substitution

Indica que una clase hija puede ser reemplazada por una clase padre sin afectar el funcionamiento del programa. Un ejemplo de cómo no se cumpliría esto es el nombrado anteriormente, digamos que tenemos dos clases rectángulo y cuadrado, un cuadrado es en teoría un rectángulo con alto y anchos iguales, entonces al invocar propiedades como setAlto y setAncho, en un rectángulo se estarían modificando propiedades distintas, mientras que con un cuadrado, se modificaría la misma propiedad, lo que indica que la implementación de una interfaz seria mas apropiada.

I: interface Segregation

Indica como las interfaces deben ser específicas, es decir, es mejor tener múltiples interfaces pequeñas, en lugar de una interfaz grande, pues esto podría llevar a que se deban implementar métodos innecesarios para la clase.

D: Dependency Inversion

Propone depender de abstracciones y no de elementos concretos, digamos que nuestro sistema brinda al usuario la posibilidad de iniciar sesión con alguna plataforma como Twitter, si más adelante se quisiera cambiar el método de inicio de sesión por el de Facebook, se debería modificar la clase en donde se está haciendo el login, si por otro lado, tenemos abstracciones de módulos de login y la clase que hace el login solo invoca los métodos que se brindan en el módulo, se podría brindar la posibilidad de que la clase use cualquier modulo de login que se le asigne y se podrían crear o modificar los módulos de login de forma independiente sin alterar la funcionalidad inicial.

El proyecto se encuentra en: https://bitbucket.org/JCSOne01/solid/src