SOLID es un acrónimo que representa los cincos principios básicos del diseño y la programación orientada a objetos. Estos principios fueron identificados a principios del año 2000 por Robert C. Martin (popularmente conocido como Uncle Bob). Uncle Bob identificó estos cinco principios, algunos de ellos ya existentes y expuso que estos deberían ser los principales principios a tener en cuenta en el momento de desarrollar software utilizando el paradigma de la orientación a objetos. Sin embargo, en un primero momento aún no eran conocidos como SOLID hasta que Michael Feathers se percató de que las iniciales de estos principios encajaban perfectamente bajo el acrónimo de SOLID y que además era un nombre muy representativo para su definición.

Estos principios no son leyes o reglas inalterables que se tengan que cumplir, pero si son una serie de recomendaciones prácticas que de ser aplicadas en su conjunto ayudan a nuestro software a obtener los siguiente beneficios:

  • Facilidad en el mantenimiento.
  • Facilidad para hacer testing.
  • Rapidez para de extender funcionalidades.
  • Buena refactorización.
  • Tolerancia frente a errores.

Antes de desglosar las letras de SOLID y ver que nos dice cada principio, tenemos que repasar dos conceptos importantes en el desarrollo de cualquier software, que son el acoplamiento y la cohesión.

Acoplamiento: En desarrollo de software se define como el grado en que un módulo, clase, método o cualquier otra entidad de software, está directamente vinculada a las demás. Este grado de acoplamiento también puede ser visto como un grado de dependencia. Por ejemplo, cuando se quiere utilizar una clase que esté estrechamente unida (tiene un alto acoplamiento) a una o más clases, acabaremos utilizando o modificando parte de estas clases de las cuales somos dependientes.

Cohesión: La cohesión es la medida en que se relacionan dos o más partes de un sistema y cómo trabajan en conjunto para lograr mejores objetivos que las partes individuales.

Para lograr un buen desarrollo debemos buscar siempre un bajo acoplamiento y una alta cohesión y los principios SOLID vienen al rescate para ayudarnos con esta tarea.

Pasemos a ver cada uno de estos:

Single Responsibility: una clase, modulo, método, etc, debe tener una y solo una razón para cambiar. Esto significa que una entidad de software debe tener solo una responsabilidad y hacer únicamente la tarea para la cual ha sido diseñada. De lo contrario si asume más de una responsabilidad existirá un alto acoplamiento provocando que nuestra lógica de programación sea frágil ante cualquier cambio.

Open / Closed: las entidades de software deben estar abiertas para su extensión, pero cerradas para su modificación. Esto significa que una entidad de software debe ser fácilmente extensible sin necesidad de modificar su código existente. Si diseñamos sistemas extensibles serán menos propensos a errores ante cambios en los requerimientos. Podemos recurrir a la herencia para que nos ayude a la hora de aplicar este principio.

Liskov substitution: este principio fue elaborado por Barbara Liskov y viene a decir que los objetos deben ser reemplazables por instancias de sus subtipos sin alterar el correcto funcionamiento del sistema. Por ejemplo, si tenemos una clase “Coche” que tiene un método “arrancarMotor” y también tenemos una clase “Deportivo” que extiende de “Coche”, podemos sustituir las referencias de “Coche” por referencias de “Deportivo”. Aplicando este principio conseguimos validar que nuestras abstracciones sean correctas.

Interface segregation: tener interfaces específicas es mejor que tener una interfaz de propósito general. Este principio nos dice que nunca debemos implementar una interfaz que no vayamos a necesitar. Incumplir este principio conlleva que en nuestras implementaciones tengamos dependencias de métodos que no necesitamos pero nos vemos obligados a definir. Por lo tanto una interfaz la define el cliente que la consume, y no debe tener métodos que este no vaya a implementar.

Dependency inversion: se debe depender de abstracciones, y no de implementaciones (concreciones). Significa que una clase concreta, no debe depender directamente de otra clase sino de una abstracción (interfaz) de esta. Aplicar este principio nos ayuda a reducir la dependencia en implementaciones específicas y así lograr que el código sea más reutilizable. No hay que confundir este principio con la “inyección de dependencias” que es una técnica que nos ayuda a la hora de aplicar este principio y conseguir que las colaboraciones entre clases no conlleven dependencias entre ellas.

En definitiva, seguir los principios SOLID se convierte en una parte esencial en nuestros desarrollos si queremos construir software de calidad que sea modificable, escalable y fácil de testear.

Arthur AntunesArthur Antunes

Leave a Reply

Your email address will not be published. Required fields are marked *