¿Que es la ortogonalidad en el software?.

por Publicado el

La ortogonalidad en el software es un concepto que leí por primera vez en el libro The Pragmatic Programmer. El concepto no es nuevo, y otros autores le han dado otros nombres. El libro dice lo siguiente:

«Ortoghogonality» is a term borrowed from geometry. Two lines are orthogonal if they meet at right angles, such as the axes on a graph. In vector terms. the two lines are independent. Move along one of the lines, and your position projected onto the other doesn’t change.

In computing, the term has come to signify a kind of independence or decoupling. Two or more things are orthogonal if changes on one do not affect any of the others.

Lo que los autores explican en el segundo párrafo es que dos objetos son ortogonales o tienen ortogonalidad, si y solo si un cambio en un componente no produce afectaciones a otro componente del sistema. El software es entrópico por naturaleza, esto significa que un cambio simple en un componente puede producir una salida compleja en el sistema entero.

Es imposible remover la complejidad totalmente en un sistema.

Lidiar con la complejidad es tu trabajo de día a día como programador o programadora. No vas a poder mantener un sistema con ninguna complejidad, no importa el tamaño ni el número de personas que trabajen en él. El índice de complejidad jamás va a llegar a ser cero.

Este mismo escenario lo vive un arquitecto o ingeniero civil. Todos los edificios  y construcciones son sistemas que están en lucha constante en contra de la complejidad, o el peso. Es imposible hacer un edificio con peso cero, y aun optimizando todo y reduciendo cosas, el edificio mismo tiene que ser capaz de poder sostener su propio peso.  Los diseñadores de las construcciones son capaces de decidir en que puntos de su sistema va a haber ortogonalidad, por ejemplo: los muros falsos, la instalación del aire acondicionado o la electricidad son subsistemas ortogonales, ya que un cambio en estos no afecta la estructura del edificio mismo. En cambio, las estructuras que soportan el peso, los cimientos y los muros de carga no son subsistemas ortogonales, si algo cambia habrá consecuencias directas y notables (intenta remover un muro de  carga y ve que pasa).

Complejidad intencional versus complejidad accidental.

Es muy difícil tener un sistema  con componentes cien por ciento ortogonales, en algunos puntos de tus diseños va a ser imposible no tener componentes que afecten a otros sin querer. Y aun anticipándote a todo es posible que ocurran afectaciones dentro de tu aplicación o con aplicaciones vecinas que no esperabas. Esto no quiere decir que debes de dejar que la complejidad crezca a sus anchas sin ninguna supervisión de tu parte. Todo lo contrario, debes de ser tu el que diseñe la complejidad, vas a decidir como y cuando un componente debe interactuar con otros. También, debes agrupar tus clases y objetos de acuerdo a su razón de cambio y su razón de fallo. No dejes la importante tarea de diseñar el flujo en complejidad de tu sistema al azar.

Ortogonalidad y SOLID.

SOLID es un conjunto de 5 buenas prácticas en el diseño y construcción de programas que te ayudan a reducir la complejidad y dependencia de tus componentes. En principio, con SOLID puedes construir componentes ortogonales o al menos reducir el nivel de complejidad accidental. Te conviene darle una revisión si buscas mejorar la calidad de la construcción de tus sistemas. Con SOLID lo que se busca es reducir a los componentes a una sola responsabilidad, una sola razón de fallo y una sola razón de cambio. Claro, hay escenarios donde la responsabilidad de un componente es  la suma de las responsabilidades de otros; aun así, los principios de SOLID siguen funcionando. No son reglas ciegas que debes seguir sin preguntar, son auxiliares en la toma de decisión, tus tomas de decisiones como programador o programadora.

Autor imagen: H. Michael Miley

Gustavo Sánchez
Últimas entradas de Gustavo Sánchez (ver todo)

Publicado por Gustavo Sánchez

Soy especialista en escribir software de calidad. Mediante el uso de marcos de trabajo, técnicas y automatización de procesos he podido reducir los costes operativos de los sistemas de la empresa. Sistemas confiables y adaptables producen clientes felices.