Programación Orientada a Objetos: Principios

Este Post es la última parte de la serie “Programación Orientada a Objetos”. Esta serie tiene como objetivo establecer los fundamentos de la POO, utilizando Java como ejemplo. Los temas de esta serie son los siguientes:

1. Definición de POO
2. Clases y Objetos
3. Herencia
4. Abstracción
5. Encapsulamiento
6. Polimorfismo
7. Composición
8. Principios utilizados en la POO

Todo el código de la serie está disponible en GitHub.

Todos los ejemplos están hechos en Netbeans.

---

Vamos a presentar varios principios que se deben de cumplir al momento de diseñar programas orientados a objetos. Definiciones son sacadas de Wikipedia.

Principio de responsabilidad única

El principio de responsabilidad única establece que cada clase debe tener responsabilidad sobre una única parte de la funcionalidad el programa completo. Esta única responsabilidad debe de estar encapsulada dentro de una misma clase.

Al llevar a cabo este principio, cualquier cambio en una parte específica del programa, solamente tendría que afectar a esa parte del programa, en otras palabras a una sola clase. Si no se separan las responsabilidades de una manera adecuada, la mantenibilidad y extensión del programa podrían hacerse mucho más complicadas.

Principio abierto-cerrado

El principio de abierto/cerrado establece que “una entidad de software (clase, módulo, función, etc.) debe quedarse abierta para su extensión, pero cerrada para su modificación”. En otras palabras, se puede agregar funcionalidad nueva, pero no se debería de modificar lo que ya está hecho para no tener que cambiar los objetos que usen la clase modificada.

Este principio se puede cumplir utilizando interfaces, ya que se pueden tener diferentes implementaciones de las mismas interfaces, y se pueden sustituir unas por otras, pero los métodos que implementan las interfaces siempre permanecerían iguales. Se puede cambiar completamente la implementación de cierta parte del programa, pero los objetos que usan esas clases modificadas no se darían cuenta, ya que la interfaz seguiría siendo la misma.

Composición sobre herencia

Como vimos, es preferible implementar composición que implementar herencia. Se pueden agregar los objetos que sean necesarios a nuestras clases, creando varias relaciones del tipo “tiene un objeto del tipo X”. También se puede utilizar la delegación para pasar la responsabilidad de ejecutar ciertas cosas a otros objetos.

DRY - No te repitas

Don’t Repeat Yourself. Cada pieza de conocimiento debe tener una única representación en el sistema. Con esto podemos evitar que nuestro programa tenga el mismo código repetido en varios lugares. Esto lleva a tener un código más limpio, más ordenado, de más fácil mantenibilidad y además es más sencillo de encontrar problemas y arreglarlos.

Separación de intereses

Este principio de diseño establece que un sistema debe de separarse en secciones, cada sección debe de enfocarse en un interés específico. Un interés es un conjunto de información que afecta el código de tu programa. Se utiliza el encapsulamiento y las interfaces para lograr esto.

Debe de existir un buen diseño en el programa con separación de intereses. Al enfocar cada sección en un interés en particular, sabemos dónde encontrar el código que necesitamos, además de que secciones individuales se pueden reutilizar en otras partes del código. De igual manera, si se actualiza una sección, las secciones que la utilicen no deberían de verse afectadas por los cambios realizados.