Table of Contents
Hoy, me gustaría hablar de principios SOLID, los 5 principios básicos de la programación orientada a objetos que aquí en Apiumhub creemos esencial para construir software que funciona. En caso de que no lo supieses, en la programación, el acrónimo de los principios SOLID fue introducido por Michael Feathers por los 5 principios definidos por Robert C. Martin al principio de los 2000.
Como ya sabes, para conseguir software que funciona debemos tener una baja compilación, alta cohesión y una fuerte encapsulación, que es algo que los principios SOLID nos ayudan a obtener. La idea es que, aplicando estos principios, se es capaz de escribir un código de mayor calidad, el sistema creado es fácil de mantener, reusar, y extender en el tiempo. Básicamente, los principios SOLID ayudan a los desarrolladores de software a conseguir escalabilidad y evitar que tu codigo se rompa cada vez que aparece un cambio.
Ok, entonces empecemos por lo básico, principios SOLID significan:
S (SRP) – Principio de responsabilidad única (Single responsibility principle)
O (OCP) – Principio de abierto/cerrado (Open/closed principle)
L (LSP) – Principio de sustitución de Liskov (Liskov substitution principle)
I (ISP) – Principio de segregación de la interfaz (Interface segregation principle)
D (DIP) – Principio de inversión de la dependencia (Dependency inversion principle)
Echemos un vistazo a cada principio individualmente para entender porque SOLID puede ayudar a los desarrolladores a construir software de calidad.
Principios SOLID
1. Principio de responsabilidad unica
“Nunca debería haber mas de una razón en una clase para cambiar”
Como puedes observar, este principio dice que un objeto/clase debería únicamente tener una responsabilidad completamente encapsulada por la clase. Aquí, cuando hablamos de responsabilidad, nos referimos a una razón para cambiar. Este principio nos dirige hacia una cohesión más fuerte en la clase y un encaje más flojo entre la dependencia de clases, una mayor facilidad de lectura y un código con una complejidad menor.
Es mucho más difícil entender y editar una clase cuando tiene más de una responsabilidad. Por lo que si tenemos más de una razón para cambiar, la funcionalidad se divide entre dos clases y cada una se encargará de su responsabilidad.
Pensamos en separar las funcionalidades ya que cada una de ellas es un acceso al cambio. Cuando una clase tiene más de una responsabilidad, se acoplan y ello hace que el codigo base sea frágil. Lo que dificulta refactorizar cuando se requiere.
Si te interesa saber mas sobre los principios SRP, aquí hay un post que te encantará leer.
2. Principio abierto-cerrado
“Entidades de Software (classes, módulos, funciones, etc.) han de estar abiertas para extensiones, pero cerradas para modificaciones”
Aquí la idea es que una entidad permite que comportamiento se extienda pero nunca modificando el código de fuente. Cualquier clase (o cualquier cosa que escribas) debe de estar escrito de un manera que puede utilizarse por lo que es. Puede ser extensible, si se necesita, pero nunca modificado. Puedes tener esto en cuenta cuando escribas tus clases. Utiliza las clases de la manera que necesites, pero para modificar su comportamiento aparece cuando añades un código nuevo, nunca cuando lo modificas el viejo. El mismo principio puede aplicarse para módulos, paquetes y librerías.
Aplicando el principio de abierto-cerrado conseguiras un acople más relajado, mejoraras la lectura y finalmente, reducirás el riesgo de romper alguna funcionalidad ya existente.
3. Principio de sustitución de Liskov
“Subtypes deben ser sustituidos por su tipo de base”
Como su nombre indica, este principio fue definido por Barbara Liskov. La idea aquí es que los objetos deberían ser reemplazados por ejemplos de su subtipo, y ello sin que la funcionalidad del sistema desde el punto de vista de los clientes se vea afectada. Básicamente, en vez de utilizar la implementación actual, deberías ser capaz de utilizar una clase base y obtener el resultado esperado. A menudo, cuando queremos representar un objeto, modulamos nuestra clase de bases en sus propiedades y en vez de eso, deberíamos poner más énfasis en su comportamiento.
Este principio básicamente confirma que nuestras abstracciones están conectadas y nos ayudan a conseguir un código que es fácil de reutilizar y una jerarquía de clases fáciles de entender.
Lo que muchos dicen es que este principio de Liskov tiene una fuerte relación que los anteriores, (open-close). Robert c Martin incluso dice que “una violación de LSP es una violación latente de OCP”.
4. Principio de segregación de la interfaz
“Classes implementan interfaces, no deberían ser forzadas a implementar los métodos no utilizados”
Aquí, se basa en cómo escribir interfaces. Entonces, qué significa? Básicamente, una vez la interfaz se convierte en larga, se necesita absolutamente de separarla en pequeñas partes más específicas. Una interfaz será definida por el cliente que lo utilice, lo que significa que el sera el unico que tenga conocimientos de los métodos relacionados con ellos.
En realidad, si añades métodos que no deberían estar ahí, las clases implementando la interfaz deberá implementar los métodos también. Esa es la razón, los clientes no deberían ser forzados a depender de las interfaces que no darán uso. Con ISP se intenta mantener un sistema desacoplado y así más fácil de refactorizar, cambiar y desplegar.
5. Principio de inversión de la dependencia
“Módulos de altos modelos no deberían depender de niveles de modulos bajos, sino de abstracciones. Abstracciones no deberían depender de detalles; sino los detalles de la abstracción”
Este principio está principalmente basado en reducir las dependencias entre los módulos del código. Básicamente, este principio será de gran ayuda para entender cómo atar correctamente sistemas juntos. Si los detalles de tu implementación dependen de los altos niveles de abstracciones, te ayudará a conseguir un sistema bien acoplado. También, influirá en la encapsulación y cohesión de ese sistema.
Conclusion
Cuando desarrollas cualquier software, hay dos conceptos muy importantes: cohesión (cuando dos partes distintas de un sistema trabajan juntas para tener mejor resultado que ambas partes trabajando de manera individual) y acoplamiento (puede verse como un grado de dependencia en una clase, método o otra entidad de software)
El acople se presenta normalmente en muchos codigos y como he mencionado anteriormente, la situación más óptima sería tener un bajo acoplamiento y alta cohesión. Con esta pequeña introducción a los 5 principios SOLID, has podido ver que nos ayudan a lograrlo.
Hay muchos principios en la ingeniería de software y yo recomendaría que antes de escribir un código, hay que indagar un poco sobre ello, leer e intentar entender sus principios. Aunque pueda parecer mucho, SOLID se convierte en una parte de ti y tu codigo utilizandolo con continuidad y adaptándose a sus guías.
One Comment
Jhon Córdoba
Excelente artículo, perfecto para recordar conceptos tan importantes para una programación de calidad.