Ortogonalidad en ingeniería de software

Ortogonalidad

En ingeniería de software, un sistema se considera ortogonal si cambiar uno de sus componentes cambia el estado de ese componente solamente.

Por ejemplo, considere un programa con tres variables: a, by c. Cambiar el valor de a no debería cambiar el valor de bo c, siempre que sean independientes.

Esta propiedad es particularmente crítica en la depuración de un programa, ya que uno se basa en reducir el número de partes móviles de un programa para identificar la causa raíz del problema.

Consulte la siguiente cita de "El arte de la programación UNIX" de Eric S. Raymond:

La ortogonalidad es una de las propiedades más importantes que puede ayudar a que incluso los diseños complejos sean compactos. En un diseño puramente ortogonal, las operaciones no tienen efectos secundarios; cada acción (ya sea una llamada a la API, una invocación de macro o una operación de lenguaje) cambia solo una cosa sin afectar a otras. Existe una y solo una forma de cambiar cada propiedad de cualquier sistema que esté controlando.

La ortogonalidad es un principio de diseño de software para escribir componentes de manera que cambiar un componente no afecte a otros componentes. Es la combinación de otros dos principios, a saber, una fuerte cohesión y un acoplamiento flexible.

En realidad, es un término tomado de las matemáticas. Por ejemplo, dos líneas son ortogonales si son perpendiculares. En el diseño de software, dos componentes son ortogonales si un cambio en uno no afecta al otro.

Aplicar este concepto a clases u otras secciones de código resulta en menos acoplamiento. Para ser ortogonales, dos clases no pueden depender de la implementación de la otra. Tampoco pueden compartir datos globales. Cambiar los componentes internos de una clase no afecta a la otra clase. Los componentes deben ser independientes y tener una sola responsabilidad.

Considere un método que lee una lista de números de un archivo y los devuelve en orden. Ahora los requisitos cambian y los números están en una base de datos. Modificar este método para acceder a la base de datos provocaría cambios en el código del cliente. Si estos fueran dos métodos diferentes, una nueva fuente no afectaría el método de clasificación. Solo el código del cliente debería conocer la fuente de los números.

Cohesión fuerte

Dentro de un componente de software, el código debe estar fuertemente conectado. Esta es una indicación de que el código está dividido correctamente.

Si un componente tiene dos o más partes relativamente desconectadas, eso puede indicar que esas partes deberían estar en un componente diferente o por sí mismas.

Bajo acoplamiento

Entre los componentes del software, debería haber pocas conexiones. Si dos componentes están fuertemente acoplados, puede indicar que deben ser un solo componente o que deben dividirse de manera diferente en más componentes.