Reglas para crear software simple y robusto

Se considera que una aplicación software es robusta cuando puede seguir funcionando en condiciones adversas e impredecibles.

A la hora de crear un software robusto una de sus primeras reglas es hazlo simple. Desde su código, escribiendo limpio y legible, hasta su arquitectura utilizando patrones de diseño. Todo esto nos lleva a seguir un estilo de diseño simple a la hora de definir nuestro proyecto software.

La navaja de Ockham

La simplicidad en el software mejora nuestro proyecto en su ejecución y en su mantenimiento. Gracias a que su código es simple de leer podemos entender mejor su estructura y su funcionalidad y gracias a que la relación entre módulos, clases y funciones es simple la detección de errores o la incorporación de nuevas características es menos estresante.

Muchas ramas de la ingeniería buscan esta simplicidad debido a la idea del principio de economía o el principio de la navaja de Ockham.

Este principio dice que en igualdad de condiciones, la explicación más simple suele ser la más probable». Esto implica que, cuando dos teorías en igualdad de condiciones tienen las mismas consecuencias, la teoría más simple tiene más probabilidades de ser correcta que la compleja.

Las cinco reglas para mantener la simplicidad

Con la evolución y la historia de la creación de software han ido apareciendo una serie de reglas que nos ayudan a mantener la simplicidad dentro del diseño de nuestro software. En futuros artículos iremos viendo cada una de estas cinco reglas.

Qué son los patrones de diseño en la industria del software

Los patrones de diseño son soluciones habituales a problemas que aparecen durante el diseño de un producto software.

Un patrón no es una pieza de código, sino un concepto general para resolver un problema concreto.  El patrón de diseño ayuda con ciertas instrucciones a implementar una solución que se adapte a las necesidades del programa que se esté creando..

Patrones y algoritmos

No se deben confundir los conceptos de algoritmo y patrón de diseño. El algoritmo es una receta para solucionar un problema muy concreto y el patrón de diseño es un plano arquitectónico para indicar cómo repartir las funciones, clases y objetos en nuestro programa.

Descripción de un patrón de diseño

La descripción de un patrón de diseño es un texto formal que permite la implementación del patrón en múltiples entornos y contextos.

Esta descripción del patrón incluye elementos como propósito, motivación, estructura de clases, aplicabilidad, pasos de implementación y ejemplo de código.

Clasificación

Los patrones de diseño se diferencian en su complejidad, nivel de detalle y escala de aplicabilidad.

Los patrones más básicos se denominan idioms y suelen aplicarse a un lenguaje de programación específico.

Los patrones más complejos y de alto nivel se denominan patrones de arquitectura y son aplicables a casi cualquier lenguaje de programación. Estos patrones ayudan al diseño global de la aplicación definiendo la arquitectura del proyecto software.

Clasificación por propósito

Los patrones de diseño se pueden clasificar también por el tipo de propósito que tenga el patrón de diseño.

Patrones de construcción

Estos patrones proporcionan mecanismos y enfoques para la creación de objetos buscando mejorar la reutilización de código y su flexibilidad.

Patrones de estructura

Estos patrones ofrecen soluciones para ensamblar y relacionar objetos para crear estructuras más grandes y maximizar su eficiencia y flexibilidad.

Patrones de comportamiento

Estos patrones ofrecen mecanismos para mejorar la comunicación entre objetos y definir las responsabilidades entre clases y objetos.

El polimorfismo dentro de la programación orientada a objetos

El polimorfismo permite que una clase hija modifique el comportamiento de un método de la superclase.

Ejemplo con la música

Queremos realizar una aplicación que haga sonar varios instrumentos musicales a la vez para interpretar una composición musical.

Como podemos modelar nuestra orquesta de la forma que prefiramos podemos crear una clase DirectorDeOrquesta que dará órdenes a un listado de instrumentos musicales. De esta forma nuestro director de orquesta puede dar órdenes a una orquesta que tenga un tamaño indeterminado.

Para conseguir esto cada instrumento musical debe responder a una órden específica del director de orquesta. Esta órden puede estar representada por una llamada al método tocar de cada instrumento musical.

Nuestra clase directorDeOrquesta sería algo como:

Clase Director

    atributos: listaDeInstrumentos

    Métodos: tocarLista

Imaginemos que tenemos la clase InstrumentoMusical y la declaramos así:

Clase InstrumentoMusical

    Atributos: nombre, tipo

    Métodos: tocar

