J2EE
Gina Tatiana Marín Calderón
E-mail: tachita_1986@hotmail.com

RESUMEN:
El siguiente documento tiene por objetivo definir y aplicar los patrones de diseño Session Façade, Data Access Object y Value Objet a un ejemplo particular.
Para lograr este objetivo, se define que son los patrones J2EE, para posteriormente concentrarnos en la definición de los patrones de estudio. A continuación, se define un caso de estudio en el cual se aplican técnicas de análisis y diseño orientado a objetos, ilustrando la aplicación de los patrones directamente en la fase de diseño. Finalmente, se desarrolla una aplicación web de baja escala, la que implementará una solución a la problemática del caso de estudio en JSP / Struts / JDBC.
Los resultados del estudio permiten a los desarrolladores J2EE que no tienen conocimientos sobre el tema de patrones, comprender su aplicación y aprender su utilización por medio del ejemplo.
PALABRAS CLAVE:
Contexto
Las aplicaciones cliente necesitan comunicar, transportar e intercambiar datos de negocios con los Enterprise Java Beans, objetos JDBC y otros objetos.
Problema
• Cada llamada a get y set de un objeto remoto implica una invocación remota, lo que afecta directamente en la escalabilidad de una aplicación.
• El paso de los atributos de un objeto de dominio (por ejemplo, Consumidores) a un método puede conducir a métodos con muchos argumentos, y cada modificación de un atributo del objeto de dominio afectará la signatura de todos los métodos que usen este objeto, teniendo con ello problemas de acoplamiento y mantenibilidad.
Motivación
• Las aplicaciones J2EE generalmente hacen uso de EJB para la implementación de los componentes de negocio, lo que implica que cada llamada a una propiedad de un entity bean por medio de los métodos get/set significaría una llamada remota.
• El cliente requiere más de un atributo del componente remoto, lo que conduce a varias llamadas de red (ej, ingreso de un Consumidor).
Solución
Se debe usar una clase que implemente el interfaz Serializable (redefinir el metodo toString() ), en donde sus propiedades miembro pueden variar según el tipo de enfoque:
Si se necesita modelar una tabla relacional o similar, las propiedades de la clase serían las mismas que los campos de la tabla relacional. Este enfoque se denomina Domain Value Object [MAR02].
INTRODUCCION:
Sun Microsystem provee en su sitio web [SUN03-1] [SUN03-2] un conjunto de patrones que pueden ser usados en el contexto del diseño de aplicaciones Java 2 Enterprise Edition, J2EE. Los patrones de diseño J2EE consisten en soluciones recurrentes y documentadas de problemas comunes de diseño de aplicaciones J2EE. Muchas de estas soluciones se basan en los patrones de Gamma et al. [GAM95], así que se podrán encontrar soluciones J2EE que son aplicadas al diseño de aplicaciones de software en general.
CONCEPTOS:
Si se necesita encapsular atributos de varias tablas en una petición (por ejemplo, un carrito de compra, con el id de un cliente, el id y cantidad de un producto), se crea una clase que combine todos los atributos que son requeridos. Este enfoque se denomina Custom Value Object [MAR02].
En una aplicación que no utilice un VO para una operación de negocios, se tendría la siguiente signatura en un método crear:
public void crearConsumidor(String rut, String nombre, String Apellido, Calendar edad….)
Es claro que la signatura es muy larga y difícil de escribir, y que su dificultad de escritura es proporcional a la cantidad de campos de una tabla.
Sin embargo:
public void crearConsumidor(ConsumidorVO vo)
Provee de una signatura mucho más sencilla que la anterior, puesto que se envía una referencia del objeto consumidor, el cual encapsula todos los datos requeridos.
La estructura del patrón es la siguiente:

