Los cinco principios de diseño de software SOLID fueron reunidos por Robert Martin (@unclebobmartin) a partir de varias ideas y papers pre-existentes en la comunidad. En estos artículos los revisaremos uno a uno con la interpretación desde mi experiencia con ellos y cómo han afectado mi forma de programar.

Todos los principios los puedes ver en el índice: http://www.davidlaym.com/2015/05/solid-resumen-de-los-principios

Principio Abierto – Cerrado

La O de SOLID es por “Open Closed Principle”, que se puede traducir como “Principio Abierto – Cerrado”. Es un concepto sencillo de describir pero muy poderoso en cuanto a lo que puede hacer por el diseño de nuestro software.

La explicación original indica: “Una entidad de software (clases, módulos, funciones, etc) deben estar abiertos para extensión, pero cerrados para modificación.

Abierto para extensión significa que el comportamiento de la entidad puede ser modificado a medida que los requerimientos evolucionan.

Cerrado para modificación, significa que los cambios en comportamiento anteriormente descritos, no afectan el código fuente o binario de la entidad en cuestión.

Esto parece realmente imposible. ¡Magia negra! Nah, nada de eso, la clave está, como siempre, en la abstracción.

Puede ser tan simple como tener un comportamiento abstraido en una clase base y realizar una herencia para sobre-escribir o complementar el comportamiento. Puede ser una clase base abstracta que define métodos abstractos (virtuales) que deben ser implementados por sus herederos. También puede ser una implementación del patrón estrategia.

Todas estas formas permiten generar una forma de desacoplar el comportamiento de la estructura, dejando nuestros diseños cerrados para modificación, pero abiertos a extensión.

Sobre el diseño anticipado

Robert Martin nos advierte a no crear diseños excesivamente complejos desde el primer instante, ya que eso es anti-productivo y en general, una muy mala idea. Lo que realmente resulta, es en la primera implementación, crear nuestro código cerrado para extensión (sin herencias ni interfaces o patrones). Cuando llegue el primer cambio, en vez de cambiar directamente lo que nos piden, creamos la estructura necesaria para que nuestro código en el futuro permita una extensión en ese tipo de cambio. Es lo que Robert llama “recibir la primera bala”.