1. INTRODUCCION
Las personas viven en un mundo de objetos. Estos objetos existen en la naturaleza, en entidades hechas por el hombre, en los negocios y en los productos que se utilizan. Pueden ser clasificados, descritos, organizados, combinados, manipulados y creados. Por eso no es sorprendente que se proponga una visión orientada a objetos para la creación de software de computadora, una abstracción que modela el mundo de forma tal que ayuda a entenderlo y gobernarlo mejor.
La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de software fue a finales de los años sesenta. Sin embargo, las tecnologías de objetos han necesitado casi veinte años para llegar a ser ampliamente usadas. Durante los años 1990, la ingeniería del software orientada a objetos se convirtió en el paradigma de elección para muchos productores de software y para un creciente número de sistemas de información y profesionales de la ingeniería.
Las tecnologías de objetos llevan a reutilizar, y la reutilización, especialmente de los componentes de software, lleva a un desarrollo de software más rápido y a programas de mejor calidad. El software orientado a objetos es más fácil de mantener debido a que su estructura es inherentemente poco acoplada. Esto lleva a menores efectos colaterales cuando se deben hacer cambios. Los sistemas orientados a objetos son más fáciles de adaptar y escalar, es decir pueden crearse grandes sistemas ensamblando subsistemas reutilizables.
Hacia mediados de los años 1980, los beneficios de la programación orientada a objetos empezaron a obtener reconocimiento, y el diseño de objetos pareció ser un enfoque sensato para la gente que deseaba utilizar el lenguaje de programación orientada a objetos. Un enfoque orientado a objetos ofrece muchos beneficios sobre un enfoque estructurado.
El análisis orientado a objetos y su diseño se enfoca en los objetos. Los objetos tienen ciertos comportamientos y atributos que determinan la manera en que interactúan y funcionan. No se intenta proporcionar un orden para las acciones al momento del diseño debido a que los objetos funcionan basados en la manera en que funcionan otros objetos. La programación orientada a objetos ayuda a los desarrolladores a crear objetos que reflejan escenarios del mundo real.
La implementación orientada a objetos oculta datos, lo cual significa que se muestra únicamente el comportamiento a los usuarios y se oculta el código subyacente de un objeto. Los comportamientos que el programador expone son únicamente aquellos elementos que el usuario de un objeto puede afectar.
El enfoque orientado a objetos permite que los objetos estén auto-contenidos. Los objetos existen por sí mismos, con una funcionalidad para invocar comportamientos de otros objetos. Al utilizar un enfoque orientado a objetos, los desarrolladores pueden crear aplicaciones que reflejan objetos del mundo real, como rectángulos, elipses y triángulos, además de dinero, números de partes y elementos en un inventario.
En un enfoque orientado a objetos, los objetos, por definición, son modulares en su construcción. Esto quiere decir que son entidades completas y, por lo tanto, tienden a ser altamente reutilizables. Las aplicaciones orientadas a objetos se construyen sobre el paradigma de los mensajes o de los eventos en donde los objetos envían mensajes a otros objetos.
2. PARADIGMA ORIENTADO A OBJETOS
Durante muchos años el término Orientado a Objetos se usó para referirse a un enfoque de desarrollo de software que utilizaba alguno de los lenguajes orientados a objetos: Ada 95, C++, Eiffel, Smalltalk, etc. Thomas Khun describe un paradigma como un conjunto de teorías, estándares y métodos que juntos representan un medio de organización del conocimiento: es decir, un medio de visualizar el mundo. En este sentido, la orientación a objetos es un nuevo paradigma. La orientación a objetos obliga a repensar acerca del rol que juega la computación, sobre lo que significa realizar computación y sobre cómo se estructura la información al interior de la computadora.
Jenkins y Glasgow observan que “la mayoría de los programadores trabajan en un lenguaje y utilizan sólo un estilo de programación. Ellos programan en un paradigma forzado por el lenguaje que utilizan. Con frecuencia, no se enfrentan a métodos alternativos de resolución de un problema, y por consiguiente tienen dificultad en ver la ventaja de elegir un estilo más apropiado al problema a manejar”. Bobrow y Stefik sugieren que existen cuatro clases de estilos de programación: (1) Orientados a procedimientos. Que utilizan algoritmos. (2) Orientados a objetos. Con clases y objetos. (3) Orientados a lógica. Expresado en cálculo de predicados. (4) Orientados a reglas. Con el uso de reglas si-entonces. No existe ningún estilo de programación idóneo para todas las clases de programación. La orientación a objetos se acopla a la simulación de situaciones del mundo real.
3. ORIENTACIÓN A OBJETOS
La orientación a objetos puede describirse como el conjunto de disciplinas que desarrollan y modelan software que facilitan la construcción de sistemas complejos a partir de componentes.
El atractivo intuitivo de la orientación a objetos es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible. Estos conceptos y herramientas orientados a objetos son tecnologías que permiten que los problemas del mundo real sean expresados de modo fácil y natural.
Las técnicas orientadas a objetos proporcionan mejoras y metodologías para construir sistemas de software complejos a partir de unidades de software modularizado y reutilizable. Se necesita un nuevo enfoque para construir software en la actualidad. Este nuevo enfoque debe ser capaz de manipular tanto sistemas grandes como pequeños y debe crear sistemas fiables que sean flexibles, mantenibles y capaces de evolucionar para cumplir las necesidades del cambio.
La orientación a objetos trata de cubrir las necesidades de los usuarios finales, así como las propias de los desarrolladores de productos software. Estas tareas se realizan mediante la modelización del mundo real. El soporte fundamental es el modelo objeto.
Un objeto es la instancia de una clase. Una clase es la representación abstracta de un concepto en el mundo real, y proporciona la base a partir de la cual se crean instancias de objetos específicos. Como ejemplo, puede crear una clase que defina a un cliente. Después puede crear una nueva instancia de la clase cliente para tener un objeto utilizable de Cliente. Para poder crear un objeto de la clase cliente, debe crear una nueva instancia basada en esa clase. Por ejemplo:
Private ObjetoCustomer as ClaseCustomer
ObjetoCustomer = New ClaseCustomer()
Cada objeto es un elemento único de la clase en la que se basa. Si una clase es como un molde, entonces un objeto es lo que se crea a partir del molde. La clase es la definición de un elemento; el objeto es el elemento. El molde para una figura de cerámica en particular, es como una clase; la figura es el objeto.
Todos los objetos están compuestos de tres elementos: (1) Interfaz. La Interfaz es el conjunto de métodos, propiedades, eventos y atributos que se declaran como públicos en su alcance y que pueden invocar los programas escritos para usar los objetos. (2) Implementación. Al código dentro de los métodos se le llama Implementación. Algunas veces también se le llama comportamiento, ya que este código es el que efectivamente logra que el objeto haga un trabajo útil. Es importante entender que las aplicaciones del cliente pueden utilizar los objetos creados aunque se cambie la implementación, siempre que no se cambie la interfaz. Siempre que se mantengan sin cambio el nombre de método, su lista de parámetro y el tipo de datos de devolución, se podrá cambiar la implementación totalmente. (3) Estado. El estado o los datos de un objeto es lo que lo hace diferente de otros objetos de la misma clase. El estado se describe a través de las variables del “elemento miembro” o de la “instancia”. Las variables del miembro son aquellas declaradas, de tal manera que están disponibles para todo el código dentro de la clase. Por lo general, las variables del miembro son privadas en su alcance. Algunas veces, se les conoce como variables de la instancia o como atributos. Observe que las propiedades no son variables del miembro, ya que son un tipo de método que funciona para recuperar y establecer valores.
3.1. Clase
Una clase es esencialmente un proyecto, a partir del cual puede crear objetos. Una clase define las características de un objeto, incluyendo las propiedades que definen los tipos de datos que ese objeto puede contener y los métodos que describen el comportamiento del objeto. Estas características determinan la manera en que otros objetos pueden acceder y trabajar con los datos que se incluyen en el objeto.
Para definir una clase, se coloca la palabra clave Class antes del nombre de su clase, y después se insertan los miembros de la clase (datos y métodos) entre la definición del nombre de la clase y la instrucción End Class. Si incluye los métodos, entonces el código de cada método también se debe incluir entre la declaración del método y el final del mismo.
Por ejemplo, si desea construir objetos que representen perros, puede definir una clase Perro con ciertos comportamientos, como caminar, ladrar y comer, y propiedades específicas, como altura, peso y color. Una vez que haya definido la clase Perro, puede crear objetos con base en esa clase. Es importante observar que todos los objetos Perro creados con base en la clase perro compartirán los mismos comportamientos, pero tendrán sus propios valores específicos para el mismo conjunto de propiedades.
El siguiente ejemplo representa la definición de la clase Perro. Tome en consideración que ésta no es una sintaxis estricta de VB.NET; simplemente es un ejemplo de la definición de clase.
Public Class Perro
Dim Altura As Decimal
Dim Peso As Decimal
Dim Color As String
Sub Caminar(ByVal Pasos As Integer)
End Sub
Sub Ladrar()
End Sub
Sub Comer()
End Sub
End Class
El siguiente ejemplo define una nueva clase, Persona, con dos partes de información relevante asociadas: el nombre de la persona, su fecha de nacimiento y un Método que calcula la edad de la persona. A pesar de que la clase Persona se define en el ejemplo, no existe aún el objeto Persona. Deberán ser creados.
Public Class Persona
Private mstrNombre As String
Private mdtFechaNacimiento As Date
Public Function Edad() As Integer
Return DateDiff(DateInterval.Year, mdtFechaNacimiento, Now())
End Function
End Class
Una clase es un tipo definido por el usuario en contraposición a un tipo proporcionado por el sistema. Al definir una clase, en realidad crea un nuevo tipo en su aplicación. Los elementos o propiedades más importantes de este modelo son: (1) Abstracción. (2) Encapsulamiento. (3) Modularidad. (4) Jerarquía. (5) Polimorfismo. Como sugiere Booch, si alguno de estos elementos no existe se dice que el modelo no es orientado a objetos.
3.2. Abstracción
La abstracción es uno de los medios más importantes, mediante el cual las personas se enfrentan con la complejidad inherente al software. La abstracción es la propiedad que permite representar las características esenciales de un objeto, sin preocuparse de las restantes características, no esenciales. Abstracción es la técnica de quitarle a una idea o a un objeto todos los acompañamientos innecesarios hasta que los deja en una forma esencial y mínima. Una buena abstracción elimina todos los detalles poco importantes y le permite enfocarse y concentrarse en los detalles importantes.
Una abstracción se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento esencial de un objeto de su implementación. Definir una abstracción significa describir una entidad del mundo real, no importa lo compleja que pueda ser y, a continuación, utilizar esta descripción en un programa.
El elemento clave de la programación orientada a objetos es la clase. Una clase se puede definir como una descripción abstracta de un grupo de objetos, cada uno de los cuales se diferencia por su estado específico y por la posibilidad de realizar una serie de operaciones. Por ejemplo, una pluma estilográfica es un objeto que tiene un estado, llena de tinta o vacía, y sobre la cual se pueden realizar algunas operaciones: escribir, poner o quitar la tapa, llenar de tinta si está vacía, etc.
La idea de escribir programas definiendo una serie de abstracciones no es nueva, pero el uso de clases para gestionar dichas abstracciones en lenguajes de programación ha facilitado considerablemente su aplicación.
La abstracción es un principio de software importante. Una clase bien diseñada expone un conjunto mínimo de métodos cuidadosamente considerados que proporcionan el comportamiento esencial de una clase en una forma fácil de usar. Crear buenas abstracciones de software no es fácil. Encontrar buenas abstracciones generalmente requiere de un entendimiento muy claro del problema y de su contexto, gran claridad de pensamiento y amplia experiencia.
Existe un principio muy importante relacionado con la abstracción, y esta es, la Dependencia mínima. Las mejores abstracciones de software hacen que las cosas complejas sean simples. Logran esto al ocultar por completo los aspectos no esenciales de una clase. Estos aspectos no esenciales, una vez que han sido debidamente ocultados, no se pueden ver, ni usar, ni depender de ellos. Este principio de dependencia mínima es lo que hace que la abstracción sea tan importante. El cambio es normal en el desarrollo de software. Lo mejor que puede hacer es minimizar el impacto de un cambio cuando éste sucede. Y cuanto menos dependa de algo, menos se verá afectado cuando cambie.
3.3. Encapsulamiento
El encapsulamiento o encapsulación es la propiedad que permite asegurar que el contenido de la información de un objeto está oculta al mundo exterior: el objeto A no conoce lo que hace el objeto B, y viceversa. La encapsulación, conocida también como ocultación de la información, en esencia, es el proceso de ocultar todos los secretos de un objeto que no contribuyen a sus características esenciales.
La encapsulación permite la división de un programa en módulos. Estos módulos se implementan mediante clases, de forma que una clase representa la encapsulación de una abstracción. En la práctica, esto significa que cada clase debe tener dos partes: una interfaz y una implementación. La interfaz de una clase captura sólo su vista externa y la implementación contiene la representación de la abstracción, así como los mecanismos que realizan el comportamiento adecuado.
Encapsulación es la capacidad de contener y controlar el acceso a un grupo de elementos asociados. Las clases proporcionan una de las formas más comunes para encapsular elementos. En el siguiente ejemplo, la clase BankAccount encapsula los métodos, campos y propiedades que se describen en una cuenta bancaria. Sin una encapsulación, se necesitaría declarar procedimientos y variables por separado para almacenar y administrar información para la cuenta bancaria, y sería difícil trabajar con más de una cuenta bancaria a la vez. La encapsulación le permite utilizar los datos y procedimientos en la clase BankAccount como una unidad. Se puede trabajar con varias cuentas bancarias al mismo tiempo sin confusión, debido a que cada cuenta está representada por una instancia única de la clase.
La encapsulación también le permite controlar la forma en que se utilizan los datos y los procedimientos. Puede utilizar modificadores de acceso, como Private o Protected, para evitar que los procedimientos externos ejecuten métodos de clase o lean y modifiquen datos en propiedades y campos. Usted debe declarar los detalles internos de una clase como Private para evitar que sean utilizados fuera de su clase; a esta técnica se le llama ocultamiento de datos. En la clase BankAccount, la información del cliente, como el saldo de la cuenta, se protege de esta forma. Una de las reglas básicas de la encapsulación es que los datos de la clase sólo se pueden modificar o recuperar a través de los procedimientos o métodos Property. Ocultar los detalles de implementación de sus clases evita que se usen de maneras no deseadas, y le permite modificar esos elementos posteriormente sin riesgo de tener problemas de compatibilidad. Por ejemplo, versiones posteriores de la clase BankAccount enlistadas más adelante, podrían cambiar el tipo de datos del campo AccountBalance sin peligro de dañar la aplicación que depende de que este campo tenga un tipo de dato específico.
Class BankAccount
Private AccountNumber As String
Private AccountBalance As Decimal
Private HoldOnAccount As Boolean = False
Public Sub PostInterest()
' Add code to calculate the interest for this account.
End Sub
ReadOnly Property Balance() As Decimal
Get
Return AccountBalance 'Returns the available balance.
End Get
End Property
End Class
3.4. Modularidad
La modularidad es la propiedad que permite subdividir una aplicación en partes más pequeñas, llamadas módulos, cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes.
La modularización consiste en dividir un programa en módulos que se puedan compilar por separado, pero que tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la modularidad de diversas formas.
La modularidad es la propiedad de un sistema que permite su descomposición en un conjunto de módulos cohesivos y débilmente acoplados. Por supuesto no todos los módulos son iguales: tomar un programa monolítico y separarlo de forma aleatoria en archivos no es óptimo. Se debe tener en cuenta los conceptos asociados de dependencia, acoplamiento, cohesión, interfaz, encapsulación y abstracción. Una vez identificado lo que es un buen módulo, se puede contemplar la reutilización de un buen módulo como componente.
El módulo A depende del módulo B si cualquier cambio en el módulo B implica que el módulo A también tenga que ser modificado. A veces se dice que el módulo A es un cliente del módulo B, o que el módulo B actúa como servidor del módulo A. En general, es normal que un mismo módulo sea tanto cliente como servidor. Esto significa, que depende de algunos módulos, mientras que otros módulos dependen de él. Incluso es posible que un par de módulos se tengan uno al otro de cliente; sin embargo, éste es un ejemplo de dependencia circular, que debe evitarse cuando sea posible debido a que impide la reutilización.
La dependencia a veces se conoce como acoplamiento. Un sistema con muchas dependencias tiene fuerte acoplamiento. Los buenos sistemas tienen débil acoplamiento, porque en ese caso los cambios en una parte del sistema son menos probables de propagarse a través del sistema.
Los módulos correctos a menudo tienen la propiedad de que sus interfaces proporcionan una abstracción de algún elemento conocido de manera intuitiva que puede, no obstante, ser difícil de implementar. Este tipo de módulos se dice que tienen una fuerte cohesión. El módulo realiza un conjunto coherente de cosas, pero dentro de lo posible el desarrollador del cliente está protegido de la información irrelevante relativa a cómo el módulo hace lo que hace.
Resumiendo se puede decir que la abstracción se produce cuando el cliente de un módulo no necesita saber más de lo que hay en la interfaz. Encapsulación es cuando un cliente de un módulo no es capaz de saber más de lo que hay en la interfaz. Si un módulo, de cualquier tamaño y complejidad, es una buena abstracción, tiene fuerte cohesión y débil acoplamiento, puede ser factible reutilizarlo en sistemas posteriores, o sustituirlo en el sistema existente.
3.5. Jerarquía
La jerarquía es una propiedad que permite la ordenación de las abstracciones. Las dos jerarquías más importantes de un sistema complejo son: estructura de clases (jerarquía “es-un” (is-a): generalización/especialización) y estructura de objetos (jerarquía “parte-de” (part-of): agregación).
Las jerarquías de generalización/especialización se conocen como herencia. Básicamente, la herencia define una relación entre clases, en donde una clase comparte la estructura o comportamiento definido en una o más clases, herencia simple y herencia múltiple, respectivamente.
La agregación es el concepto que permite el agrupamiento físico de estructuras relacionadas lógicamente. Así, un camión se compone de ruedas, motor, sistema de transmisión y chasis; en consecuencia, camión es una agregación, y ruedas, motor, transmisión y chasis son agregados de camión.
3.6. Polimorfismo
La quinta propiedad significativa de la orientación a objetos es el polimorfismo. Es la propiedad que indica, literalmente, la posibilidad de que una entidad tome muchas formas. En términos prácticos, el polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento de programa y realizar la misma operación de diferentes formas, según sea el objeto que se referencia en ese momento.
Por ejemplo, cuando se describe la clase mamíferos se puede observar que la operación comer es una operación fundamental en la vida de los mamíferos, de modo que cada tipo de mamífero debe poder realizar la operación o función comer. Por otra parte, una cabra o una vaca que pastan en un campo, un niño que se come un caramelo y un león que devora a otro animal, son diferentes formas que utilizan diferentes mamíferos para realizar la misma función comer.
El polimorfismo adquiere su máxima expresión en la derivación o extensión de clases, es decir, cuando se obtiene una clase a partir de una clase ya existente, mediante la propiedad de derivación de clases o herencia.
El polimorfismo requiere ligadura tardía o postergada, también llamada dinámica, y esto sólo se puede producir en lenguajes de programación orientados a objetos. Los lenguajes no orientados a objetos soportan ligadura temprana o anterior, también llamada estática, esto significa que el compilador genera una llamada a un nombre específico de función y el enlazador (linker) resuelve la llamada a la dirección absoluta del código que se ha de ejecutar. En la orientación a objetos, el programa no puede determinar la dirección del código hasta el momento de la ejecución. Cuando se envía un mensaje a un objeto, el código que se llama no se determina hasta el momento de la ejecución. El compilador asegura que la función existe y realiza verificación de tipos de los argumentos y del valor de retorno, pero no conoce el código exacto a ejecutar.
La orientación a objetos beneficia a los desarrolladores debido a que: (1) Los programas son fáciles de diseñar debido a que los objetos reflejan elementos del mundo real. (2) Las aplicaciones son más sencillas para los usuarios debido a que los datos innecesarios están ocultos. (3) Los objetos son unidades autocontenidas. (4) La productividad se incrementa debido a que puede reutilizar el código. (5) Los sistemas son fáciles de mantener y se adaptan a las cambiantes necesidades de negocios. (6) Es más fácil crear nuevos tipos de objetos a partir de los ya existentes. (6) Simplifica los datos complejos. (7) Reduce la complejidad de la transacción. (8) Confiabilidad. (9) Robustez. (10) Capacidad de ampliación.
3.7. Otras propiedades
El modelo objeto ideal no sólo tiene las propiedades anteriormente citadas sino que es conveniente que soporte, además, estas otras propiedades:
a) Concurrencia (multitarea). El lenguaje soporta la creación de procesos paralelos independientes del sistema operativo. Esta propiedad simplificará la transportabilidad de un sistema de tiempo real de una plataforma a otra.
b) Persistencia. Los objetos deben poder ser persistentes; es decir, los objetos han de permanecer después de la ejecución del programa.
c) Genericidad. Las clases parametrizadas, mediante plantillas o unidades genéricas, sirven para soportar un alto grado de reutilización. Estos elementos genéricos se diseñan con parámetros formales, que se instanciarán con parámetros reales, para crear instancias de módulos que se compilan y enlazan, y ejecutan posteriormente.
d) Manejo de Excepciones. Se deben detectar, informar y manejar condiciones excepcionales utilizando construcciones del lenguaje. Esta propiedad añadida al soporte de tolerancia a fallos del software permitirá una estrategia de diseño eficiente.
4. TAXONOMÍA DE LENGUAJES ORIENTADOS A OBJETOS
Una taxonomía de lenguajes de programación con propiedades de orientación a objetos fue creada por Wegner. La clasificación incluye los siguientes grupos: (1) Basado en objetos. Un lenguaje de programación es basado en objetos si su sintaxis y semántica soportan la creación de objetos que tienen las propiedades descritas en el punto anterior. Por ejemplo: Ada-83, Clipper 5.2, Visual Basic 4/5/6. (2) Basado en clases. Si un lenguaje de programación es basado en objetos y soporta además la creación de clases, se considera basado en clases. Por ejemplo: Clu. (3) Orientación a objetos. Un lenguaje de programación orientado a objetos es un lenguaje basado en clases que soporta también herencia. Por ejemplo: Visual Basic .NET, C# .NET, C++, Java, Delphi, Eiffel, Simula.
5. CONCEPTOS ORIENTADOS A OBJETOS
Coad y Yourdon definen el término orientación a objetos de la siguiente forma:
Orientación a Objetos = objetos + clasificación + herencia + comunicación
5.1. Clases y Objetos
Un modelo orientado a objetos de software de computadora debe exhibir abstracciones de datos y procedimientos que conducen a una modularidad eficaz. Una clase es un concepto orientado a objetos que encapsula las abstracciones de datos y procedimientos que se requieren para describir el contenido y comportamiento de alguna entidad del mundo real.
Las abstracciones de datos, especialmente los atributos, que describen la clase están encerradas por una “muralla” de abstracciones procedimentales llamadas operaciones, métodos o servicios, capaces de manipular los datos de alguna manera. La única forma de alcanzar los atributos y operar sobre ellos, es ir a través de alguno de los métodos que forman la muralla. Por lo tanto, la clase encapsula datos, al interior de la muralla, y el proceso que manipula los datos, los métodos que componen la muralla. Esto posibilita la ocultación de información y reduce el impacto de efectos colaterales asociados a cambios.
5.2. Atributos
Los atributos están asociados a clases y objetos, y describen la clase o el objeto de alguna manera. Las entidades de la vida real están a menudo descritas con palabras que indican características estables. La mayoría de los objetos físicos tienen características tales como forma, peso, color y tipo de material. Las personas tienen características como fecha de nacimiento, padres, nombre y color de los ojos. Una característica puede verse como una relación binaria entre una clase y cierto dominio.
La “relación” binaria implica que un atributo puede tomar un valor definido por un dominio enumerado. En la mayoría de los casos, un dominio es simplemente un conjunto de valores específicos. Por ejemplo, suponga que una clase Coche tiene un atributo color. El dominio de valores de color es blanco, negro, plata, gris, azul, rojo, amarillo, verde.
Las características, o valores del dominio, pueden aumentarse asignando un valor por defecto, o característica, a un atributo. Por ejemplo, el atributo color tiene el valor por defecto negro. Los valores asignados a los atributos de un objeto hacen a ese objeto ser único.
5.3. Operaciones, métodos y servicios
Un objeto encapsula datos, representados como una colección de atributos, y los algoritmos que procesan estos datos. Estos algoritmos son llamados operaciones, métodos o servicios y pueden ser vistos como módulos en un sentido convencional.
Cada uno de los métodos encapsulados por un objeto proporciona una representación de uno de los comportamientos del objeto. Por ejemplo, el método DeterminarColor para el objeto Coche extraerá el color almacenado en el atributo color. La consecuencia de la existencia de ese método es que la clase coche ha sido diseñada para recibir un estímulo, mensaje, que requiere el color de una instancia particular de una clase. Cada vez que un objeto recibe un estímulo, éste inicia un cierto comportamiento, que puede ser tan simple como determinar el color del coche o tan complejo como la iniciación de una cadena de estímulos que se pasan entre una variedad e objetos diferentes. Siempre que un objeto es estimulado por un mensaje, inicia algún comportamiento ejecutando un método.
5.4. Mensajes
Los mensajes son el medio a través del cual interactúan los objetos. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta un método.
Una operación dentro de un objeto emisor genera un mensaje de la forma:
destino.operación (parámetros)
donde destino define al objeto receptor el cual es estimulado por el mensaje, operación se refiere al método que recibe el mensaje y parámetros proporciona información requerida para el éxito de la operación.
Los mensajes proporcionan una visión interna del comportamiento de objetos individuales, y del sistema orientado a objetos como un todo. El paso de mensajes mantiene comunicado un sistema orientado a objetos.
