REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN UNIVERSITARIA
INSTITUTO UNIVERSITARIO DE TECNOLOGIA DE MARACAIBO
PROGRAMA NACIONAL DE FORMACION INFORMATICA
Introducción a la programación.
Alumno:
T.S.U. Edgar Brito
C.I.: 15.887.879
Sección: 3212
Maracaibo, 16 de julio de 2022
Índice
Unidad 1. Introducción a la programación orientada a objetivo.
-Fundamentos de la POO
-Técnicas y herramientas para la representación de la POO en UML
(Diagrama de clases y sus relaciones)
Unidad 2. Leguaje de programación orientada a objetivo.
-Características
-Fundamentos
-Entradas/salidas
-Clases y objetos
-Implementación y ámbito de una clase
-Especificadores de acceso
-Constructores y destructores
Unidad 3. Herencia.
-Definición y tipos
-Tipos de herencias
-Clases bases virtuales
-Visibilidad de la herencia
-Clases abstractas y métodos virtuales
-Constructores y destructores con herencia.
Unidad 4. Polimorfismo.
-Definición y beneficios
-Tipos de polimorfismo: Sobrecarga, Paramétrico y de inclusión (Subtipado)
-Implementación
Introducción.
En el presente trabajo se hablara sobre los fundamentos de la programación
orientada a objetos, conceptos básicos, sus técnicas y herramientas en la UML
que conforma la materia Ingeniería del software ya que es importante tener claro
algo de conocimiento sobre el tema
Unidad 1. Introducción a la programación orientada a objetivo.
Fundamentos de la POO: La POO es una técnica para desarrollar soluciones
computacionales utilizando componentes de software (objetos de software). Entre
ellos destacan los siguientes fundamentos:
Clase: Una clase es una especie de "plantilla" en la que se definen los atributos y
métodos predeterminados de un tipo de objeto. Esta plantilla se crea para poder
crear objetos fácilmente. Al método de crear nuevos objetos mediante la lectura y
recuperación de los atributos y métodos de una clase se le conoce como
instanciación.
Herencia: Por ejemplo, herencia de la clase C a la clase D, es la facilidad
mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones
de C, como si esos atributos y operaciones hubiesen sido definidos por la misma
D. Por lo tanto, puede usar los mismos métodos y variables registrados como
"públicos" (public) en C. Los componentes registrados como "privados" (private)
también se heredan pero se mantienen escondidos al programador y solo pueden
ser accedidos a través de otros métodos públicos. Para poder acceder a un
atributo u operación de una clase en cualquiera de sus subclases pero mantenerla
oculta para otras clases es necesario registrar los componentes como "protegidos"
(protected), de esta manera serán visibles en C y en D pero no en otras clases.
Objeto: Instancia de una clase. Entidad provista de un conjunto de propiedades o
atributos (datos) y de comportamiento o funcionalidad (métodos), los mismos que
consecuentemente reaccionan a eventos. Se corresponden con los objetos reales
del mundo que nos rodea, o con objetos internos del sistema (del programa).
Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución
se desencadena tras la recepción de un "mensaje". Desde el punto de vista del
comportamiento, es lo que el objeto puede hacer. Un método puede producir un
cambio en las propiedades del objeto, o la generación de un "evento" con un
nuevo mensaje para otro objeto del sistema.
Técnicas y herramientas para la representación de la POO en UML
(Diagrama de clases y sus relaciones):
El diagrama de clases es una técnica central y ampliamente difundida en los
distintos métodos orientados a objeto. Cada método incluye sus propias variantes
a esta técnica, pero en el presente artículo nos vamos a centrar en la visión que se
encuentra implementada dentro del lenguaje estándar de modelado UML 1.1
Un lenguaje de modelado debe ser capaz de ofrecer los mecanismos necesarios
para capturar y modelar la abstracción de un sistema desde diferentes puntos de
vista. Estos puntos de vista deben dar lugar a diferentes diagramas que recojan
tanto la definición estática del sistema, como la componente de comportamiento
dinámico del mismo.
Para el modelado de la parte estática de un sistema, UML 1.1 [1], [2] cuenta con
los diagramas de estructura, que fueron introducidos en [3]. En concreto, los
diagramas de estructuras representan las abstracciones identificadas en forma de
clases y objetos, mostrando su estructura interna, así como sus interrelaciones.
Existen dos tipos de diagramas de estructura: los diagramas de clase y los
diagramas de objetos.
Los diagramas de clase describen los tipos de objetos de un sistema, así como los
distintos tipos de relaciones que pueden existir entre ellos. Los diagramas de clase
se convierten así en la técnica más potente para el modelado conceptual de un
sistema software, la cual suele recoger los conceptos clave del modelo de objetos
subyacente al método orientado a objetos que la incorpora, en este caso UML 1.1.
Por su parte, los diagramas estáticos de objetos representan una instantánea del
estado del sistema en un momento dado, esto es, cada diagrama de objetos es
una instancia del diagrama de clase, que representa uno de los infinitos
escenarios a los que puede dar origen un diagrama de clase.
Una vez introducidos los diagramas de estructura, nos vamos a centrar en los
aspectos esenciales de un diagrama de clase, por ser éste el diagrama más
importante y representativo del modelado estático de sistemas software.
-Utilidad de un diagrama de clase
El propósito de un diagrama de clase es describir las clases que conforman el
modelo de un determinado sistema. Dado el carácter de refinamiento iterativo que
caracteriza un desarrollo orientado a objetos, el diagrama de clase va a ser creado
y refinado durante las fases de análisis y diseño, estando presente como guía en
la implementación del sistema.
Se puede decir que existen tres perspectivas diferentes desde las cuales se
pueden utilizar los diagramas de clase:
-Conceptual: El diagrama de clase representa los conceptos en el dominio del
problema que se está estudiando. Este modelo debe crearse con la mayor
independencia posible de la implementación final del sistema.
-Especificación: El diagrama de clase refleja las interfaces de las clases, pero no
su implementación. Aquí las clases aparecen más cercanas a los tipos de datos,
ya que un tipo representa una interfaz que puede tener muchas implementaciones
diferentes.
-Implementación: Esta vista representa las clases tal cual aparecen en el entorno
de implementación.
-Clases
Para UML una clase es “una descripción de un conjunto de objetos que comparten
los mismos atributos, operaciones, métodos, relaciones, y semántica”. De esta
forma, un diagrama de clase de UML puede describir todos los componentes de
una clase de una forma sencilla. Así, el elemento fundamental de los diagramas
de clase es el icono que representa una clase.
El icono de una clase es un rectángulo dividido en tres secciones, como se puede
apreciar en la Figura A. La sección superior contiene el nombre de la clase, la
sección intermedia contiene la lista de atributos, y la sección inferior contiene la
lista de operaciones de la clase. Tanto la sección de atributos como la sección de
operaciones pueden omitirse. Cuando estas secciones aparecen, normalmente no
muestran todos los atributos ni todas las operaciones. El objetivo es mostrar sólo
aquellos atributos y operaciones que son representativos para un determinado
diagrama.
Dependiendo del detalle del diagrama de clase, la notación para un atributo puede
indicar su nombre, su tipo, un valor de inicio y su visibilidad, siendo su sintaxis:
Visibilidad nombre: tipo = valor
Donde:
• Visibilidad expresa si el atributo es visible para el resto de objetos del diagrama,
pudiéndose dar los siguientes casos:
+ Visibilidad pública: Visible por todos los objetos
# Visibilidad protegida: Visible sólo por el objeto y sus descendientes
- Visibilidad privada: Visible sólo por el objeto
• Nombre es el identificador del atributo
• Tipo indica el dominio del atributo
• Valor es un elemento opcional que indica un valor de inicio para el atributo
Al igual que sucede con los atributos, las operaciones de una clase pueden
especificarse con diferente nivel de detalle según la siguiente sintaxis:
Visibilidad nombre (lista de parámetros): tipo de retorno
La propiedad de ocultar las secciones de atributos y operaciones de una clase en
los diagramas de clase de UML, así como la posibilidad de especificar con un
mayor o menor grado de detalle los atributos y las operaciones de una clase,
permite utilizar un diagrama de clase de UML desde una perspectiva conceptual,
de especificación o de implementación, como se puede apreciar en la Figura B.
Asociaciones
Las asociaciones representan las relaciones más generales entre clases, es decir,
las relaciones con menor contenido semántico. Para UML una asociación va a
describir un conjunto de vínculos entre las instancias de las clases.
Las asociaciones pueden ser binarias (conectan dos clases) o n-arias (conectan n
clases), aunque lo más normal en un modelo es utilizar sólo relaciones binarias
(en general, y sin entrar en detalles, se puede afirmar que una relación n-aria
puede modelarse mediante un conjunto finito de relaciones binarias).
La forma de representar las asociaciones binarias en UML es mediante una línea
que conecta las dos clases. En general, las asociaciones son bidireccionales, esto
es, no tienen un sentido asociado.
Cada asociación tiene dos roles; cada rol marca una dirección en la asociación.
Así, en la Figura C, la asociación entre Cliente y Pedido contiene dos roles: uno de
Pedido a Cliente; y otro de Cliente a Pedido. A cada rol se le puede asociar una
etiqueta con su nombre. Si un rol no tiene asociado un nombre se le da el nombre
de la clase destino de la asociación, así el rol de Cliente a Pedido, recibe el
nombre de Pedido.
Cada rol tiene asociada una multiplicidad que especifica el número de instancias
de una clase que pueden estar relacionadas con una única instancia de la clase
asociada. La multiplicidad se expresa en UML mediante una cadena asociada a un
rol que representa un subconjunto abierto de enteros no negativos.
Sintácticamente esto se traduce en una secuencia de intervalos de números
enteros separada por comas, donde cada intervalo representa un rango, quizás
infinito, de enteros en el formato:
Cota inferior... Cota superior
Donde cota inferior y cota superior son valores de literales enteros. Adicionalmente
la cota superior se puede representar a través de un asterisco, ‘*’, indicando la
inexistencia de una cota superior. Un único ‘*’ indica el rango 0...∞. Un único
número indica una multiplicidad exacta, así por ejemplo 2 sería equivalente al
rango 2...2. En la práctica, las multiplicidades más utilizadas son 1 (exactamente
una), * (muchas: 0 a infinito) y 0...1
(Cero o una).
Un aspecto importante, que en ocasiones puede ser una fuente de confusión, es
cómo interpretar las multiplicidades que aparecen en los extremos de una
asociación. En UML la multiplicidad se define con respecto a una instancia de la
clase al otro extremo de la asociación, esto es, el indicador de multiplicidad se
interpreta asumiendo una sola instancia de la clase al otro extremo de la
asociación y después leyendo el mínimo y el máximo de instancias para la clase
más cercana al indicador. Según esto, las
cardinalidades que aparecen en la Figura C se leerían: “Un Cliente puede tener
asociados 0 o más pedidos, y un pedido tiene que tener asociado siempre un solo
Cliente”.
Como se ha dicho anteriormente, las asociaciones son por defecto bidireccionales,
de forma que cuando se quiera modelar una asociación unidireccional entre
clases, debe indicarse de forma explícita el sentido de la asociación mediante una
punta de flecha al final de la línea de asociación. Esto es lo que se denomina en
UML navegabilidad, y en nuestro ejemplo de la Figura C significa que un Pedido
tiene la responsabilidad de decir a que Cliente está asociado, pero un Cliente no
tiene la responsabilidad de decir que pedidos han realizado.
Agregación y composición
La agregación es una asociación con unas connotaciones semánticas más
definidas: la agregación es la relación parte-de, que presenta a una entidad como
un agregado de partes (en orientación a objeto, un objeto como agregado de otros
objetos). Como ejemplo ilustrativo de lo que es una agregación podemos recurrir
al ya clásico ejemplo de la bicicleta, donde una bicicleta se modela como un
agregado de ruedas, sillín, manillar, cuadro y pedales (ver Figura D).
La agregación en UML presenta el siguiente matiz, la existencia de las partes
agregadas es independiente de la existencia del objeto agregado, esto es, cuando
se crea el objeto agregado se irán estableciendo las relaciones con cada una de
las partes que lo constituyen a medida que se vayan necesitando. Los objetos que
representan las partes del objeto agregado pueden ya existir o crearse para formar
parte del objeto agregado, pero cuando se destruye el objeto agregado, los
objetos que lo forman no tienen por qué ser destruidos, por consiguiente, las
partes pueden sobrevivir a la destrucción del objeto agregado.
Volviendo al ejemplo de la bicicleta, cuando se crea una instancia de la clase
bicicleta, ésta deberá asociarse con las instancias oportunas de las clases de los
objetos que forman el agregado bicicleta. Pero, si la instancia de bicicleta es
destruida, las instancias de sus objetos constituyentes pueden seguir existiendo, y
convertirse en partes de otros objetos. En UML la agregación se representa por
una asociación en la que el rol del extremo unido a la clase agregada presenta el
adorno de un diamante vacío.
UML presenta una variación mucho más restrictiva de agregación que recibe el
nombre de composición. La composición implica que los componentes de un
objeto sólo pueden pertenecer a un solo objeto agregado, de forma que cuando el
objeto agregado es destruido todas sus partes son destruidas también.
La notación empleada para la composición es la misma que para la agregación
con la diferencia que el adorno de composición es un diamante relleno.
En la figura anterior se presenta un modelo de un pedido. Un pedido se ha
modelado como una composición de líneas de pedido, cada una de las cuales
está asociada con un producto.
Aunque los conceptos de agregación y composición se han presentado en un
contexto de análisis y diseño orientado a objetos, para ilustrar sus diferencias
vamos a ver como se implementarían ambas en C++.
Una agregación se implementa en C++ incluyendo en la declaración de la clase
agregada punteros a las instancias de las clases que constituyen sus agregados.
Esto es lo que denomina “Booch” agregación por referencia. Un esquema de la
implementación de la clase Bicicleta como puede apreciarse en la siguiente
gráfica.
Por su parte una composición se implementa en C++ incluyendo las declaraciones
de los objetos componentes en la declaración de la clase agregada. Esto es lo que
denomina Booch agregación por valor. En la Figura G se presenta el esqueleto de
la clase Pedido en C++. Como un Pedido esta forma por un número ilimitado de
Líneas Pedido, se tiene un vector de instancias de Línea Pedido que será
dimensionado en los constructores de la clase Pedido, y destruido en el destructor
de dicha clase.
Herencia.
La herencia es la típica relación de generalización/especialización entre clases. En
UML la herencia se representa mediante una flecha, cuya punta es un triángulo
vacío. La flecha que representa a la herencia va orientada desde la subclase a la
superclase. Cuando de una superclase se derivan varias subclases existen dos
notaciones diferentes, aunque totalmente equivalentes, para su representación. En
la primera forma de representar esta situación se muestra una superclase a la que
llegan tantas flechas como clases derivadas tiene. En la segunda representación
se tiene una única punta de flecha que llega a la superclase, pero a la base del
triángulo que hace de punta de flecha llegan tantos caminos como subclases haya.
La herencia tiene diferentes interpretaciones según la perspectiva de modelado
que se esté utilizando.
En el nivel conceptual, simplemente expresa que una determinada entidad es un
subtipo de otra entidad, por ejemplo Empresa es un subtipo de Cliente siendo, por
tanto, un tipo especial de Cliente. La idea central es expresar que todo lo que se
dice que es cierto para una clase (atributos, operaciones y relaciones) es cierto
para sus subclases.
Cuando se está realizando un modelo de especificación, la idea principal se centra
en que la interfaz de una subclase debe incluir todos los elementos de la interfaz
de su superclase. Otra forma de expresar el objetivo del nivel de especificación en
cuanto a la herencia es el principio de capacidad de sustitución, o lo que es lo
mismo, que en el lugar donde se espere una instancia de la superclase, pueda
aparecer una instancia de cualquiera de sus subclases, y todo siga funcionando
correctamente. La instancia de la subclase puede responder a ciertas órdenes de
forma diferente a como lo haría una instancia de la superclase (gracias al
polimorfismo), pero los clientes que esperan la instancia de la superclase no
necesitan conocer ni preocuparse por estas diferencias.
Desde el punto de vista de la implementación, la herencia está asociada a la
capacidad de los lenguajes de programación para representar este mecanismo de
transmisión de estructura y comportamiento desde la superclase a la subclase,
esto es, la subclase hereda todos los métodos y atributos de la superclase.
Unidad 2. Leguaje de programación orientada a objetivo.
-Características: Es importante señalar que la POO puede variar según el
programador. Y esto sucede porque hay un cambio de concepto; no se trata tanto
de una única escala sino, de una forma de concebir la programación.
Lo cierto es que este tipo de programación es mucho más abierta, aunque
favorece una estructuración ordenada. Se requiere de una cierta formación previa,
pero en la práctica hay varias ventajas por las que puede interesar esta
metodología. La organización del código se realiza en distintas clases que,
posteriormente, podrán concretarse en objetos.
El módulo fue la primera introducción de programación para reaprovechamiento,
pero aquí se va un paso más allá. La POO busca, en definitiva, que las
aplicaciones que se desarrollen sean cada vez más complejas sin que eso
suponga desechar el código. Esta filosofía permitirá reutilizarlo, de manera que
progresar no supondrá renunciar.
En consecuencia, lo que podemos hacer es señalar una serie de cuestiones
comunes que has de conocer.
1. Distinción entre clase y objeto
La distinción entre clase y objeto es una de las claves de este tipo de
programación que la hace única. No en vano, si no entendemos esta parte, no
sabemos cómo funciona este tipo de programación.
2. Reutiliza el código y evita su duplicación
La duplicación del código es uno de los problemas recurrentes, sobre todo por la
pérdida de tiempo que implica. La POO introduce una novedad interesante al
respecto
3. Encapsula la información
El concepto de encapsulación de la información es clave si quieres afinar en la
privacidad. Uno de los problemas recurrentes está en la cantidad de datos que se
comparten, y en qué medida.
4. Polimorfismo
El polimorfismo permite diseñar objetos para compartir comportamientos. Por lo
tanto, es una buena forma de que se pueda proporcionar orden. El efecto que se
consigue es que puedes procesar los objetos de distintas maneras.
-Fundamentos: Abstracción: proceso mental de extracción de las características
esenciales de algo, ignorando los detalles superfluos.
Encapsulación: proceso por el que se ocultan los detalles del soporte de las
características esenciales de una abstracción.
Modularización: proceso de descomposición de un sistema en un conjunto de
módulos o piezas independientes y cohesivas (con significado propio). Lo
adecuado es conseguir los mínimos acoplamientos.
Jerarquización: proceso de estructuración por el que se produce una
organización (jerarquía) de un conjunto de elementos en grados o niveles de
responsabilidad, incumbencia o composición entre otros.
-Entradas/salidas: La clase acaba con la entrada y salida de datos, que nos va a
permitir solicitar información al usuario y devolver información. En este caso se
explica usando las sentencias de Javascript prompt() y alert(). La primera me
permite solicitar un dato al usuario y la segunda presentarlo. Ambas funciones
lanzan una caja de diálogo que el usuario debe usar para interaccionar con las
aplicaciones
-Clases y objetos:
Clases: Cada clase tiene asociado un código (definición de la clase), que
determina
-Los atributos que tienen los objetos de la clase
-Los métodos que pueden ejecutar los objetos de la clase y cómo lo hacen
-Programar orientado a objetos consiste en escribir código de clases de objetos
Objetos: Un objeto en POO representa alguna entidad de la vida real, es decir,
alguno de los objetos que pertenecen al negocio con que estamos trabajando o al
problema con el que nos estamos enfrentando, y con los que podemos interactuar.
A través del estudio de ellos se adquiere el conocimiento necesario para, mediante
la abstracción y la generalización, agruparlos según sus características en
conjuntos. Estos conjuntos determinan las clases de objetos con las que estamos
trabajando. Primero existen los objetos; luego aparecen las clases en función de la
solución que estemos buscando. Ésta es la forma más común de adquirir
conocimiento aunque no es la única. En ocasiones, cuando el observador es un
experto del negocio (o del problema), el proceso puede ser a la inversa y
comenzar el análisis en una base teórica abstracta, sustentada por el
conocimiento previo que da lugar primeramente a clases de objetos que satisfagan
las necesidades de la solución.
-Implementación y ámbito de una clase
En la fase de implementación, una clase es un tipo o molde que sirve para crear
objetos.
La sintaxis para declarar una clase es:
[Modificador] class <nombre>
{
// Campos de la clase
// Métodos de la clase
Los modificadores de acceso sirven para restringir el acceso a los campos o a los
métodos de una clase.
Los principales modificadores de acceso son:
private
protected
public
El modificador private permite que el campo o método sólo pueda ser accedido
dentro de la clase donde fue declarado.
El modificador protected permite que el campo o método sólo pueda ser accedido
dentro de la clase donde fue declarado y en todas las clases derivadas de ella.
El modificador public permite que el campo o método pueda ser accedido desde
cualquier clase.
-Especificadores de acceso
En una definición de clase, un especificador de acceso se utiliza para controlar la
visibilidad de los miembros de una clase fuera del ámbito de la clase.
Los miembros de una clase pueden ser públicos, privados o protegidos. Las
palabras reservadas public, private y protected se utilizan para controlar el modo
de acceso a la clase.
Dentro de una declaración de clase, cada una de estas palabras se puede utilizar
para preceder a una o más declaraciones de los miembros de una clase:
- Acceso protegido. Los miembros protegidos significan que sólo se puede
acceder a ellos por función del miembro dentro de la misma clase y por funciones
miembro de clases derivadas de esta clase.
- Acceso público. Los miembros públicos son accesibles por cualquier parte del
programa.
- Acceso privado. Los miembros privados sólo pueden ser utilizados por la función
del miembro de la clase y las funciones amigas de la clase.
-Constructores y destructores
El objetivo de un constructor es el de inicializar un objeto cuando éste es creado.
Asignaremos los valores iniciales así como los procesos que ésta clase deba
realizar.
Se utiliza para crear tablas de métodos virtuales y poder así desarrollar el
polimorfismo, una de las herramientas de la programación orientada a objetos
(POO). Al utilizar un constructor, el compilador determina cuál de los objetos va a
responder al mensaje (virtual) que hemos creado. Tiene un tipo de acceso, un
nombre y un paréntesis.
En java es un método especial dentro de una clase, que se llama
automáticamente cada vez que se crea un objeto de esa clase.
Posee el mismo nombre de la clase a la cual pertenece y no puede regresar
ningún valor (ni siquiera se puede especificar la palabra reservada void). Por
ejemplo si añadiéramos a la clase Suma un constructor, tendríamos que llamarlo
también Suma. Cuando en una clase no se escribe propiamente un constructor,
java asume uno por defecto (que es el Constructor vacío, es decir sin parámetros).
Un destructor en algunos lenguajes de programación orientados a objetos es un
método de una clase que se llama justo antes de una instancia de esa clase y se
elimina de la memoria. No todos los lenguajes de programación orientados a
objetos suelen tener un destructor.
La contrapartida de un destructor es un constructor que se ejecuta cuando se crea
el objeto, se instancia y se lo inicializa.
Unidad 3. Herencia.
-Definición y tipos
Herencia es un concepto de la programación orientada a objetos. El cual es un
mecanismo que permite derivar una clase a otra clase.
En otras palabras, tendremos unas clases que serán hijos, y otras clases que
serán padres.
Las clases hijas pueden utilizar tanto sus métodos y propiedades como de la clase
padre, siempre que su modificador de acceso lo permita.
Cuando heredamos de una clase padre únicamente podemos hacerlo de una sola
clase. No podemos heredar de dos clases, por ejemplo class Triciclo: Mixto,
Vehículo no es válido.
-Tipos de herencias
Hay dos tipos de herencia: Herencia Simple y Herencia Múltiple. La primera indica
que se pueden definir nuevas clases solamente a partir de una clase inicial
mientras que la segunda indica que se pueden definir nuevas clases a partir de
dos o más clases iniciales. Java sólo permite herencia simple.
-Clases bases virtuales.
Cuando se tiene herencia múltiple, se puede presentar el caso en que en una
jerarquía de tres o más niveles se esté heredando por dos caminos diferentes a
una misma clase, hecho que podría degenerar en la redundancia de la definición
de métodos y atributos al momento de compilar, hecho que estimula la
virtualización de la clase base heredada.
-Visibilidad de la herencia
Para poder dar acceso a los métodos y atributos de un objeto dentro de la
Programación Orientada a Objeto utilizamos la visibilidad. Esta cualidad es posible
configurarla a través de tres palabras reservadas en PHP. Estas son:
1. Public: Un método o atributo tiene una visibilidad pública cuando todas las
demás clases pueden acceder a ellos. Nos referimos a otra clase o una
subclase.
2. Private: Tan solo se puede ver y acceder a ellos desde el propio código de
la clase.
3. Protected: Solo desde el propio código de su clase o de sus subclases
pueden acceder.
-Clases abstractas y métodos virtuales
Las clases abstractas actúan como expresiones de conceptos generales de los
que pueden derivarse clases más concretas. No se puede crear un objeto de un
tipo de clase abstracta. Sin embargo, puede usar punteros y referencias a tipos de
clase abstractos.
Para crear una clase abstracta, declare al menos una función miembro virtual
pura. Se trata de una función virtual declarada mediante la sintaxis del
especificador puro (= 0). Las clases derivadas de la clase abstracta deben
implementar la función virtual pura o deben ser también clases abstractas.
Considere el ejemplo presentado en Funciones virtuales. El propósito de la clase
Account es proporcionar funcionalidad general, pero los objetos de tipo Account
son demasiado generales para resultar útiles.
-Constructores y destructores con herencia.
Unidad 4. Polimorfismo.
-Definición: Polimorfismo quiere decir "muchas formas". Se refiere a la posibilidad
de que objetos de clases diferentes puedan responder a mensajes con el mismo
nombre, cada uno de ellos con su propio comportamiento.
Ejemplo:
3 + 5 El objeto 3 (instancia de la clase Integer) recibe el mensaje sumar con el
argumento 5.
5/2 + 4/5 El objeto 5/2 (instancia de la clase Fraction) recibe el mensaje sumar
con el argumento 4/5.
‘Hola’ + ‘y Adiós’ El objeto ‘Hola’ (instancia de la clase String) recibe el mensaje
sumar con el argumento ‘y Adiós’. Se observa que las acciones desencadenadas
por el mensaje sumar dependen de cuál es la clase del objeto receptor. Esto es
posible gracias al Polimorfismo, característica de la POO que hace referencia a
una operación que adopta varias formas de implementación. Es la habilidad de
dos o más objetos de distintas clases de responder a un mismo mensaje, cada
uno de su propia forma. Esto significa que un objeto no necesita saber a quién le
está enviando un mensaje. Solo debe saber que se han definido las
implementaciones correspondientes en los objetos para que respondan a ese
mensaje en particular. O dicho de otra manera, un mismo mensaje puede provocar
la invocación de métodos distintos
-Beneficios: El Polimorfismo permite reconocer y explotar las similitudes entre
diferentes clases de objetos. Cuandose reconoce que varios tipos diferentes de
objetos pueden responder al mismo mensaje, se estáreconociendo la distinción
entre el nombre del mensaje y un método. Cuando un objeto (emisor) envía un
mensaje, si el receptor entiende ese mensaje, ejecutará el método que él tiene
asociado al mismo. Instancias de distintas clases pueden asociar, cada una, un
método distinto a un mismo mensaje común a todas.
Diferentes respuestas son posibles, por lo tanto métodos diferentes tienen sentido
para clases diferentes, pero el emisor puede simplemente enviar el mensaje sin
preocuparse de la clase del receptor.
-Tipos de polimorfismo: Sobrecarga, Paramétrico y de inclusión (Subtipado).
-Sobrecarga: El polimorfismo de sobrecarga ocurre cuando las funciones del
mismo nombre existen, con funcionalidad similar, en clases que son
completamente independientes una de otra (éstas no tienen que ser clases
secundarias de la clase objeto). Por ejemplo, la clase complex, la clase image y la
clase link pueden todas tener la función "display". Esto significa que no
necesitamos preocuparnos sobre el tipo de objeto con el que estamos trabajando
si todo lo que deseamos es verlo en la pantalla.
Por lo tanto, el polimorfismo de sobrecarga nos permite definir operadores cuyos
comportamientos varían de acuerdo a los parámetros que se les aplican. Así es
posible, por ejemplo, agregar el operador + y hacer que se comporte de manera
distinta cuando está haciendo referencia a una operación entre dos números
enteros (suma) o bien cuando se encuentra entre dos cadenas de caracteres
(concatenación).
- Paramétrico: El polimorfismo paramétrico es la capacidad para definir varias
funciones utilizando el mismo nombre, pero usando parámetros diferentes
(nombre y/o tipo). El polimorfismo paramétrico selecciona automáticamente el
método correcto a aplicar en función del tipo de datos pasados en el parámetro.
-Subtipado: La habilidad para redefinir un método en clases que se hereda de una
clase base se llama especialización. Por lo tanto, se puede llamar un método de
objeto sin tener que conocer su tipo intrínseco: esto es polimorfismo de subtipado.
Permite no tomar en cuenta detalles de las clases especializadas de una familia
de objetos, enmascarándolos con una interfaz común (siendo esta la clase
básica).
Imagine un juego de ajedrez con los objetos rey, reina, alfil, caballo, torre y peón,
cada uno heredando el objeto pieza.
El método movimiento podría, usando polimorfismo de subtipado, hacer el
movimiento correspondiente de acuerdo a la clase objeto que se llama. Esto
permite al programa realizar el movimiento de pieza sin tener que verse conectado
con cada tipo de pieza en particular.
-Implementación: El uso más común de polimorfismo en programación orientada a
objetos se da cuando se utiliza la referencia de una clase padre, para referirse al
objeto de la clase hijo.
Esta característica permite definir distintos comportamientos para un método
dependiendo de la clase sobre la que se realice la implementación.
En todo momento tenemos un único medio de acceso, sin embargo, se podrá
acceder a métodos distintos. Es importante saber que la única manera de acceder
a un objeto es a través de una variable de referencia. La variable de referencia
sólo puede ser de un tipo. Una vez declarado el tipo de la variable de referencia,
no se puede cambiar.
Bibliografía
[Link]
[Link]
[Link]
programacin-orientada-a-objetos
[Link]
programacion-orientada-objetos
[Link]
[Link]
[Link]
%20en%20POO%20representa,con%20los%20que%20podemos%20interactuar.
[Link]
[Link]
PKHSH2JMY#:~:text=de%20su%20%C3%A1mbito.-,3.5%20Especificadores
%20de%20Acceso.,ser%20p%C3%BAblicos%2C%20privados%20o
%20protegidos.
[Link]
[Link]
%20en%20POO,-Herencia%20es%20un&text=El%20cual%20es%20un
%20mecanismo,modificador%20de%20acceso%20lo%20permita.
[Link]
[Link]
[Link]
orientada-a-objetos-poo/#:~:text=PHP%2FProgramaci%C3%B3n-,La
%20visibilidad%20de%20los%20atributos%20y%20m%C3%A9todos,Programaci
%C3%B3n%20Orientada%20a%20Objetos%20(POO)&text=Para%20poder
%20dar%20acceso%20a,tres%20palabras%20reservadas%20en%20PHP.
[Link]
[Link]
%C3%A1s%20com%C3%BAn%20de,que%20se%20realice%20la
%20implementaci%C3%B3n.
[Link]
[Link]