Hace ya décadas que el paradigma de orientación a objetos (OO) tomó su lugar en el desarrollo de software. Sin embargo, a la fecha muchos de nosotros seguimos sin entender o aplicar correctamente los conceptos en los que se basa este paradigma, así que hemos decidido aprovechar este espacio, ya sea para conocerlos, repasarlos o aclararlos.
Los conceptos fundamentales que se deben entender para poder ser buenos desarrolladores OO, son los siguientes: abstracción, encapsulación, identidad, modularidad, jerarquía, tipos, concurrencia y persistencia. Nótese que estos conceptos no son exclusivos de la orientación a objetos, simplemente tienen ciertas particularidades desde esta perspectiva. Veamos cuales son.
Abstracción
El paradigma OO se basa en la noción de representar elementos del mundo real como objetos. Sin embargo, cualquier elemento del mundo real tiene una cantidad interminable de propiedades y comportamiento. Para lidiar con esta complejidad, utilizamos la abstracción. La abstracción es el mecanismo a través del cual nos enfocamos en los aspectos esenciales o distintivos de algo, ignorando detalles irrelevantes. Obviamente, la abstracción siempre se hace desde alguna perspectiva particular, porque, lo que en algunos casos es irrelevante, en otros no es necesariamente así.
Los objetos que encontramos que tienen la misma estructura, comportamiento y semántica, forman una clase. Así que lo que un objeto puede saber (estado) o hacer (comportamiento), está determinado por la clase a la que pertenece.
Identidad
La identidad es la propiedad de un objeto, que lo distingue de todos los demás. Los seres humanos tenemos huellas digitales, números de identificación, perfiles DNA. Estos representan el hecho de que cada uno de nosotros es único e identificable. De la misma manera, cada objeto en un sistema OO tiene una identidad distinta. La identidad es necesaria para que podemos hablar con un objeto sin confundirlo con otro, y para que puedan existir al mismo tiempo varios objetos de la misma clase.
En ocasiones se tiende a confundir la identidad de un objeto con su estado. El estado es el conjunto de valores que encapsula un objeto. Dos objetos pueden tener estados idénticos, pero siguen siendo objetos separados, distintos e identificables.
Encapsulación
Los detalles de una clase —estructuras de datos, algoritmos, etc.— se hacen privados, o encapsulan, para que sea imposible que otras clases dependan de ellos. El principal beneficio es que se una clase pueda modificar la forma en que realiza una operación, sin necesidad de afectar a sus clientes.
La forma en que esto se logra, es separando cada clase en dos partes: su interfaz (qué es lo que hace), y su implementación (cómo lo hace).
Modularidad
La modularidad consiste en la descomposición de algo grande y complejo, en partes más sencillas y manejables.
Mientras que la abstracción se enfoca en reducir la complejidad lógica, la modularidad se preocupa por aspectos físicos o de implementación. Por ejemplo, las clases se agrupan en paquetes para poder administrarlas mejor.
Jerarquía
Una jerarquía es una organización de elementos de acuerdo a su tipo, de acuerdo a una estructura de árbol. Así como en la botánica se utilizan jerarquías para definir familias de plantas, en OO, las jerarquías facilitan reconocer similitudes y diferencias entre objetos.
Los dos tipos de jerarquías más comunes en OO son la jerarquía por herencia o generalización, y la jerarquía por agregación. En la primera, se aplica la frase “es un tipo de”, mientras que en la segunda se aplica “es parte de”. Por ejemplo, una manzana es un tipo de fruta, y a su vez puede ser parte de una cosecha.
Tipos
La importancia de los tipos varía dependiendo de si un lenguaje es estricto con los tipos (strongly typed), o no. En los lenguajes OO, los tipos normalmente se refieren a las clases.
En los lenguajes “fuertemente tipificados”, el compilador puede detectar cuando se está tratando de enviar a un objeto, un mensaje que no puede o no sabe responder. Esto evita errores en tiempo de ejecución, además de permitir una mejor optimización del código ejecutable. La desventaja es una menor flexibilidad durante el desarrollo.
Concurrencia
La concurrencia se preocupa por administrar el acceso a recursos compartidos entre operaciones que se sobreponen en el tiempo (incluyendo la ejecución en paralelo).
Supongamos que tenemos un proceso con múltiples hilos de control. Es posible que un objeto reciba un mensaje al mismo tiempo (aproximadamente) de dos objetos diferentes. Este es un escenario que debemos considerar y manejar apropiadamente. Existen dos estrategias básicas de control de concurrencia: pesimista, optimista y muy optimista.
En el control pesimista, cuando un objeto inicia acceso a un recurso compartido, le pone un candado, realiza el trabajo que necesita, y una vez que termina, libera el recurso. Esta estrategia no es muy escalable, por lo que sólo se debe aplicar en sistemas pequeños o donde el acceso a recursos compartidos sea raro.
El control optimista utiliza un acercamiento más complejo, pero más escalable. Cuando un objeto inicia el acceso a un recurso compartido, le pone una “marca” única a éste. Después procede a realizar su trabajo, y cuando es momento de aplicar los cambios necesarios en el objeto compartido, le pone un candado, verifica que su marca no haya sido modificada por otro objeto, aplica los cambios, y libera el candado. En dado caso que la marca haya sido modificada, se dice que hay una colisión. Las colisiones se pueden manejar de diferentes maneras, desde ignorarlas, hasta avisar al usuario de la aplicación para que elija la acción deseada.
Persistencia
Los objetos tienen un periodo de existencia, desde los más volátiles, hasta los más estables. Si un objeto requiere sobrevivir al proceso en que se ejecuta, entonces se dice que es persistente. En otras palabras, la persistencia es la capacidad de un objeto para existir más allá del proceso que lo ejecuta. Para implementar la persistencia, requerimos de algún mecanismo para almacenar datos. Existen diversos mecanismos, desde archivos en texto plano, hasta bases de datos relacionales (RDBMS) orientadas a objetos (OODBMS).
Con esto concluimos nuestra revisión sobre los principios básicos de la orientación a objetos. Recuerden que para ser un buen desarrollador, se necesita contar con una buena base teórica.
Referencias
• Atomic Object. Object Oriented Tutorial.
atomicobject.com/training-material.page
- Log in to post comments