1.2.- DESARROLLO ORIENTADO A OBJETOS

Enfoque de Orientación a Objetos

El enfoque de orientación a objetos es una forma de observar la realidad. El enfoque como su nombre lo indica se basa en el concepto de objeto:

Es todo aquello que tiene características que lo hacen único e indivisible dentro del entorno al que pertenece. Siempre es posible establecer propiedades o atributos de un objeto, lo mismo que su grado de respuesta a estímulos externos (comportamientos del objeto). percibimos tal cual por sus características y su respuesta ante el entorno. Un elemento notable es que las características de un objeto pueden ser por sí mismas otros objetos.

La orientación a objetos promete mejoras de amplio alcance en la forma de diseño, desarrollo y mantenimiento del software ofreciendo una solución a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo de software: la falta de portabilidad del código y reusabilidad, código que es difícil de modificar, ciclos de desarrollo largos y técnicas de codificación no intuitivas.

Un lenguaje orientado a objetos ataca estos problemas. Tiene tres características básicas:

 

– basado en objetos,

– basado en clases y

– capaz de tener herencia de clases.

 

El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos definir un objeto como un conjunto complejo de datos y programas que poseen estructura y forman parte de una organización.

Esta definición especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un dato simple, sino que contiene en su interior cierto número de componentes bien estructurados. En segundo lugar, cada objeto no es un ente aislado, sino que forma parte de una organización jerárquica o de otro tipo.

 

Estructura de un Objeto

 

Un objeto puede considerarse como una especie de cápsula dividida en tres partes:

 

1. RELACIONES. Las relaciones permiten que el objeto se inserte en la organización y están formadas esencialmente por punteros a otros objetos.

2. PROPIEDADES Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.

3. METODOS. Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.

 

Clases e Instancias

Dentro de la definición de objetos hay algunos que serán muy parecidos ya sea que comparten la misma definición de características. Una clase es una ayuda notacional en el análisis para establecer las propiedades y funciones que serán comunes a todos los objetos que se generen a partir de ella, tal y como lo muestra la figura 1.2.

 

Figura 1.2 Clase en notación UML

En la notación de la metodología UML se utiliza un rectángulo con tres divisiones para definir una clase. En la primera se indica el nombre de la clase, la segunda contendrá todas las propiedades del objeto y la tercera contiene las funciones por media de las cuales el objeto responde a estímulos de su entorno.

En el enfoque orientado a objetos, todos los objetos se generan a partir de clases. Incluso cuando solo se genere uno, de forma que todo objeto está asociado a la clase a partir de la que se generó y se dice que dicho objeto es una instancia de clase que puede usar directamente las características y funciones asociadas a la clase.

La clase es un elemento conceptual que permite definir y modelar, el objeto o instancia de clase es una ejemplificación de clase. Una instancia de clase tiene valores de atributos y puede invocar sus métodos.

 

Encapsulamiento

 

Cuando interactuamos con un objeto únicamente nos interesa conocer las características y atributos que nos permiten establecer dicha interacción, es decir el objeto “publica” ciertas características y métodos, pero encapsula las demás ya que no es fundamental para el exterior conocerlas para poder interactuar con el objeto. Únicamente se requiere conocer aquellas que se exhiban como públicas.

 

Polimorfismo

El polimorfismo se define como la característica de que un objeto que pide la ejecución de una función a otro objeto no necesita saber la naturaleza del objeto dueño de la función. El polimorfismo más común lo tenemos en un operador como el de suma o multiplicación, ya que la operación se realiza aun cuando los operándoos sean distintos. La implementación del operador tiene el cuidado de hacer correctamente la operación para el tipo de datos que está participando como se muestra en la figura 1.3.

Figura 1.3. La clase animal y las subclases león y pajaro. Polimorfismo

Herencia

 El concepto de herencia va asociado a la Generalización –Especialización- en el que se establece que cierta clase de objetos puede tener clases de objetos más especializados las cuales por ser especializaciones, tendrán todos los elementos de la clase genérica y modificarán la funcionalidad heredada o agregarán nueva funcionalidad para especializarse.

En la notación UML la relación de herencia entre dos clases se indica por medio de una flecha hueca que apunta a la clase ascendiente, esto es porque, en una relación de herencia el padre no se construye teniendo en cuenta que se pueden derivar de él clases más especializadas. Por otro lado las clases que son descendientes es importante que sepan quién es su ascendiente pues de él están tomando propiedades y funciones. Ejemplo de herencia la figura 1.4.

Figura1.4. Herencia de clase

Las clases que no generan directamente instancias se denominan abstractas, y aquellas que generan directamente objetos se les denominan concretas.

Asociaciones estáticas

Permiten la estructuración de los objetos incorporando reglas del negocio. En su forma más simple es un vínculo entre dos objetos. Al nivel de análisis se documentan como vínculos entre clases, sin embargo, es importante recordar que las clases son definiciones generales de un tipo de objeto, lo que implica que no son colecciones de objetos y por lo tanto las asociaciones estáticas no son asociaciones entre conjuntos de objetos como se pueden dar en el modelo Entidad Relación tradicional.

La asociación se indica con una línea uniendo a las dos clases. La línea puede tener una etiqueta que indique la forma en la que se está interpretando la asociación. Muchas reglas del negocio se refieren a los niveles máximos y mínimos de vinculación entre distintos objetos de la aplicación. Por ejemplo, un objeto Cliente solo debe estar asociado a un solo agente de Ventas, aunque un Agente Vendedor puede estar vinculado a más de un cliente. Este tipo de información es la multiplicidad o cardinalidad de la asociación y se indica colocando un rango en los extremos de la asociación.

 

Existen casos en los que una clase se asocia con más de una clase, en donde es conveniente no sólo mostrar la multiplicidad, sino también cómo el analista concibe el vínculo de la clase en cada asociación. En estos casos se le define un rol a la clase en a cada asociación que participa como se muestra en la figura 1.5.

Figura 1.5: Asociaciones estáticas

 

Asociaciones de agregación o composición.

Un caso particular de asociación estática, es cuando se encuentra que un objeto no sólo está asociado con otro, sino que además uno es parte del otro. Este tipo de situación se le llama asociación de agregación.

La agregación podemos establecerla en dos tipos: por composición y por agregación simple como se muestra en la figura 1.6. En la primera, los objetos y la asociación se dieron simultáneamente y cuando desaparezca un objeto, el otro también desaparecerá, así como la asociación. Por lo regular se da cuando modelamos un objeto como propiedad de otro objeto.

Figura 1.6 Agregación y composición.

La agregación simple es la más común y se da cuando tenemos documentos, tales como facturas, órdenes de entrada de almacén, recibos de pago, etc. Ya que el documento es el objeto central y tiene una serie de características con cierto grado de opcionalidad, que hacen no necesiten estar los dos para que la agregación se dé.

En UML la agregación se denota con un rombo en el extremo de la asociación en donde se encuentra la clase a la que se le están agregando objetos. La agregación por composición se denota con el rombo sólido, mientas que la agregación simple es con el rombo vacío.

En general es conveniente indicar las asociaciones de agregación pues sugieren que las operaciones de mantenimiento a esos objetos tienen que hacerse dentro de una misma transacción, lo cual ayuda a identificar la complejidad de los modelos de objetos que se están obteniendo. Siempre será más fácil dar mantenimiento a una familia de objetos que a dos o más familias de objetos como lo sugieren las asociaciones de agregación.