METODOLOGÍA ORIENTADA A OBJETOS

La metodología orientada a objetos ha derivado de las metodologías anteriores a éste. Así como los métodos de diseño
estructurado realizados guían a los desarrolladores que tratan de construir sistemas complejos utilizando algoritmos
como sus bloques fundamentales de construcción, similarmente los métodos de diseño orientado a objetos han
evolucionado para ayudar a los desarrolladores a explotar el poder de los lenguajes de programación basados en objetos
y orientados a objetos, utilizando las clases y objetos como bloques de construcción básicos.

Actualmente el modelo de objetos ha sido influenciado por un número de factores no sólo de la Programación Orientada
a Objetos, POO (Object Oriented Programming, OOP por sus siglas en inglés). Además, el modelo de objetos ha probado
ser un concepto uniforme en las ciencias de la computación, aplicable no sólo a los lenguajes de programación sino
también al diseño de interfaces de usuario, bases de datos y arquitectura de computadoras por completo. La razón de
ello es, simplemente, que una orientación a objetos nos ayuda a hacer frente a la inherente complejidad de muchos tipos
de sistemas.

Se define a un objeto como "una entidad tangible que muestra alguna conducta bien definida". Un objeto "es cualquier
cosa, real o abstracta, acerca de la cual almacenamos datos y los métodos que controlan dichos datos".

Los objetos tienen una cierta "integridad" la cual no deberá ser violada. En particular, un objeto puede solamente cambiar
estado, conducta, ser manipulado o estar en relación con otros objetos de manera apropiada a este objeto.

Actualmente, el Análisis Orientado a Objetos (AOO) va progresando como método de análisis de requisitos por derecho
propio y como complemento de otros métodos de análisis. En lugar de examinar un problema mediante el modelo clásico
de entrada-proceso-salida (flujo de información) o mediante un modelo derivado exclusivamente de estructuras
jerárquicas de información, el AOO introduce varios conceptos nuevos. Estos conceptos nuevos le parecen inusuales a
mucha gente, pero son bastante naturales.

Una clase es una plantilla para objetos múltiples con características similares. Las clases comprenden todas esas
características de un conjunto particular de objetos. Cuando se escribe un programa en lenguaje orientado a objetos, no
se definen objetos verdaderos sino se definen clases de objetos.

Una instancia de una clase es otro término para un objeto real. Si la clase es la representación general de un objeto, una
instancia es su representación concreta. A menudo se utiliza indistintamente la palabra objeto o instancia para referirse,
precisamente, a un objeto.

En los lenguajes orientados a objetos, cada clase está compuesta de dos cualidades: atributos (estado) y métodos
(comportamiento o conducta). Los atributos son las características individuales que diferencian a un objeto de otro
(ambos de la misma clase) y determinan la apariencia, estado u otras cualidades de ese objeto. Los atributos de un
objeto incluyen información sobre su estado.

Los métodos de una clase determinan el comportamiento o conducta que requiere esa clase para que sus instancias
puedan cambiar su estado interno o cuando dichas instancias son llamadas para realizar algo por otra clase o instancia.
El comportamiento es la única manera en que las instancias pueden hacerse algo a sí mismas o tener que hacerles algo.
Los atributos se encuentran en la parte interna mientras que los métodos se encuentran en la parte externa del objeto.

Representación visual de un objeto como componente de software

Para definir el comportamiento de un objeto, se crean métodos, los cuales tienen una apariencia y un comportamiento
igual al de las funciones en otros lenguajes de programación, los lenguajes estructurados, pero se definen dentro de una
clase. Los métodos no siempre afectan a un solo objeto; los objetos también se comunican entre sí mediante el uso de
métodos. Una clase u objeto puede llamar métodos en otra clase u objeto para avisar sobre los cambios en el ambiente o
para solicitarle a ese objeto que cambie su estado.
Cualquier cosa que un objeto no sabe, o no puede hacer, es excluida del objeto. Además, como se puede observar de los
diagramas, las variables del objeto se localizan en el centro o núcleo del objeto. Los métodos rodean y esconden el
núcleo del objeto de otros objetos en el programa. Al empaquetamiento de las variables de un objeto con la protección de
sus métodos se le llama encapsulamiento. Típicamente, el encapsulamiento es utilizado para esconder detalles de la
puesta en práctica no importantes de otros objetos. Entonces, los detalles de la puesta en práctica pueden cambiar en
cualquier tiempo sin afectar otras partes del programa.