Consecuencias
• En el contexto de aplicaciones remota, se logra una mayor eficiencia, puesto que reduce el envío de mensajes por red.
• En el contexto de JDBC, permite representar un conjunto de atributos procedentes de uno o varios objetos de dominio, representados por la signatura método (VO) en vez de método (arg1, arg2, arg3…).
• Un Value Object puede contener información obsoleta si se pretende usar en una actualización posterior en otra transacción. Esto se puede corregir con el patrón Versión Number [MAR02].
CARACTERISTICAS:
Contexto
Clases Java comunes o EJB encapsulan lógica y datos de negocios, exponiendo sus interfaces y la complejidad de los servicios distribuidos a la capa cliente.
Problema
En un método de aplicaciones donde se utiliza la arquitectura estratificada (o por capas), se pueden presentar los siguientes problemas:
• Acoplamiento fuerte, provocado por la dependencia directa entre los clientes y los objetos de negocio.
• Demasiadas llamadas a operaciones entre el cliente y el servidor, abocando a problemas de rendimiento de red (en el caso de EJB).
• Falta de una estrategia de acceso uniforme de los clientes, exponiendo los objetos de negocio a una mala utilización.
Motivación
• Proporcionar a los clientes un interfaz sencillo que oculte todas las interacciones complejas entre los componentes de negocio.
• Ocultar al cliente las interacciones y las interdependencias entre los componentes de negocio, permitiendo de esta forma el aumento de flexibilidad y evitar que los cambios en los objetos de negocio repercutan en errores en la vista.
• Evitar la exposición directa de los objetos de negocios a los clientes, para mantener el acoplamiento entre las dos capas al mínimo.
• Centralizar los casos de uso en métodos centralizados sobre una clase.
Solución
Usar un session bean (para el caso de aplicaciones EJB) o una clase java común que encapsule la complejidad de las interacciones entre los objetos de negocio participantes en un flujo de trabajo (workflow). El session façade maneja los objetos de negocios y proporciona un servicio de acceso uniforme a los cliente. Es decir, el cliente (JSP, Swing, etc) no tratará con los EJB ni con la complejidad del acceso remoto, ni con JDBC, sino que trabajará con colecciones y Value's Object. .
La estructura del patrón es la siguiente

Consecuencias
• Introduce una capa extra entre el Modelo y el Controlador: Agregando esta capa, se puede modelar los casos de uso de una forma centralizada, logrando también centralizar todo el acoplamiento a esta capa intermedia.
• Expone un interfaz uniforme para el acceso al Modelo.
• Cuando se utiliza con EJB, reduce el número de invocaciones remotas, aumentando la escalabilidad.
• Simplifica la gestión de transacciones y el mantenimiento de los casos de uso.
1.3 Data Access Object
Contexto
El acceso a los datos varía según el soporte persistente y el proveedor.
Problema
• La poca homogeneidad del almacenamiento persistente produce distintas implementaciones para lograr la accesibilidad (la iimplementación de operaciones sobre un archivo de texto plano es distinta a la realizada sobre un motor de base de datos, aunque se requiera de ambos las mismas operaciones)). Un cambio en el sistema de almacenamiento (cambio de proveedor de bd o de formato) puede conducir a una reimplentación de los componentes de datos y componentes vinculados (los que requieren estos datos).
• Con el API de JDBC se puede acceder de una forma estándar a los servidores de bases de datos relacional. Sin embargo, la implementación del lenguaje SQL puede variar según el propietario, aunque se suponga que es un estándar (por ejemplo, las operaciones para recuperar el autonumérico de un registro ingresado no es igual en Oracle que en MySQL o SQLServer).
• El acceso a datos de sistemas no relacionales incurre en la utilización de un API no propietario, por lo que se aumenta la dependencia entre el código de la aplicación y el código del acceso a datos.
• Introducir el código de conectividad en todos los componentes que requieren de acceso hace difícil la mantención y la migración cuando se desea cambiar la fuente de datos.
Motivación
• Los componentes de la aplicación necesitan recuperar y almacenar información desde almacenamientos persistentes y otras fuentes de datos variadas (incluidos archivos de texto, planillas de cálculo, etc). Además, puede variar los proveedores, por lo que se tiene el problema del SQL propietario.
• Una API de datos que exponga al cliente un conjunto de operaciones comunes lograría reducir el acoplamiento y dependencias de la implementación. Por ejemplo, una tabla de clientes en un modelo relacional para el proveedor Oracle o MySQL tiene las mismas operaciones: agregar, eliminar, modificar, etc. Sin embargo, algunas operaciones pueden tener distintas implementaciones (porque el SQL para esa acción puede ser distinto según el proveedor), pero esto sería independiente para los clientes (por medio de una factory)
• Los componentes necesitan ser transparentes al almacenamiento persistente real o la implementación de la fuente de datos para proporcionar una portabilidad y migración sencillas a diferentes productos, tipos de almacenamiento y tipos de fuentes de datos.
Solución
• Utilizar un Data Access Object (DAO) para abstraer y encapsular todos los accesos a la fuente de datos, logrando así desacoplar la lógica de negocios de la lógica de acceso a datos. El DAO maneja la conexión con la fuente de datos para obtener y almacenar datos.
• El desacoplamiento de la lógica de negocios con el acceso a datos permite crear implementaciones plugables del DAO, con solo seleccionar el tipo de fuente de datos durante la instalación/configuración de una aplicación.
Estructura

