En el post de hoy hablaremos sobre cinco principios básicos de la programación orientada a objetos. A muchos ya os sonarán, sobre todo si ya sois trabajadores/estudiantes experimentados del sector. Si estás empezando a programar con el paradigma orientado a objetos y quieres conocer estos principios que seguro te ayudarán en tu labor, no dudes en seguir leyendo.

Estamos hablando de los conocidos como principios SOLID. Este es un acrónimo enunciado por Robert C. Martin como regla mnemotécnica para recordar los cinco principios. Bien aplicados (y normalmente de la mano de patrones de diseño) nos ayudarán como desarrolladores a producir un código mucho más mantenible. Antes de pasar a enumerar estos principios SOLID y describir cada uno de ellos, es importante tener en cuenta y comprender dos conceptos en los que se apoyan para su desarrollo: cohesión y acoplamiento.

Cohesión y acoplamiento

Estos dos conceptos en el mundo del desarrollo software tienen un nivel alto de abstracción. Nosotros os daremos unas acepciones básicas para estos conceptos, pero tened en cuenta que son amplios, y existen distintos tipos de cohesión y acoplamiento a tener en cuenta a la hora de desarrollar software. En este artículo tenéis una explicación bastante amplia de estos dos conceptos. Para que nosotros nos entendamos, os daremos las dos definiciones más simplificadas de acoplamiento y cohesión:

  • Acoplamiento: Cuando hablamos de acoplamiento entre dos artefactos o unidades software (un método, una librería, un componente…) hablamos de la dependencia entre ellas. Si una unidad depende mucho de otra, diremos que están fuertemente acopladas. Si, de lo contrario, no dependen para nada una de la otra, diremos que están totalmente desacopladas.

  • Cohesión: Cuando hablamos de cohesión, nos estamos refiriendo a cómo se organizan las distintas unidades de software en una unidad de nivel superior, como las clases o funciones en las librerías, métodos y procedimientos en clases…

Cuando desarrollemos software, buscaremos que nuestras unidades tengan una gran cohesión y un bajo acoplamiento.

Principios SOLID

Ahora sí, una vez que tenemos presentes los conceptos de cohesión y acoplamiento, vamos a enumerar y describir los cinco principios que nos ayudarán a mejorar nuestra estrategia de programación.

Single Responsibility (Principio de responsabilidad única)

Este prinicipio enuncia que cada clase debe realizar una única función concreta. A menudo nos encontramos con métodos cuya finalidad no se corresponden con la funcionalidad de la clase, por diversas razones (en el momento del desarrollo solo era un método auxiliar ejecutado en ciertas ocasiones especiales, el método se añadió en esa clase por comodidad…). El problema viene cuando otras clases hacen uso del mismo método. Es en este momento en el que nos debemos plantear la creación de una nueva clase que cargue con esa responsabilidad. Esto evitará la repetición de código en varias clases, aumentará la mantenibilidad del código y ayudará en otras fases del desarrollo (como el testing).

Open/Closed (Principio abierto/cerrado)

Este principio se basa en que las clases deben crearse con “un diseño abierto para poder extenderse pero cerrado para su modificación”. Esto es, crear clases cuya funcionalidad se pueda extender sin necesidad de entrar al código fuente para ampliarla. Para cumplir con este principio el programador debe tener muy claro cómo va a funcionar su programa, cómo se van a comunicar las clases entre sí… para poder saber por dónde se podrá extender funcionalidad y por dónde no. Los mecanismos más utilizados para cumplir este principio son el uso de herencia entre clases y la utilización de interfaces.

Es complicado predecir al 100% por dónde y por dónde no se podrá ampliar la funcionalidad de las clases, por lo que es posible que aún intentando cumplir con este principio en un momento dado del desarrollo tengamos que refactorizar el código para aumentar la funcionalidad de una determinada clase.

Liskov Substitution (Principio de Sustitución de Liskov)

Este principio fue enunciado por Barbara Liskov y habla de la importancia de la concordancia entre las clases base y las clases derivadas de estas. Esta importancia radica en evitar la reimplementación de métodos que provoquen que métodos de la clase base tengan un comportamiento diferente al que tendrían si fuesen invocados por un objeto de la clase base.

Interface Segregation (Segregación de Interfaces)

Este principio es similar al de responsabilidad única, pero centrado en el desarrollo de interfaces. Lo que viene a decirnos este principio es que cuando definamos interfaces, estas deben ser específicas e incluir los métodos abstractos necesarios para que las clases realicen una función concreta (es preferible tener muchas interfaces y que sus métodos engloben una única funcionalidad a una sola interfaz con métodos para realizar varias funciones).

Dependency Inversion (Inversión de dependencias)

Este último principio tiene como objetivo el desacoplamiento de las clases, haciendo uso de abstracciones que permitan que una clase interactúe con otras sin conocerlas directamente (las clases base no deben conocer los detalles de implementación de las clases hijas). Existen distintos patrones de diseño que nos ayudan con esta tarea.

Conclusiones

Como habéis podido ver, la tarea de programar no se basa sólo en lanzar líneas de código que funcionen. Si queremos realizar un desarrollo de calidad y mantenible a largo plazo, debemos cuidar un poco el diseño y desarrollo de nuestra aplicación, de modo que si en un futuro nuestra aplicación debe evolucionar o refactorizarse esta tarea se facilite.

También habréis podido deducir que estos principios de la orientación a objetos van muy de la mano de los patrones de diseño. Este es un tema que trataremos próximamente en Infseg.

Si tienes alguna duda, no dudes en contactar con nosotros. Puedes hacerlo a través de Twitter en @InfsegWeb.

Fuentes