Como continuación a esta serie, definiremos más conceptos clave en el paradigma de la programación orientada a objetos. Seguimos con dos de los más importantes en el análisis y diseño antes de la implementación de nuestros programas.
El arte de abstraer
En la nota anterior escribí sobre algunos fundamentos del paradigma de la POO. Recordemos algunos conceptos importantes: el objeto (las entidades que nos interesan), la clase (la especificación de los objetos) y sus características (atributos y métodos). En esta ocasión, quiero abundar un poco más sobre eso que escribí y llamé abstracción de entidades. Comencemos por definir tan elegante palabra, abstracción:
Con ayuda de su infinitivo abstraer que, según el diccionario de la RAE, significa:
- Separar por medio de una operación intelectual un rasgo o una cualidad de algo para analizarlos aisladamente o considerarlos en su pura esencia o noción.
Pensemos en un aislamiento a un nivel adecuado de importancia para nosotros; según el contexto, este podría ser desde el nivel de un pequeño escenario, como todo lo que ocurre en una biblioteca o lo referente a una historia que quisiéramos contar, hasta el nivel de nuestra realidad misma (por si alguien gusta de filosofar). De este nivel, lo que nos interesa separar para analizar y considerarlo en su pura esencia son los participantes, los objetos. Así, dejando detrás todo lo demás en nuestro nivel, podemos describir esas entidades que tienen un papel importante en lo que queremos modelar orientándonos a objetos.
Pues bien, apartando y describiendo cada entidad de nuestro interés, vamos realizando la abstracción necesaria para tener nuestros preciados objetos. Notemos que la abstracción es recursiva; primero identificamos y aislamos las entidades para analizarlas, después aislamos sus características más importantes para analizarlas también, como adentrándonos cada vez más en algo grande y estudiándolo por partes para ir refinando nuestro entendimiento hasta un punto necesario. De esta manera iremos creando las descripciones idóneas de esos objetos para nuestro fin.
Secretos necesarios
Otro aspecto importante a considerar, una vez que tenemos la descripción de nuestros objetos, es la organización que les daremos; no redactaríamos nuestras ideas a otros sin antes darles algo de coherencia u organización, no nos daríamos a entender como quisiéramos. A los objetos también hay que organizarlos; delimitar sus componentes (atributos y comportamiento) en clases ayuda mucho a dar una apariencia atómica a cada entidad y obtener unidades independientemente funcionales, pero aún falta algo, algo para lograr una organización entre entidades, falta ocultar detalles que no deberían ser vistos por otros objetos ¿por qué? porque simplemente no necesitan saber cómo hacen los demás objetos lo que hacen, o cómo se encuentran sus atributos (directamente) para funcionar de manera correcta; así como para un niño que mira la televisión no le es necesario saber cómo funciona internamente ese aparato para poder usarlo, los objetos no requieren conocer algunos aspectos internos de otros objetos para interactuar con ellos.
La idea anterior nos lleva a definir un concepto más de los fundamentales en la POO: el encapsulamiento u ocultamiento de la información. Es en la definición de las clases en donde aplicaremos este concepto, lo haremos declarando características de los objetos, ya sean atributos (propiedades) o métodos (comportamiento), como públicas o privadas:
- Públicas cuando estas deban servir como una interfaz de comunicación con otros objetos. Todas las características públicas son visibles para otros objetos, pues si no lo fueran no podría existir tal cosa como la interacción. A menudo suele recomendarse solo declarar públicos algunos métodos, aquellos que pidan o proporcionen información acerca del objeto que los tiene, o que realicen acciones ajenas a la implementación más interna del objeto, por ejemplo: el método “caminar”, en un objeto de la clase Persona puede ser público, sin embargo, un método que defina una parte del algoritmo de cómo hacerlo (mover pie, por mencionar alguno) no debería ser visible para otros objetos; mucho menos lo deberían ser los atributos que son usados en ese algoritmo, no es necesario.
- Privadas cuando se trata de atributos, porque estas partes del objeto son las que deben estar mayormente ocultas; pensémoslo, se trata de datos (variables en un código) que son manipulados por los métodos, perdería toda confiabilidad el hecho de que pudieran ser manipulados también por otros objetos, acabaríamos con la integridad que vinimos haciendo desde la abstracción. También pueden ser privadas cuando se trata de métodos “intermedios”, es decir, que sirven para implementar otros métodos, los cuales finalmente son los presentables (públicos) ante el exterior de la clase. Y por supuesto, también lo serán aquellos métodos que ayuden a definir el buen funcionamiento del objeto, esos que trabajan en lo más profundo de la clase, por ejemplo, en un objeto de la clase Persona, un método de estos últimos podría ser “respirar”.
Buenos objetos, menos trabajo
Una vez que hemos descrito nuestros objetos, desde la abstracción en nuestra mente hasta la obtención de las clases bien definidas, podemos decir que tenemos material para escribir código altamente reutilizable y es que cada clase representa una pieza de software que es independiente y puede ser usada sin problemas en más de un programa, así es, no requiere modificaciones para funcionar en conjunto con un grupo de objetos que con otro, pues en donde quiera que la usemos representa eso que anteriormente hemos modelado. Es una característica muy llamativa, ¿verdad? es seguro que pensamos en que no escribiremos tanto código de esta manera, muy cierto; el trabajo de implementar se reduce mucho, pero hay que trabajar más en el diseño, es por eso que debemos agudizar nuestra capacidad de abstracción y aplicar la idea del encapsulamiento.
Ecelenete axplicacion. Gracias.
Gracias a ti por leernos. Te invito a leer las otras notas de la serie.¡Saludos!