Consecuencias
• Flexibilidad en la instalación/configuración de una aplicación.
• Independencia del vendedor de la fuente de datos.
• Independencia del recurso (base de datos relacional, base de datos orientado a objetos, ficheros planos, etc.).
• Reduce la complejidad de la implementación de la lógica de negocios (Session Façades)
• Más complejidad en el diseño, debido principalmente al conjunto de clases que colaboran en el DAO y en forma general, cada DAO es utilizado para modelar una tabla del modelo relacional.
2. Caso de estudio
Para aplicar estos dos patrones J2EE, se presentará un caso de estudio de baja escala, en el cual se aplicará en forma directa los patrones de diseño vistos anteriormente.
El caso de estudio se enmarca en el grupo de desarrollo Inukisoft. Esta empresa basa su principal actividad en el desarrollo de software, por lo que requiere de una web que permita a los clientes ver la oferta de productos y enviar consultas / sugerencias. Los administradores de la web de Inukisoft deben poder revisar las consultas y actualizar el catálogo de productos, con una cuenta exclusiva para usuarios administradores. Se especifica que se requiere de una única cuenta de administración, por lo que no se deberá registrar una lista de usuarios.
Cada producto incluye su identificador, nombre, descripción. Los administradores podrán actualizar todos los datos de estos productos, y eliminarlos si lo consideran pertinente.
Las siguientes funciones se pueden resumir en el siguiente diagrama de casos de uso:

En base a este diagrama de casos de uso, se pueden identificar algunos objetos de dominio candidatos: Producto de software, Catálogo, Consulta, Cliente y Administrador. Definiendo un diagrama de clases para armar el modelo conceptual, quedaría:
Ya definido un bosquejo del análisis, toca ir al diseño de la aplicación. Para ello, se define el modelo de datos que se utilizará.
Atributo / Tipo Descripción del atributo
id / entero largo sin signo autonumérico Identifica a cada consulta con un número correlativo.
consulta / texto largo 255 El texto de la consulta efectuada por el cliente
fecha / tipo fecha timestamp La hora y fecha de la consulta
Tabla: ProductoSoftware
Atributo / Tipo Descripción del atributo
id / entero largo sin signo autonumérico id / entero largo sin signo autonumérico
nombre / texto largo 50 Describe las funcionalidades del producto
descripcion / texto largo 1000 La hora y fecha de la consulta
precio / flotante sin signo El precio del producto de software
Los otros elementos del modelo conceptual no están incluidos en el modelo relacional, puesto que no son entidades que almacenan cantidades de datos.
Ya con los objetos de dominio persistentes definidos, se puede entonces aplicar directamente el patrón Domain Value Object sobre las tablas Consulta y ProductoSoftware, por lo que se obtendría las clases ConsultaVO y ProductoSoftwareVO.
Ya generalizadas las tablas del modelo relacional en clases, se debe a continuación aplicar el patrón DAO a las tablas Consulta y Producto de Software. Bellas [BEL03] propone un esquema estructural para los DAO's, el cual se reutilizará este diseño para la tabla Consulta:
Tabla: Consulta
Clase / Interface Descripción
SQLConsultaDAO Interface que define todas las operaciones de acción y consulta de la tabla Consulta
AbstractSQLConsultaDAO Clase Abstracta que implementa SQLConsultaDAO. Los métodos implementados en la clase abstracta son los que son independiente de plataforma (en general son todos, a excepción del método create() ).
JDBC3CCConsultaDAO Subclase de AbstractSQLConsultaDAO, la cual es una clase concreta y final que implementa los métodos dependientes de la plataforma. En general, se implementa el método create(), puesto que el campo clave de la tabla es un autonumérico, por lo que la estrategia de recuperación, en este caso, es por DriverJDBC del tipo 3.
SQLConsultaDAOFactory Clase que implementa el patrón de diseño Factory Method [GAM95]. Esta clase define cual subclase de AbstractSQLConsultaDAO debe ser instanciada cuando se utiliza el DAOConsulta.
El diagrama de clases de este DAO queda representado de la siguiente manera:

Podríamos reutilizar este diseño de clases para la tabla “ProductoSoftware”, por lo que se tendría terminado el Modelo de Tablas del sistema.
El siguiente paso del diseño es definir donde van a ir implementados los casos de uso. Para ello, se puede aplicar directamente el patrón Session Façade, donde se definirán todas las operaciones de los casos de uso.
Esta façade será el punto de acceso a todas las funcionalidades del sistema. En una arquitectúra MVC (Modelo Vista Control), los DAO’s y el VO representan la capa Modelo. La Vista puede ser representada por una aplicación Swing, JSP o Applet. La vista se comunica con las clases controlador, las cuales son las que se comunican a su vez con la façade del sistema. De esta forma, se tiene una arquitectura general del software con menos acoplamiento, lo que permite trabajar con el modelo de forma independiente a la vista (potenciando la separación de roles de trabajo, por ejemplo, equipo de desarrollo del Modelo, equipo de desarrollo de la Vista y Control, etc.)
La siguiente fase del diseño es definir la vista que se favorecerá del Modelo. Según el caso de estudio, se requiere de una WebApp, por lo que las vistas serán implementadas como JSP y las clases controlador serán definidas como Servlets Action (subclase de Action de Struts) que invocan a los datos de la façade (para evitar que la vista se comunique directamente con la façade del sistema). Para definir los elementos de la vista, se requiere del diseño de la navegación, la cual será jerárquica:

Mapa de navegación / componentes de la vista Administrador (1)
También incluye la siguiente jerarquía:

La navegación de la vista Cliente queda definida de la siguiente forma:

Los servlets action cumplen el rol de controlador de flujo de las acciones, seteando los datos que deben presentarse en las páginas JSP, y también son utilizados para invocar a los métodos de negocios definidos en la façade.
3. Implementación
En la implementación se deben codificar los modelos de clases obtenidos del diseño (en este caso, en un diseño logrado con la aplicación directa de los patrones de diseño). Se debe tener en cuenta que el patrón de diseño representa una solución de diseño, teniendo como objetivo la reutilización. Sin embargo, la codificación del patrón de diseño a lenguaje Java no conduce necesariamente a componentes reutilizables, por lo que se deberán utilizar otras herramientas para hacer reutilizable el código obtenido. En esta investigación se utilizó el Refactoring de Eclipse para reutilizar el código de las clases, utilizando un DAO de otro proyecto anterior, para luego adaptar el nombre, la ruta de los paquetes, y la redefinición del método (en general, cambiar el SQL). Las vinculaciones y correcciones de nombres son realizadas por el IDE. Esta técnica es útil para los DAO’s que tienen pocos campos y que cumplen las mismas funcionalidades básicas (por ejemplo, una tabla país (id, descripción) y otra tabla categorías (id, categoría) las que son utilizadas para llenar los comboBox de un formulario).
La implementación del Modelo Vista Control se realizó en Struts 1.1 [APA02], aconsejando la siguiente metodología en la implementación del mapa de acciones [URZ03]:
• Definir el mapeo correspondiente a la nueva acción en el archivo struts-config.xml, indicando el nombre de la acción, y la clase Action que ejecutará las acciones correspondientes, el nombre del FormBean que validará los datos, el alcance que tendrán esos datos, de donde será referenciada y quien desplegará los datos para los ActionForward definidos en el servlet.
• Escribir el BeanForm, y realizar las validaciones correspondientes para asegurar que los datos lleguen al controlador (Action).
• Escribir el Action Servlet, el cual ejecutará las acciones del requerimiento (típicamente una invocación a la façade, la asignación de valores al FormBean y la asignación de valores asociados a la Request).
• Escribir el o los archivos JSP que generará la vista para el usuario. Se debe tener especial cuidado con los beans y atributos que se utilizarán en este archivo ya que deben estar definidos en el FormBean e ingresados como atributos al requerimiento que recibe la página JSP
• Para implementar los componentes de la vista, se utiliza Java Standar Tag Library (JSTL), puesto que consiste en una solución, basada en XML, que sustituye el scriptlet incristado de la páginas JSP por tags XML [PAL03]. Este tipo de solución permite adecuar la vista a los roles que no están familiarisados con el código Java, como por ejemplo, los diseñadores. De esta forma, se mejora la separación de roles de trabajo.
La implementación de patrones J2EE no es trivial en los desarrollos de aplicaciones empresariales. Los desarrolladores necesitan conocer propuestas metodológicas para una correcta implementación de los patrones. La investigación entrega un aporte metológico, junto con un producto de baja escala con ejemplos de implementación.
El código fuente del caso de estudio, incluido en la investigación, puede ayudar a comprender la implementación del patrón, pero debe quedar claro que los patrones no son las respuestas únicas a un problema, sino que más bien representan una solución estructural y de comportamiento para un problema de diseño recurrente.
REFERENCIAS:
• http://cmcrossroads.com/bradapp/javapats.html
• http://java.sun.com/blueprints/corej2eepatterns/index.html
• http://www.dcc.uchile.cl/~luguerre/cc40b
• http://www.programacion.net/java/tutorial/patrones2/