Esta imagen conceptual de un objeto —un núcleo de variables empaquetadas en una membrana protectora de métodos
— es una representación ideal de un objeto y es el ideal por el que los diseñadores de sistemas orientados a objetos
luchan. Sin embargo, no lo es todo: a menudo, por razones de eficiencia o la puesta en práctica, un objeto puede querer
exponer algunas de sus variables o esconder algunos de sus métodos.

El encapsulamiento de variables y métodos en un componente de software ordenado es, todavía, una simple idea
poderosa que provee dos principales beneficios a los desarrolladores de software:

Modularidad, esto es, el código fuente de un objeto puede ser escrito, así como darle mantenimiento,
independientemente del código fuente de otros objetos. Así mismo, un objeto puede ser transferido alrededor del sistema
sin alterar su estado y conducta.

Ocultamiento de la información, es decir, un objeto tiene una "interfaz publica" que otros objetos pueden utilizar para
comunicarse con él. Pero el objeto puede mantener información y métodos privados que pueden ser cambiados en
cualquier tiempo sin afectar a los otros objetos que dependan de ello.

Los objetos proveen el beneficio de la modularidad y el ocultamiento de la información. Las clases proveen el beneficio
de la reutilización. Los programadores de software utilizan la misma clase, y por lo tanto el mismo código, una y otra vez
para crear muchos objetos.

En las implantaciones orientadas a objetos se percibe un objeto como un paquete de datos y procedimientos que se
pueden llevar a cabo con estos datos. Esto encapsula los datos y los procedimientos. La realidad es diferente: los
atributos se relacionan al objeto o instancia y los métodos a la clase. ¿Por qué se hace así? Los atributos son variables
comunes en cada objeto de una clase y cada uno de ellos puede tener un valor asociado, para cada variable, diferente al
que tienen para esa misma variable los demás objetos. Los métodos, por su parte, pertenecen a la clase y no se
almacenan en cada objeto, puesto que sería un desperdicio almacenar el mismo procedimiento varias veces y ello va
contra el principio de reutilización de código.

Otro concepto muy importante en la metodología orientada a objetos es el de herencia. La herencia es un mecanismo
poderoso con el cual se puede definir una clase en términos de otra clase; lo que significa que cuando se escribe una
clase, sólo se tiene que especificar la diferencia de esa clase con otra, con lo cual, la herencia dará acceso automático a
la información contenida en esa otra clase.

Con la herencia, todas las clases están arregladas dentro de una jerarquía estricta. Cada clase tiene una superclase (la
clase superior en la jerarquía) y puede tener una o más subclases (las clases que se encuentran debajo de esa clase en
la jerarquía). Se dice que las clases inferiores en la jerarquía, las clases hijas, heredan de las clases más altas, las clases
padres.

Las subclases heredan todos los métodos y variables de las superclases. Es decir, en alguna clase, si la superclase
define un comportamiento que la clase hija necesita, no se tendrá que redefinir o copiar ese código de la clase padre.
De esta manera, se puede pensar en una jerarquía de clase como la definición de conceptos demasiado abstractos en lo
alto de la jerarquía y esas ideas se convierten en algo más concreto conforme se desciende por la cadena de la
superclase.

Sin embargo, las clases hijas no están limitadas al estado y conducta provistos por sus superclases; pueden agregar
variables y métodos además de los que ya heredan de sus clases padres. Las clases hijas pueden, también, sobrescribir
los métodos que heredan por implementaciones especializadas para esos métodos. De igual manera, no hay limitación a
un sólo nivel de herencia por lo que se tiene un árbol de herencia en el que se puede heredar varios niveles hacia abajo y
mientras más niveles descienda una clase, más especializada será su conducta.

La herencia presenta los siguientes beneficios:

Las subclases proveen conductas especializadas sobre la base de elementos comunes provistos por la superclase. A
través del uso de herencia, los programadores pueden reutilizar el código de la superclase muchas veces.

Los programadores pueden implementar superclases llamadas clases abstractas que definen conductas "genéricas". Las
superclases abstractas definen, y pueden implementar parcialmente, la conducta, pero gran parte de la clase no está
definida ni implementada. Otros programadores concluirán esos detalles con subclases especializadas.

Ventajas de la metodología orientada a objetos

En síntesis, algunas ventajas que presenta son:

