Un diagrama de colaboración' en las versiones de UML 1.x es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboracion, también llamados diagramas de comunicación, muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.
Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común.
Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace".
Un diagrama de comunicación es también un diagrama de clases que contiene roles de clasificador y roles de asociación en lugar de sólo clasificadores y asociaciones. Los roles de clasificador y los de asociación describen la configuración de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicación. Cuando se instancia una comunicación, los objetos están ligados a los roles de clasificador y los enlaces a los roles de asociación. El rol de asociación puede ser desempeñado por varios tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales del procedimiento. Los símbolos de enlace pueden llevar estereotipos para indicar enlaces temporales.
Utilidad
Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.
Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.
Tipos de mensajes
Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.
También se representa la respuesta a un mensaje con una flecha discontinua.
Pueden ser usados en dos formas:
De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.
martes, 17 de julio de 2012
Driagrama de Secuencias
Utilidad
Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.
Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.
Tipos de mensajes
Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.
También se representa la respuesta a un mensaje con una flecha discontinua.
Pueden ser usados en dos formas:
De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.
Estructura
Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje.
Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.
Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.
Tipos de mensajes
Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.
También se representa la respuesta a un mensaje con una flecha discontinua.
Pueden ser usados en dos formas:
De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.
Estructura
Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje.
Definición de polimorfismo
En programación orientada a objetos el polimorfismo se refiere a la posibilidad de enviar un mensaje a un grupo de objetos cuya naturaleza puede ser heterogénea. El único requisito que deben cumplir los objetos que se utilizan de manera polimórfica es saber responder al mensaje que se les envía.
La apariencia del código puede ser muy diferente dependiendo del lenguaje que se utilice, más allá de las obvias diferencias sintácticas.
Por ejemplo, en un lenguaje de programación que cuenta con un sistema de tipos dinámico (en los que las variables pueden contener datos de cualquier tipo u objetos de cualquier clase) como Smalltalk no se requiere que los objetos que se utilizan de modo polimórfico sean parte de una jerarquía de clases.
En lenguajes basados en clases y con un sistema de tipos de datos fuerte (independientemente de si la verificación se realiza en tiempo de compilación o de ejecución), es posible que el único modo de poder utilizar objetos de manera polimórfica sea que compartan una raíz común, es decir, una jerarquía de clases, ya que esto proporciona la compatibilidad de tipos de datos necesaria para que sea posible utilizar una misma variable de referencia (que podrá apuntar a objetos de diversas subclases de dicha jerarquía) para enviar el mismo mensaje (o un grupo de mensajes) al grupo de objetos que se tratan de manera polimórfica.
En Java, es frecuente y profusamente aconsejada la utilización de interfaces (que es un mecanismo del lenguaje que se emplea por medio de la palabra clave Interface) para proveer la necesaria concordancia de tipos para hacer posible el polimorfismo, también como un contrato que debe cumplir cualquier clase que implemente una cierta interfaz y como una forma de documentación para los desarrolladores. A veces, en la literatura que refiere específicamente a Java se hace mención a "herencia y polimorfismo de interfaces", lo que no concuerda con los conceptos de la programación orientada a objetos porque una clase que implementa una interfaz sólo obtiene su tipo de datos y la obligación de implementar sus métodos, no obtiene comportamiento ni de atributos. Esto muchas veces resulta paradójico porque en Java frecuentemente se utiliza la mal llamada "herencia de interfaces" para dotar a una clase con un tipo adicional (o varios) para que su uso en combinación con la agregación (colaboración o composición) permita evitar la necesidad de la herencia múltiple y favorezca una utilización más amplia del polimorfismo.
No obstante, el uso de una jerarquía de clases como paso previo, es muy habitual incluso en aquellos lenguajes en los que es posible prescindir de tal jerarquía, ya que, desde una perspectiva conceptual, se puede decir que al pertenecer los "objetos polimórficos" a subclases de una misma jerarquía, se asegura la equivalencia semántica de los mensajes que se invocarán de modo polimórfico. Por esto, en programación orientada a objetos a veces se denomina al polimorfismo como "polimorfismo de subclase (o de subtipo)".
En resumen, en la programación orientada a objetos, la esencia del polimorfismo no atañe a la clase o prototipo de la que provienen los objetos. Aún así, en los lenguajes basados en clases, es habitual (y en algunos tal vez sea el único modo) que dichos objetos pertenezcan a subclases pertenecientes a una misma jerarquía. Entonces, el polimorfismo debe verse como una forma flexible de usar un grupo de objetos (como si fueran sólo uno). Podría decirse que el polimorfismo en esencia refiere al comportamiento de los objetos, no a su pertenencia a una jerarquía de clases (o a sus tipos de datos).
Lo anterior se hace aún más evidente en lenguajes de programación orientada a objetos basados en prototipos, como Self, en los que las clases no existen.
Además, es importante remarcar que si un cierto grupo de objetos pueden utilizarse de manera polimórfica es porque, en última instancia, todos ellos saben responder a un cierto mensaje (o a varios), pero dado que esos mismos objetos generalmente contendrán otros métodos (que otros objetos en dicho grupo no contienen), difícilmente se pueda decir lisa y llanamente que los objetos son polimórficos; lo correcto es decir que esos objetos se pueden utilizar de modo polimórfico para un cierto conjunto de mensajes.
Un ejemplo. Podemos crear dos clases distintas: Pez y Ave que heredan de la superclase Animal. La clase Animal tiene el método abstracto mover que se implementa de forma distinta en cada una de las subclases (peces y aves se mueven de forma distinta). Entonces, un tercer objeto puede enviar el mensaje mover a un grupo de objetos Pez y Ave por medio de una variable de referencia de clase Animal, haciendo así un uso polimórfico de dichos objetos respecto del mensaje mover.
El concepto de polimorfismo, desde una perspectiva más general, se puede aplicar tanto a funciones como a tipos de datos. Así nacen los conceptos de funciones polimórficas y tipos polimórficos. Las primeras son aquellas funciones que pueden evaluarse o ser aplicadas a diferentes tipos de datos de forma indistinta; los tipos polimórficos, por su parte, son aquellos tipos de datos que contienen al menos un elemento cuyo tipo no está especificado.
La apariencia del código puede ser muy diferente dependiendo del lenguaje que se utilice, más allá de las obvias diferencias sintácticas.
Por ejemplo, en un lenguaje de programación que cuenta con un sistema de tipos dinámico (en los que las variables pueden contener datos de cualquier tipo u objetos de cualquier clase) como Smalltalk no se requiere que los objetos que se utilizan de modo polimórfico sean parte de una jerarquía de clases.
En lenguajes basados en clases y con un sistema de tipos de datos fuerte (independientemente de si la verificación se realiza en tiempo de compilación o de ejecución), es posible que el único modo de poder utilizar objetos de manera polimórfica sea que compartan una raíz común, es decir, una jerarquía de clases, ya que esto proporciona la compatibilidad de tipos de datos necesaria para que sea posible utilizar una misma variable de referencia (que podrá apuntar a objetos de diversas subclases de dicha jerarquía) para enviar el mismo mensaje (o un grupo de mensajes) al grupo de objetos que se tratan de manera polimórfica.
En Java, es frecuente y profusamente aconsejada la utilización de interfaces (que es un mecanismo del lenguaje que se emplea por medio de la palabra clave Interface) para proveer la necesaria concordancia de tipos para hacer posible el polimorfismo, también como un contrato que debe cumplir cualquier clase que implemente una cierta interfaz y como una forma de documentación para los desarrolladores. A veces, en la literatura que refiere específicamente a Java se hace mención a "herencia y polimorfismo de interfaces", lo que no concuerda con los conceptos de la programación orientada a objetos porque una clase que implementa una interfaz sólo obtiene su tipo de datos y la obligación de implementar sus métodos, no obtiene comportamiento ni de atributos. Esto muchas veces resulta paradójico porque en Java frecuentemente se utiliza la mal llamada "herencia de interfaces" para dotar a una clase con un tipo adicional (o varios) para que su uso en combinación con la agregación (colaboración o composición) permita evitar la necesidad de la herencia múltiple y favorezca una utilización más amplia del polimorfismo.
No obstante, el uso de una jerarquía de clases como paso previo, es muy habitual incluso en aquellos lenguajes en los que es posible prescindir de tal jerarquía, ya que, desde una perspectiva conceptual, se puede decir que al pertenecer los "objetos polimórficos" a subclases de una misma jerarquía, se asegura la equivalencia semántica de los mensajes que se invocarán de modo polimórfico. Por esto, en programación orientada a objetos a veces se denomina al polimorfismo como "polimorfismo de subclase (o de subtipo)".
En resumen, en la programación orientada a objetos, la esencia del polimorfismo no atañe a la clase o prototipo de la que provienen los objetos. Aún así, en los lenguajes basados en clases, es habitual (y en algunos tal vez sea el único modo) que dichos objetos pertenezcan a subclases pertenecientes a una misma jerarquía. Entonces, el polimorfismo debe verse como una forma flexible de usar un grupo de objetos (como si fueran sólo uno). Podría decirse que el polimorfismo en esencia refiere al comportamiento de los objetos, no a su pertenencia a una jerarquía de clases (o a sus tipos de datos).
Lo anterior se hace aún más evidente en lenguajes de programación orientada a objetos basados en prototipos, como Self, en los que las clases no existen.
Además, es importante remarcar que si un cierto grupo de objetos pueden utilizarse de manera polimórfica es porque, en última instancia, todos ellos saben responder a un cierto mensaje (o a varios), pero dado que esos mismos objetos generalmente contendrán otros métodos (que otros objetos en dicho grupo no contienen), difícilmente se pueda decir lisa y llanamente que los objetos son polimórficos; lo correcto es decir que esos objetos se pueden utilizar de modo polimórfico para un cierto conjunto de mensajes.
Un ejemplo. Podemos crear dos clases distintas: Pez y Ave que heredan de la superclase Animal. La clase Animal tiene el método abstracto mover que se implementa de forma distinta en cada una de las subclases (peces y aves se mueven de forma distinta). Entonces, un tercer objeto puede enviar el mensaje mover a un grupo de objetos Pez y Ave por medio de una variable de referencia de clase Animal, haciendo así un uso polimórfico de dichos objetos respecto del mensaje mover.
El concepto de polimorfismo, desde una perspectiva más general, se puede aplicar tanto a funciones como a tipos de datos. Así nacen los conceptos de funciones polimórficas y tipos polimórficos. Las primeras son aquellas funciones que pueden evaluarse o ser aplicadas a diferentes tipos de datos de forma indistinta; los tipos polimórficos, por su parte, son aquellos tipos de datos que contienen al menos un elemento cuyo tipo no está especificado.
Definicion Metaclases
En programación orientada a objetos, una metaclase es una clase cuyas instancias son clases. En otras palabras, como los objetos son instancias de una clase, las clases son instancias de una metaclase.
No todos los lenguajes orientados a objetos soportan metaclases. Además, los lenguajes que lo soportan tienen sus propias reglas que definen como los objetos, clases y metaclases interactúan.
Las metaclases permiten saber el tipo exacto de un objetocuando lo único que se tiene es un manejador a su clase base. suministra un conjunto de metaclases con este objetivo:
Class, Field, Method, Constructor,
etc. Asímismo, la clase
Object
posee el método
getClass(),
que permite obtener un objeto de tipo
Class
con toda la información sobre el verdadero objeto apuntado.* El objeto
.class
correspondiente a una clase cualquiera
Xxx
puede obtenerse sencillamente mediante la expresión
Xxx.class
.* La verdad es que, durante la ejecución, por cada clase que haycargada, Java mantiene un objeto oculto de tipo
Class
quedescribe a dicha clase.* Ese objeto de tipo
Class
se utiliza en tiempo de ejecución parachequear las conversiones de tipo efectuadas por el programador.* El operador
instanceof
nos dice si un objeto es instancia deuna clase determinada o no.
No todos los lenguajes orientados a objetos soportan metaclases. Además, los lenguajes que lo soportan tienen sus propias reglas que definen como los objetos, clases y metaclases interactúan.
Las metaclases permiten saber el tipo exacto de un objetocuando lo único que se tiene es un manejador a su clase base. suministra un conjunto de metaclases con este objetivo:
Class, Field, Method, Constructor,
etc. Asímismo, la clase
Object
posee el método
getClass(),
que permite obtener un objeto de tipo
Class
con toda la información sobre el verdadero objeto apuntado.* El objeto
.class
correspondiente a una clase cualquiera
Xxx
puede obtenerse sencillamente mediante la expresión
Xxx.class
.* La verdad es que, durante la ejecución, por cada clase que haycargada, Java mantiene un objeto oculto de tipo
Class
quedescribe a dicha clase.* Ese objeto de tipo
Class
se utiliza en tiempo de ejecución parachequear las conversiones de tipo efectuadas por el programador.* El operador
instanceof
nos dice si un objeto es instancia deuna clase determinada o no.
Definicion de Abstraccion
hay ocasiones, cuando se desarrolla una jerarquía de clases en que algún
comportamiento está presente en todas ellas pero se materializa de forma
distinta para cada una. Por ejemplo, pensemos en una estructura de
clases para manipular figuras geométricas. Podríamos pensar en tener una
clase genérica, que podría llamarse Figura geométrica y una serie de
clases que extienden a la anterior que podrían ser Círculo, Polígono,
etc. Podría haber un método dibujar dado que sobre todas las figuras
puede llevarse a cabo esta acción, pero las operaciones concretas para
llevarla a cabo dependen del tipo de figura en concreto (de su clase).
Por otra parte la acción dibujar no tiene sentido para la clase genérica
Figura geométrica, porque esta clase representa una abstracción del
conjunto de figuras posibles.
Concepto de mensajes
Veamos detenidamente qué es un mensaje:
Un único objeto de por sí no es demasiado útil. En general, un objeto es un componente más de un programa o una aplicación que contiene otros muchos objetos. Con esta interacción los programadores
conseguimos una funcionalidad de mayor orden y podemos modelar comportamientos mucho más
complejos.
La Ambulancia que teníamos aparcada no es más que chapa por sí sola, es incapaz de desarrollar ninguna actividad. Es útil cuando otro objeto (conductor, por ejemplo) la conduce.
Los objetos de un programa interactúan y se comunican entre ellos por medio de mensajes. Cuando un objeto A quiere que otro objeto B ejecute una de sus funciones miembro (métodos de B), el objeto A manda un mensaje al objeto B. (¿complejo? :-)
A veces el objeto que recibe el mensaje necesita más información, si le decimos que queremos subir la velocidad, deberíamos además, decirle la velocidad exacta, por ejemplo. Esta información se pasa junto con el mensaje en forma de parámetro.
Partes del mensaje si quisiéramos (Yo) decirle a MiAmbulancia que suba la velocidad en 10 km/h:
Los mensajes proporcionan dos ventajas importantes:
Un único objeto de por sí no es demasiado útil. En general, un objeto es un componente más de un programa o una aplicación que contiene otros muchos objetos. Con esta interacción los programadores
conseguimos una funcionalidad de mayor orden y podemos modelar comportamientos mucho más
complejos.
La Ambulancia que teníamos aparcada no es más que chapa por sí sola, es incapaz de desarrollar ninguna actividad. Es útil cuando otro objeto (conductor, por ejemplo) la conduce.
Los objetos de un programa interactúan y se comunican entre ellos por medio de mensajes. Cuando un objeto A quiere que otro objeto B ejecute una de sus funciones miembro (métodos de B), el objeto A manda un mensaje al objeto B. (¿complejo? :-)
A veces el objeto que recibe el mensaje necesita más información, si le decimos que queremos subir la velocidad, deberíamos además, decirle la velocidad exacta, por ejemplo. Esta información se pasa junto con el mensaje en forma de parámetro.
Partes del mensaje si quisiéramos (Yo) decirle a MiAmbulancia que suba la velocidad en 10 km/h:
- El objeto al cual se manda el mensaje (MiAmbulancia).
- El método o función miembro que debe ejecutar (SubirVelocidad()).
- Los parámetros que necesita ese método (10).
Los mensajes proporcionan dos ventajas importantes:
- El comportamiento de un objeto está completamente determinado (a excepción del acceso directo a variables miembro públicas) por sus métodos, así que los mensajes representan todas las posibles interacciones que pueden realizarse entre objetos.
- Los objetos no necesitan formar parte del mismo proceso, ni siquiera residir en un mismo ordenador para mandarse mensajes entre ellos (y de esta forma interactuar).
Concepto de Clases
En la programación orientada a objetos, una clase es una construcción que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos los objetos de la clase comparten. Un objeto de una determinada clase se denomina una instancia de la clase. La clase que contiene (y se utilizó para crear) esa instancia se puede considerar como del tipo de ese objeto, por ejemplo, una instancia del objeto de la clase "Persona" sería del tipo "Persona".
Una clase por lo general representa un sustantivo, como una persona, lugar o (posiblemente bastante abstracta) cosa - es el modelo de un concepto dentro de un programa de computadora. Fundamentalmente, encapsula el estado y el comportamiento del concepto que representa. Encapsula el estado a través de marcadores de datos llamados atributos (o variables miembro o variables de instancia), y encapsula el comportamiento a través de secciones de código reutilizables llamados métodos.
Más técnicamente, una clase es un conjunto coherente que consiste en un tipo particular de metadatos. Una clase tiene tanto una interfaz y una estructura. La interfaz describe cómo interactuar con la clase y sus instancias con métodos, mientras que la estructura describe cómo los datos se dividen en atributos dentro de una instancia. Una clase también puede tener una representación (metaobjeto) en tiempo de ejecución, que proporciona apoyo en tiempo de ejecución para la manipulación de los metadatos relacionados con la clase. En el diseño orientado a objetos, una clase es el tipo más específico de un objeto en relación con una capa específica.
Los lenguajes de programación que soportan clases difieren sutilmente en su soporte para diversas características relacionadas con clases. La mayoría soportan diversas formas de herencia. Muchos lenguajes también soportan características para proporcionar encapsulación, como especificadores de acceso.
Una clase por lo general representa un sustantivo, como una persona, lugar o (posiblemente bastante abstracta) cosa - es el modelo de un concepto dentro de un programa de computadora. Fundamentalmente, encapsula el estado y el comportamiento del concepto que representa. Encapsula el estado a través de marcadores de datos llamados atributos (o variables miembro o variables de instancia), y encapsula el comportamiento a través de secciones de código reutilizables llamados métodos.
Más técnicamente, una clase es un conjunto coherente que consiste en un tipo particular de metadatos. Una clase tiene tanto una interfaz y una estructura. La interfaz describe cómo interactuar con la clase y sus instancias con métodos, mientras que la estructura describe cómo los datos se dividen en atributos dentro de una instancia. Una clase también puede tener una representación (metaobjeto) en tiempo de ejecución, que proporciona apoyo en tiempo de ejecución para la manipulación de los metadatos relacionados con la clase. En el diseño orientado a objetos, una clase es el tipo más específico de un objeto en relación con una capa específica.
Los lenguajes de programación que soportan clases difieren sutilmente en su soporte para diversas características relacionadas con clases. La mayoría soportan diversas formas de herencia. Muchos lenguajes también soportan características para proporcionar encapsulación, como especificadores de acceso.
Suscribirse a:
Entradas (Atom)