programacion orientada a objetos

PROGRAMACION ORIENTADA A OBJETOS
Gina Tatiana Marín Calderón
E-mail: tachita_1986@hotmail.com

RESUMEN: La Programación Orientada a Objetos es un paradigma de programación que usa objetos y sus interacciones para diseñar aplicaciones y programas de computador. Está basado en varias técnicas, incluyendo herencia, modularidad, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de 1990. Actualmente son muchos los lenguajes de programación que soportan la orientación a objetos.


PALABRAS CLAVE:
Los objetos son entidades que combinan estado, comportamiento e identidad:
• El estado está compuesto de datos, será uno o varios atributos a los que se habrán asignado unos valores concretos (datos).
• El comportamiento está definido por los procedimientos o métodos con que puede operar dicho objeto, es decir, qué operaciones se pueden realizar con él.
• La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).


INTRODUCCION:
La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener, reutilizar y volver a utilizar.
De aquella forma, un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separan ni deben separarse el estado y el comportamiento.
Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a ninguno de ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos.
Esto difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada sólo se escriben funciones que procesan datos. Los programadores que emplean éste nuevo paradigma, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.


CONCEPTOS:
Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. Al parecer, en este centro, trabajaban en simulaciones de naves, y fueron confundidos por la explosión combinatoria de cómo las diversas cualidades de diversas naves podían afectar unas a las otras. La idea ocurrió para agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamiento. Fueron refinados más tarde en Smalltalk, que fue desarrollado en Simula en Xerox PARC (y cuya primera versión fue escrita sobre Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar "en marcha" en lugar de tener un sistema basado en programas estáticos.
La programación orientada a objetos tomó posición como el estilo de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++, una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas de usuario, para las cuales la programación orientada a objetos está particularmente bien adaptada. En este caso, se habla también de programación dirigida por eventos.
Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. La adición de estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a menudo a problemas de compatibilidad y a la capacidad de mantenimiento del código. Los lenguajes orientados a objetos "puros", por otra parte, carecían de las características de las cuales muchos programadores habían venido a depender. Para saltar este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo algunas características imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet, y a la implementación de la máquina virtual de Java en la mayoría de navegadores. PHP en su versión 5 se ha ido modificando y soporta una orientación completa a objetos, cumpliendo todas las características propias de la orientación a objetos.
La programación orientada a objetos es una nueva forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:
• Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.
• Herencia: (por ejemplo, herencia de la clase D a la clase C) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables públicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de OOP.
• Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.
• Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.
• Evento: un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.
• Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.
• Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.
• Estado interno: es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.
• Componentes de un objeto: atributos, identidad, relaciones y métodos.
• Representación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.
En comparación con un lenguaje imperativo, una "variable", no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.


CARACTERISTICAS:
Hay un cierto desacuerdo sobre exactamente qué características de un método de programación o lenguaje le definen como "orientado a objetos", pero hay un consenso general en que las características siguientes son las más importantes:
• Abstracción: Denota las características esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción.
• Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.
• Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.
• Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.
• Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.
• Recolección de basura: la Recolección de basura o Garbage Collection es la técnica por la cual el ambiente de Objetos se encarga de destruir automáticamente, y por tanto desasignar de la memoria, los Objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo Objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse manualmente.


REFERENCIAS:
• http://java.sun.com – Sitio Java en internet de Sun Microsystems

• http://www.mindview.net/Books/TIJ Buce Eckel