Esta clase al ejecutar el método tocar mostrará un mensaje por pantalla.

Veamos la definición de la clase InstrumentoMusical con más detalle:

Clase InstrumentoMusical

    nombre, tipo



    función tocar() {

        imprime("El instrumento suena")

    }

Ahora imaginemos que queremos declarar las clases Flauta y la clase tambor. La declaración quedaría así:

Clase Flauta que hereda de InstrumentoMusical

    función tocar() {

        imprime("Piiiiiiii")

    }



Clase Tambor que hereda de InstrumentoMusical

    función tocar() {

        imprime("Bum")

    }

De esta forma las clases hijas tienen comportamientos personalizados para el método tocar que ha sido heredado de su clase padre.

El polimorfismo es la capacidad de un programa de detectar la verdadera clase de un objeto e invocar su implementación, incluso aunque su tipo real sea desconocido en el contexto actual.
También se puede pensar en el polimorfismo como la capacidad de un objeto para “fingir” ser otro objeto,

La herencia dentro de la programación orientada a objetos

La herencia es la capacidad de crear nuevas clases a partir de otras clases anteriores.

La principal ventaja de la herencia es la reutilización de código.

Si se quiere crear una clase ligeramente diferente a una ya existente, no es necesario duplicar el código. En su lugar, se amplía la clase existente y se coloca la funcionalidad adicional dentro de una subclase resultante que hereda los campos y métodos de la superclase.
Una de las consecuencias del uso de la herencia es que las subclases tienen la misma interfaz que su clase padre. No se puede esconder un método en una subclase si este mismo método se declaró en la superclase de forma pública.

Las interfaces de clase dentro de la programación orientada a objetos

Ahora que conocemos los conceptos de abstracción y encapsulación podemos hablar de las interfaces de clase dentro de la programación orientada a objetos.

La interfaz de una clase es un listado de métodos que, en el caso de tratarse de una interfaz pública, estos métodos son conocidos por los objetos alrededor de nuestra clase.

Las interfaces y la forma de modelar las clases y métodos abstractos en la mayoría de los lenguajes de programación se basan en conceptos de abstracción y encapsulación.

En los lenguajes modernos de programación orientada a objetos, el mecanismo de la interfaz (declarado normalmente con la palabra clave interface o protocol) permite definir contratos de interacción entre objetos. Esto recalca el interés de reflejar en las interfaces sólo los métodos y no los atributos por esta razón hay muchos lenguajes de programación orientada a objetos que no permiten la declaración de atributos en las interfaces de clase.

Una clase puede tener una interfaz pública, otra interfaz privada y otra interfaz protegida dependiendo de cómo se declaren los distintos métodos de la clase. De esta forma los métodos de la clase estarán disponibles a distintos niveles de complejidad.

La encapsulación dentro de la programación orientada a objetos

Para encender una televisión sólo tienes que pulsar el botón de encendido, los detalles de la alimentación eléctrica, el arranque del sistema software de la televisión, la decodificación de la señal de la televisión o la distribución de los cables y circuitos que componen el aparato de televisión permanecen ocultos para los usuarios bajo la carcasa de la televisión. El usuario sólo tiene que saber cuál es el botón de encendido, los botones para cambiar de canal y los botones para modificar el nivel de volumen brillo y otros detalles simples de configuración.

El hecho de ocultar el comportamiento y atributos internos de una clase con el objetivo de simplificar la interfaz ofrecida a otros objetos se denomina encapsulación ya que lo que estamos haciendo es ocultar en cápsulas elementos que resultan innecesarios a objetos de fuera de nuestra clase.

Este ejemplo ilustra cómo funciona una interfaz pública de una clase. A otros objetos se les ofrece un conjunto de métodos y atributos pero no se les deja ver cómo se trata esa información o si hay más métodos internos. A los objetos que trabajan con nuestra clase sólo les interesa los resultados que se pueden obtener de los atributos y métodos públicos.

La encapsulación es la capacidad de un objeto para ocultar partes de su estado y comportamiento de otros objetos, exponiendo únicamente una interfaz limitada al resto del programa.
Encapsular algo significa hacerlo privado y, por ello, disponible únicamente dentro de los métodos de su propia clase.

Existe el modelo protegido que resulta un poco menos restrictivo que el modelo de la encapsulación. En el modelo protegido los métodos de una clase están también disponibles para las clases hijas.