Conceptos y principios orientado a objetos

Fecha: 19/Jul/2005 (15/07/2005)
Autor: Arbis Percy Reyes Paredes
E_mail: bigpercynet@hotmail.com
Blog: http://percyreyes.blogspot.com
¡¡ Los peruanos SÍ podemos !!

Comentarios previos.... algo de historia

Vivimos 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 usamos. 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 nos 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 90, 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 (de componente 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 más fácilmente escalables (pueden crearse grandes sistemas ensamblando subsistemas reutilizables).

Hacia mediados de los 80, 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 para programar 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.

Las implementaciones orientadas a objetos ocultan datos, lo cual significa que muestran únicamente los comportamientos a los usuarios y ocultan 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 autocontenidos. 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, como el sistema operativo Microsoft® Windows®.

1. El paradigma orientado a objetos

Durante muchos años el término Orientado a Objetos (OO) se usó para referirse a un enfoque de desarrollo de software que usaba uno de los lenguajes orientados a objetos (Ada 95, C++, Eiffel, Smalltalk, etc.). En el libro The Structure of Scientific Revolutions, el historiador Thomas K describía un paradigma como un conjunto de teorías, estándar 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 programación orientada a objetos es un nuevo paradigma. La orientación a objetos fuerza a reconsiderar nuestro pensamiento sobre la computación, sobre lo que significa realizar computación y sobre cómo se estructura la información dentro 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:

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.

2. Orientación a Objetos

La orientación a objetos puede describirse como el conjunto de disciplinas que desarrollan y modelizan 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 creamos 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 cosas:


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 nuestro objeto.

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 nuestro objeto aunque cambiemos la implementación, siempre que no cambiemos la interfaz. Siempre que se mantengan sin cambio nuestro nombre de método, su lista de parámetro y el tipo de datos de devolución, podremos cambiar la implementación totalmente.

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 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.

¿Qué es una 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

Vamos con otro ejemplo. 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.

Ahora que ya sabéis todo esto, vamos con os elementos (propiedades) más importantes de este modelo. Estas son:

Como sugiere Booch, si alguno de estos elementos no existe se dice que el modelo no es orientado a objetos.

2.1. Abstracción:

La abstracción es uno de los medios más importantes, mediante el cual nos enfrentamos 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.

Los lenguajes orientados a objetos proporcionan la Encapsulación. La encapsulación se puede utilizar para aplicar el concepto de Abstracción.

2.2 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 (también se conoce 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, usted 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. Usted 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

2.3 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: Abstracción es cuando un 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.

2.4 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.

2.5 Polimorfismo

La quinta propiedad significativa de los lenguajes de programación orientados 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 POO, 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.

y ¿Cuales son los beneficios? , buena pregunta eh ...!!!

En resumen, la programación orientada a objetos beneficia a los desarrolladores debido a que:

Vea también: Factores en la calidad del sofware

2.6 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:

3. 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:

4. Conceptos de orientación 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

4.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 (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 (dentro 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.

Nota: Un objeto encapsula datos (atributos) y los métodos (operaciones, métodos o servicios) que manipulan esos datos.

4.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, supongamos 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 (valores del dominio) pueden aumentarse asignando un valor por defecto (característica) a un atributo. Por ejemplo, el atributo color tiene el valor por defecto negro.

Nota: Los valores asignados a los atributos de un objeto hacen a ese objeto ser único.

4.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.

Nota: Siempre que un objeto es estimulado por un mensaje, inicia algún comportamiento ejecutando un método.

4.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.

Nota: El paso de mensajes mantiene comunicado un sistema orientado a objetos.

Hemos terminado. Quieres seguir abstrayéndote..??? jejeje..., entonces, te recomiendo este artículo (Identificación de un modelo de objetos) para que puedas afianzar los conceptos sobre modelo de objetos.

No olvides de darme tu voto en PanoramaBox, de esta manera seguiré compartiendo contigo lo que voy aprendiendo. Gracias.

Arbis Percy Reyes Paredes es peruano, tiene 21 años y se dedica a la construcción de software de manera profesional, joven desarrollador de aplicaciones Web y Servicios Web XML en VB .NET y C# .NET con bases de datos SQL Server 2000, aplicaciones basadas en Windows con VB .NET y C# .NET, VB 6.0, y controles y bibliotecas ActiveX; actualmente estudia en la Universidad Nacional de Trujillo, la carrera de Ingeniería de Sistemas. Le encanta el desarrollo de aplicaciones para dispositivos móviles tanto como la programación gráfica y programación avanzada de videojuegos.

ir al índice