Reutilización. Las clases están diseñadas para que se reutilicen en muchos sistemas. Para maximizar la reutilización, las
clases se construyen de manera que se puedan adaptar a los otros sistemas. Un objetivo fundamental de las técnicas
orientadas a objetos es lograr la reutilización masiva al construir el software.

Estabilidad. Las clases diseñadas para una reutilización repetida se vuelven estables, de la misma manera que los
microprocesadores y otros chips se hacen estables.

El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivel. El encapsulamiento oculta
los detalles y hace que las clases complejas sean fáciles de utilizar.

Se construyen clases cada vez más complejas. Se construyen clases a partir de otras clases, las cuales a su vez se
integran mediante clases. Esto permite construir componentes de software complejos, que a su vez se convierten en
bloques de construcción de software más complejo.

Calidad. Los diseños suelen tener mayor calidad, puesto que se integran a partir de componentes probados, que han sido
verificados y pulidos varias veces.

Un diseño más rápido. Las aplicaciones se crean a partir de componentes ya existentes. Muchos de los componentes
están construidos de modo que se pueden adaptar para un diseño particular.

Integridad. Las estructuras de datos (los objetos) sólo se pueden utilizar con métodos específicos. Esto tiene particular
importancia en los sistemas cliente-servidor y los sistemas distribuidos, en los que usuarios desconocidos podrían
intentar el acceso al sistema.
Mantenimiento más sencillo. El programador encargado del mantenimiento cambia un método de clase a la vez. Cada
clase efectúa sus funciones independientemente de las demás.

Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una interfaz de usuario gráfica de modo que el usuario
apunte a iconos o elementos de un menú desplegado, relacionados con los objetos. En determinadas ocasiones, el
usuario puede ver un objeto en la pantalla. Ver y apuntar es más fácil que recordar y escribir.

Independencia del diseño. Las clases están diseñadas para ser independientes del ambiente de plataformas, hardware y
software. Utilizan solicitudes y respuestas con formato estándar. Esto les permite ser utilizadas en múltiples sistemas
operativos, controladores de bases de datos, controladores de red, interfaces de usuario gráficas, etc. El creador del
software no tiene que preocuparse por el ambiente o esperar a que éste se especifique.

Interacción. El software de varios proveedores puede funcionar como conjunto. Un proveedor utiliza clases de otros.
Existe una forma estándar de localizar clases e interactuar con ellas. El software desarrollado de manera independiente
en lugares ajenos debe poder funcionar en forma conjunta y aparecer como una sola unidad ante el usuario.

Computación Cliente-Servidor. En los sistemas cliente-servidor, las clases en el software cliente deben enviar solicitudes
a las clases en el software servidor y recibir respuestas. Una clase servidor puede ser utilizada por clientes diferentes.
Estos clientes sólo pueden tener acceso a los datos del servidor a través de los métodos de la clase. Por lo tanto, los
datos están protegidos contra su corrupción.

Computación de distribución masiva. Las redes a nivel mundial utilizarán directorios de software de objetos accesibles. El
diseño orientado a objetos es la clave para la computación de distribución masiva. Las clases de una máquina
interactúan con las de algún otro lugar sin saber donde residen tales clases. Ellas reciben y envían mensajes orientados
a objetos en formato estándar.

Mayor nivel de automatización de las bases de datos. Las estructuras de datos (los objetos) en las bases de datos
orientadas a objetos están ligadas a métodos que llevan a cabo acciones automáticas. Una base de datos OO tiene
integrada una inteligencia, en forma de métodos, en tanto que una base de datos relacional básica carece de ello.

Migración. Las aplicaciones ya existentes, sean orientadas a objetos o no, pueden preservarse si se ajustan a un
contenedor orientado a objetos, de modo que la comunicación con ella sea a través de mensajes estándar orientados a
objetos.

Mejores herramientas CASE. Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software
Asistida por Computadora) utilizarán las técnicas gráficas para el diseño de las clases y de la interacción entre ellas, para
el uso de los objetos existentes adaptados a nuevas aplicaciones. Las herramientas deben facilitar el modelado en
términos de eventos, formas de activación, estados de objetos, etc. Las herramientas OO del CASE deben generar un
código tan pronto se definan las clases y permitir al diseñador utilizar y probar los métodos recién creados. Las
herramientas se deben diseñar de manera que apoyen el máximo de creatividad y una continua afinación del diseño
durante la construcción.