Conceptos del paradigma orientado a objetosbbeltran.cs.buap.mx/Unidad1.pdf · MC Beatriz Beltrán...

MC Beatriz Beltrán Martínez / MC Miguel Rodríguez Hernández

Conceptos del paradigma orientado a objetos

El desarrollo de proyectos software a lo largo del tiempo ha sufrido una evolución

desde los primeros sistemas de cálculo, implementados en grandes computadoras

simplemente ayudados mediante unas tarjetas perforadas donde los programadores

escribían sus algoritmos de control, hasta la revolución de los sistemas de información e

internet.

Han existido dos grandes cambios desde aquellos sistemas meramente algorítmicos

donde todo el esfuerzo de desarrollo se centraba en la escritura de programas que realizaran

algún tipo de cálculo. El primero de ellos es la aparición del modelo relacional, un modelo

con fuerte base matemática que supuso el desarrollo las bases de datos y propició la

aparición de los grandes sistemas de información. El segundo cambio es sobre los

lenguajes de programación, la aparición de los Lenguajes Orientados a Objetos (aunque

los primero lenguajes con características de orientación a objetos aparecieron en la década

de los setenta, por ejemplo Simula 67) supuso una revolución en la industria software.

El problema entonces radicaba en poder sacarle partido a los lenguajes orientados a

objetos por lo que aparecieron numerosas metodologías para el diseño orientado objetos,

hubo un momento en el que se podía decir que el concepto de orientación a objetos estaba

“de moda” y todo era orientado a objetos, cuando realmente lo que ocurría es que las

grandes empresas que proporcionaban los compiladores y lenguajes de programación

“lavaban la cara" a sus compiladores, sacaban nuevas versiones que adoptaran alguno de

los conceptos de orientación a objetos y los vendían como orientados a objetos.

En la actualidad el desarrollo orientado a objetos se considera uno de los más

poderosos modelos desarrollados. Para poner un poco de orden, sobre todo en lo que

respecta a la modelización de sistemas software, aparece UML (Unified Modeling

Languaje, Lenguaje Unificado de Modelado) que pretende unificar las tres metodologías

más difundidas (OMT, Bootch y OOSE) e intentar que la industria software termine su

maduración como Ingeniería.

Modelado Para producir software que cumpla su propósito hay que obtener los requisitos del

sistema, esto se consigue conociendo de una forma disciplinada a los usuarios y

haciéndolos participar de manera activa para que no queden “cabos sueltos”.

Para conseguir un software de calidad, que sea duradero y fácil de mantener hay que

idear una sólida base arquitectónica que sea flexible al cambio. Para desarrollar software,

rápida y eficientemente, minimizando el trabajo de recodificación y evitando crear miles de

líneas de código inútil hay que disponer, además de la gente y las herramientas necesarias,

de un enfoque apropiado.

El modelado es la espina dorsal del desarrollo software de calidad. Se construyen

modelos para poder comunicarnos con otros, para explicar el comportamiento del sistema a


desarrollar, para comprender, nosotros mismos, mejor ese sistema, para controlar el riesgo

y en definitiva para poder atacar problemas que sin el modelado su resolución sería

imposible, tanto desde el punto de vista de los desarrolladores como desde el punto de vista

del cliente, el cual, si finalmente se le entrega el producto del desarrollo, se encontrará con

infinidades de problemas, desde que no se cumplen las especificaciones hasta fallos que

dejan inutilizado el sistema.

El modelado, o modelo de objetos, describe los conceptos principales de la

orientación a objetos: las estructuras estáticas y sus relaciones. Las principales estructuras

estáticas son los objetos y clases, los cuales están compuestos de atributos y operaciones,

mientras que las principales relaciones entre objetos y entre clases corresponden a las ligas

y asociaciones, respectivamente.

A través del modelado conseguimos cuatro objetivos:

Los modelos nos ayudan a visualizar cómo es o queremos que sea un sistema.

Los modelos nos permiten especificar la estructura o el comportamiento de un

sistema.

Los modelos nos proporcionan plantillas que nos guían en la construcción de un

sistema.

Los modelos documentan las decisiones que hemos adoptado.

Orientación a Objetos

La programación estructurada tradicional se basa fundamentalmente en la ecuación

de Wirth:

Algoritmos + Estructuras de Datos = Programas

Esta ecuación significa que en la programación estructurada u orientada a

procedimientos los datos y el código se trata por separado y lo único se realiza son

funciones o procedimientos que tratan esos datos y los van pasando de unos a otros hasta

que se obtiene el resultado que se desea.

La Programación Orientada a Objetos, POO (OOP, Object Oriented Programming,

en inglés), es una técnica de programación cuyo soporte fundamental es el objeto. Un

objeto es una extensión de un Tipo Abstracto de Datos (TAD), concepto ampliamente

utilizado desde la década de los setenta. Un TAD es un tipo definido por el usuario, que

encapsula un conjunto de datos y las operaciones sobre estos datos.

A la hora de definir TAD’s (u objetos) se usa un concepto que nos ayuda a

representar la realidad mediante modelos computacionales, la abstracción, que es un

proceso mental por el que se evitan los detalles para centrarse en las cosas más genéricas de

manera que se facilite su comprensión. De hecho la abstracción no sólo se utiliza en la

informática, un arquitecto al que le han encargado realizar los planos de un edificio no

comenzará por diseñar los planos con máximo nivel de detalle, sino que comenzará a

realzar ciertos esbozos en un papel para posteriormente ir refinando. Por supuesto que

cuando está realizando los esbozos no se preocupa de por dónde van a ir las líneas


eléctricas ni las tuberías de saneamiento, abstrae esos detalles para atacarlos posteriormente

cuando tenga clara la estructura del edificio.

La diferencia entre el concepto de TAD y el de objeto radica en que además del

proceso de abstracción que se utiliza para su definición, existen otros dos con los que se

forma el núcleo principal de la programación orientada a objetos, estos son la herencia y el

polimorfismo.

Ventajas de la orientación a objetos

Las ventajas más importantes de la programación orientada a objetos son las

siguientes:

Mantenibilidad (facilidad de mantenimiento). Los programas que se diseñan

utilizando el concepto de orientación a objetos son más fáciles de leer y comprender

y el control de la complejidad del programa se consigue gracias a la ocultación de la

información que permite dejar visibles sólo los detalles más relevantes.

Modificabilidad (facilidad para modificar los programas). Se pueden realizar

añadidos o supresiones a programas simplemente añadiendo, suprimiendo o

modificando objetos.

Reusabilidad. Los objetos, si han sido correctamente diseñados, se pueden usar

numerosas veces y en distintos proyectos.

Fiabilidad. Los programas orientados a objetos suelen ser más fiables ya que se

basan en el uso de objetos ya definidos que están ampliamente testados.

Estas ventajas son directas a los programadores. Estos, se podría decir, que son los

ejecutores de un determinado proyecto software. Pero la orientación a objetos no sólo

reporta beneficios a los programadores. En las etapas de análisis, previas a la codificación,

el utilizar un modelado orientado a objetos reporta grandes beneficios ya estas mismas

ventajas son aplicables a todas las fases del ciclo de vida de un proyecto software.

La tendencia actual es a tratar temas conceptuales de primer plano (o sea, en las

fases de análisis) y no temas finales de implementación. Los fallos durante la etapa de

implementación son más difíciles de corregir y más costosos que si se dan en las etapas

previas.

El modelado orientado a objetos tiende al refinamiento sucesivo de manera que se

llega a la etapa de implementación con un diseño lo suficientemente explícito para que no

existan casos inesperados y todo independientemente del lenguaje de programación (salvo

en etapas muy próximas a la implementación donde no hay más remedio que contar con el

soporte que se recibe del lenguaje elegido). El desarrollo orientado a objetos es más una

manera de pensar y no una técnica de programación.

Conceptos básicos de la orientación a objeto

Como ya hemos dicho la orientación a objetos se basa en conceptos como clase,

objeto, herencia y polimorfismo, pero también en otros muchos, los cuales se explican a

detalle a continuación.


1. Abstracción

La abstracción se enfoca en la vista externa del objeto y sirve para separar el

comportamiento esencial del objeto de su implementación. La abstracción se enfoca sobre

las características importantes de algún objeto, relativo a la perspectiva de que observa.

Gracias a la abstracción podemos representar las características esenciales de un

objeto sin preocuparnos de las restantes características (no esenciales). La 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.

En el sentido más general, una abstracción es una representación concisa de una

idea o de un objeto complicado. En un sentido más específico, la abstracción localiza y

oculta los detalles de un modelo o diseño para generar y manipular objetos.

Una abstracción tiene un significado más general que la encapsulación, pudiendo

hablar de abstracción de datos en lugar de encapsulación de datos.

La abstracción es una estrategia de resolución de problemas en la cual el

programador se concentra en resolver una parte del problema ignorando completamente los

detalles sobre cómo se resuelven el resto de las partes.

En este proceso de abstracción se considera que el resto de las partes ya han sido

resueltas y por lo tanto pueden servir de apoyo para resolver la parte

que recibe la atención.

Imaginemos que se quiere aplicar la abstracción a las

Computadoras, las personas que compran una, no requieren saber de

su funcionamiento interno para poder utilizarla.


Si ahora, la abstracción la aplicamos a los

Automóviles, sucede algo muy similar, la persona que

adquiere uno, no requiere saber cómo funciona de manera

interna, solo tiene que saber manejar y los servicios básicos

(gasolina, llevarlo a mantenimiento, agua, etc.).

2. Clase y objeto

Los objetos son las entidades básicas del modelo de objeto. La palabra objeto

proviene del latín objectus, donde ob significa hacía, y jacere significa arrojar; o sea que

teóricamente un objeto es cualquier cosa que se pueda arrojar.

Ejemplo: Una pelota o un libro se pueden arrojar, por lo tanto estos son objetos. Por

otro lado, un avión o un elefante también se consideran objetos, aunque sean bastante

pesados para ser arrojados.

Los objetos son más que simples cosas que se puedan arrojar, son conceptos

pudiendo ser abstractos o concretos.

Ejemplo: Una mesa es un objeto concreto, mientras que un viaje es un objeto

abstracto.

Los objetos corresponden por lo general a sustantivos, pero no a gerundios.

Ejemplo: Mesa y viaje son ambos sustantivos y por lo tanto objetos. Trabajando y

estudiando son gerundios por lo cual no se consideran objetos.

Cualquier cosa que incorpore una estructura y un comportamiento se le puede

considerar como un objeto.

Ejemplo: Una pelota es sólida y redonda y se le puede arrojar o atrapar. Un libro es

rectangular y sólido y se le puede abrir, cerrar, y leer.

Un objeto debe tener una identidad coherente, al que se le puede asignar un nombre

razonable y conciso.

Ejemplo: Se consideran manzanas todas las frutas con un sabor, textura, y forma

similar.

La existencia de un objeto depende del contexto del problema. Lo que puede ser un

objeto apropiado en una aplicación puede no ser apropiado en otra, y al revés. Por lo

general, existen muchos objetos en una aplicación, y parte del desafío es encontrarlos.

Ejemplo: La temperatura se puede considerar un objeto abstracto, teniendo

propiedades tales como el valor de la temperatura y el tipo de la escala en que se mide


(Celsius o Fahrenheit). Por otro lado, si hablamos de un termómetro, la temperatura pasa a

ser una propiedad del termómetro.

Los objetos se definen según el contexto de la aplicación.

Ejemplo: Una persona llamada Juan Pérez se considera un objeto para una

compañía, mientras que para un laboratorio el hígado de Juan Pérez es un objeto. Una

universidad como la BUAP se considera un objeto, mientras que dentro de la BUAP los

objetos serían las aulas, los estudiantes y los profesores.

Los objetos deben ser entidades que existen de forma independiente. Se debe

distinguir entre los objetos, los cuales contienen características o propiedades, y las propias

características.

Ejemplo: El color y la forma de una manzana no se consideran propiamente

objetos, sino propiedades del objeto manzana. El nombre de una persona se considera una

propiedad de la persona.

Un grupo de cosas puede ser un objeto si existe como una entidad independiente.

Ejemplo: Un automóvil se considera un objeto el cual consiste de varias partes,

como el motor y la carrocería.

Los objetos deben tener nombres en singular, y no en plural.

Ejemplo: Un automóvil es un objeto, automóviles son simplemente muchos objetos

y no un solo objeto.

Parte de una cosa puede considerarse un objeto.

Ejemplo: La rueda, la cual es parte del automóvil, se puede considerar un objeto.

Por otro lado, el lado izquierdo del automóvil sería un mal objeto.

Los objetos deben tener nombren razonables y concisos para evitar la construcción

de objetos que no tengan una identidad coherente.

Ejemplo: Datos o información no son nombres concisos de objetos. Por otro lado,

un estudiante es un objeto, ya que contiene propiedades como el número de matrícula y

nombre del estudiante, además incluye un comportamiento tal como ir a clases, presentar

exámenes, y graduarse. Todos los estudiantes cuyos apellidos comiencen con "A" sería un

mal objeto ya que el nombre del objeto no es conciso.


El objeto integra una estructura de datos (atributos) y un comportamiento

(operaciones).

Una clase describe un grupo de objetos con estructura y comportamiento común.

(Clase y tipo no son necesariamente equivalentes, tipo se define por las manipulaciones que

se le puede dar a un objeto dentro de un lenguaje y clase involucra una estructura, pudiendo

corresponder a una implementación particular de un tipo.)

Las estructuras o propiedades de la clase se conocen como atributos y el

comportamiento como operaciones. Una clase define uno o más objetos, donde los objetos

pertenecen a la clase, teniendo características comunes.

Ejemplo: Juan Pérez y María López se consideran miembros de la clase persona,

donde todas las personas tienen una edad y un nombre. La BUAP y la UDLA pertenecen a

la clase universidad, donde todas las universidades tienen una dirección y un grado

máximo. Chrysler y Microsoft pertenecen a la clase compañía, donde todas las compañías

tienen una dirección, un número de empleados, y una ganancia al año.

Una clase se considera un "molde" del cual se crean múltiples objetos.

Ejemplo: La clase es como un molde de una cerámica de la cual se pueden crear

múltiples cerámicas, todas con exactamente las mismas características. Para modificar las

cerámicas hay que primero construir un nuevo molde.

Al definir múltiples objetos en clases se logra una abstracción del problema. Se

generaliza de los casos específicos definiciones comunes, como nombres de la clase,

atributos, y operaciones.

Ejemplo: Los objetos impresora a láser, impresora de burbuja, e impresora de punto

son todos objetos que pertenecen a la clase impresora.

Una clase como la hemos definido se conoce también como clase básica.


Todos los objetos son instancias de una clase y la clase de un objeto es una

propiedad implícita del objeto. Cada objeto conoce su clase y la mayoría de los lenguajes

de programación orientados al objeto pueden determinar la clase de un objeto en tiempo de

ejecución.

La agrupación en clases de los objetos permite la abstracción de un problema. Las

definiciones comunes, tales como nombres de clases y de atributos se almacenan una vez

por cada clase. Las operaciones se escriben una vez para cada clase: reutilización de

código.

Imaginemos que queremos aplicar la

abstracción a las Aves:

El objeto serían el pájaro, y sus

características por ejemplo, serían pico, alas,

plumas y patas.

El comportamiento sería volar, parar,

etc.

3. Relación entre clases

Las relaciones entre clases juegan un papel importante en el modelo de objetos. Las

clases, al igual que los objetos, no existen de modo aislado. Por esta razón existirán

relaciones entre clases y entre objetos.

Las relaciones entre clases, se deben a dos razones. La primera, una relación entre

clases puede indicar algún tipo de compartición (por ejemplo margaritas y rosas son ambas

tipos de flores). Segunda, una relación entre clases puede indicar algún tipo de conexión

semántica; por ejemplo, las rosas rojas y amarillas, son más parecidas entre sí que las

margaritas y las rosas.

Los tres grandes tipos de relaciones entre clases son:

Generalización / especialización (es-un).

Agregación (todo / parte).

Asociación.

Generalización / Especialización (is-a / es-un)

Las clases se pueden organizar en estructuras jerárquicas. La herencia es una

relación entre clases donde una clase comparte la estructura o comportamiento, definida en

una (herencia simple) o más clases (herencia múltiple). Se denomina superclase a la clase

de la cual heredan otras clases. De modo similar, una clase que hereda de una o más clases

se denomina subclase. Una subclase heredará atributos de una superclase en el árbol

jerárquico. La herencia, por consiguiente, define un tipo de jerarquía entre clases, en las que

una subclase hereda de una o más superclases.


En la siguiente imagen, se ilustra la jerarquía de la clase Animal, con dos subclases

que heredan de la superclase.

Herencia es la propiedad por la cual instancias de una clase hija (o subclase) puede

acceder tanto a datos como a comportamientos (métodos) asociados con una clase padre (o

superclase). La herencia siempre es transitiva, de modo que una clase puede heredar

características de superclases de nivel superior. Esto es, si la clase perro es una subclase de

mamífero y de animal.

Una vez que la jerarquía se ha establecido es fácil extenderla. Para describir sus

diferencias a partir de un concepto de una jerarquía existente. La herencia significa que el

comportamiento y los datos asociados con las clases hijas son siempre una extensión de las

propiedades asociadas con las clases padres. Una subclase debe tener todas las propiedades

de la clase padre y otras.

Una superclase representa una generalización de las subclases. De igual modo, una

subclase de una clase dada representa una especialización de la clase superior. La clase

derivada es-un tipo de la clase base o superclase.

En el modelado orientado a objetos es útil introducir clases en un cierto nivel que

puede no existir en la realidad, pero que son construcciones conceptuales útiles. Estas

clases se conocen como clases abstractas y su propiedad fundamental es que no se pueden

crear instancias de ellas. Ejemplos de una clase abstracta es FiguraGeometrica, ya que se

sabe que toda figura geométrica tiene un área y un perímetro, pero hasta no saber que figura

es, no se pueden calcular.

La generalización, en esencia, es una abstracción en que un conjunto de objetos de

propiedades similares se representa mediante un objeto genérico. El método usual para

construir relaciones entre clases es definir generalizaciones buscando propiedades y

funciones de un grupo de tipos de objetos similares, que se agrupan.

Animal

Mamífero Reptil

Gato Perro Cocodrilo Zorro Serpiente


Agregación

Una agregación es una relación que representa a los objetos compuestos. Un objeto

es compuesto si se compone a su vez de otros objetos. Una casa se compone de

habitaciones, tejados, suelos, ventanas, etc. Una habitación a su vez, se compone de

paredes, techos, suelo, ventanas y puertas.

La agregación de objetos permite describir modelos del mundo real que se

componen de otros modelos, que a su vez se componen de otros modelos. La agregación es

un concepto que se utiliza para expresar tipo de relaciones entre objetos parte-de (part-of)

o tiene-un (has-a). El objeto componente, también a veces denominado continente o

contenedor, es un objeto agregado que se compone de múltiples objetos.

La agregación es una forma específica de asociación y no un comportamiento

independiente, que añade significados o connotaciones semánticas en ciertos casos. Dos

objetos forman un agregado, o existe entre ellos una relación de agregación, si existe ente

ellos una relación todo-parte, continente-contenido.

La agregación puede ser de dos tipos, por contenido físico o por contenido por

referencia o conceptual.

FiguraGeo

métrica

Cuadrado Circulo Triangulo

Casa

Habitación Tejados

Puertas Ventanas Paredes

tiene tiene

tiene

tiene

tiene tiene

tiene


La agregación por contenido físico o por valor implica que un objeto contenido no

existe independientemente del objeto contenedor. La vida de ambos objetos está

íntimamente relacionada. Cuando se crea un sintagma de la clase contenedor o1, se crea

una instancia de la clase contenida o2. Cuando se destruye el objeto o1, se destruye el

objeto o2.

El objeto agregado Coche, se compone de un motor, una transmisión, un chasis,

etc., que son a su vez parte-de coche, siendo una agregación con contenido físico.

La agregación no implica no implica siempre contenido físico, como en el caso de

Coche, sino que puede implicar simplemente relaciones conceptuales. Así un Edificio

puede componer de Divisiones, que a su vez constan de Oficinas, o bien una Compañía

consta de varios Departamentos y cada Departamento consta de varias secciones.

En la agregación por referencia, conceptual o sin contenido físico no existe fuerte

dependencia entre objetos de las clases continente / contenido y no están acoplados entre

ellos. Eso significa que se pueden crear y destruir instancias de clase independiente.

Coche

Motor Chasis Transmisión Puerta

Parte-de

Parte-de Parte-de

Parte-de

Compañía

Departa-

mento

Edificio

División

Sección Oficina


Asociación

Una asociación representa una dependencia semántica entre clases e implica la

dirección de esta dependencia. En general, las asociaciones son bidireccionales, aunque

pudiesen ser unidireccionales si así se indica expresamente.

Una relación de asociación define una relación de pertenencia. Para encontrar

relaciones de asociación es preciso buscar frases tales como “pertenece a”, “es miembro

de”, “está asociado con”, “trabaja para”, etc.

Las asociaciones pueden ser unitarias, binarias, ternarias o de cualquier otro orden,

aunque la mayoría serán binarias. Una propiedad importante intrínseca a la relación de

asociación o multiplicidad es la cardinalidad o multiplicidad. La multiplicidad es la

propiedad que expresa el número de instancias de una clase que se asocian o conectan con

instancias de la clase asociada. Existen tres tipos de multiplicidad o cardinalidad:

Una a una

Una a muchas

Muchas a muchas

Una relación una a una implica una relación estrecha entre objetos. Por ejemplo, una

relación entre una clase venta de un producto y la clase operaciónTD que representa la

operación o pago de la venta mediante una tarjeta de crédito. Cada venta se corresponde

con una operación de una tarjeta de crédito y a la inversa. Otro ejemplo es la relación entre

País y Capital. Un país tiene una capital y sólo una, y una ciudad que es capital de un país

sólo pertenece a un país.

Una relación una a muchas se puede ver entre las clases País y Ciudad. Un país

tiene muchas ciudades, mientras que una ciudad sólo pertenece a un país. Otro ejemplo se

da entre la clase Línea, Circunferencia, o en general Figura y la clase Punto. Cualquier

figura puede tener muchos puntos, y un punto se asocia a una figura.

Las clases Ventas y Artículo se enlazan también por una relación una a muchas.

Una venta puede constar de muchos artículos.

Por último, la multiplicidad muchas a muchas, implica que una instancia de una

clase puede corresponder con muchas instancias de otra clase, y viceversa. Las clases

Estudiante y Asignatura están relacionadas con asociaciones de multiplicidad muchas a

muchas. Un estudiante puede estar inscrito en muchas asignaturas, y en una asignatura

determinada pueden estar inscritos muchos alumnos.

Juan Pérez IBM Trabaja-para


Las relaciones de multiplicidad o cardinalidad se indican de muy diversas formas,

según sea la metodología de análisis y diseño orientada a objetos que se utilice. Las

notaciones más usuales son:

4. Polimorfismo

Hace referencia a la posibilidad de que dos métodos implementen distintas acciones,

aun teniendo el mismo nombre, dependiendo del objeto que lo ejecuta o de los parámetros

que recibe.

La palabra polimorfismo proviene del griego, y significa que posee varias formas

diferentes. Este es uno de los conceptos esenciales de una programación orientada a

objetos. Así como la herencia está relacionada con las clases y su jerarquía, el polimorfismo

se relaciona con los métodos.

El polimorfismo permite referirse a objetos de clases diferentes mediante el mismo

elemento. Imaginamos que disponemos de una clase profesor (Teacher) que también hereda

de ser persona (Person) y que ambas disponen del método trabaja (work) y que ambos

evidentemente lo hacen de una forma distinta.

En general, hay tres tipos de polimorfismo:

Polimorfismo de sobrecarga

Polimorfismo paramétrico (también llamado polimorfismo de plantillas)

Polimorfismo de inclusión (también llamado redefinición o subtipado)

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

1..n, 1-m una a muchas 1 n

una a muchas

0,1, 0-1 opcionalidad 0 1

opcionalidad

m..n, m-n una a muchas n m

una a muchas

una a una


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

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.

Por lo tanto, podemos por ejemplo, definir varios métodos homónimos de addition()

efectuando una suma de valores.

El método entero addition(entero, entero) devolvería la suma de dos números

enteros.

real addition(real, real) devolvería la suma de dos flotantes.

caracter addition(caracter, caracter) daría por resultado la suma de dos caracteres

definidos por el autor.

Una signature es el nombre y tipo (estático) que se da a los argumentos de una

función. Por esto, una firma de método determina qué elemento se va a llamar.

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.

5. Encapsulamiento

La encapsulación es un mecanismo que consiste en organizar datos y métodos de

una estructura, conciliando el modo en que el objeto se implementa, es decir, evitando el


acceso a datos por cualquier otro medio distinto a los especificados. Por lo tanto, la

encapsulación garantiza la integridad de los datos que contiene un objeto.

El usuario de una clase en particular no necesita saber cómo están estructurados los

datos dentro de ese objeto, es decir, un usuario no necesita conocer la implementación Al

evitar que el usuario modifique los atributos directamente y forzándolo a utilizar funciones

definidas para modificarlos (llamadas interfaces), se garantiza la integridad de los datos

(por ejemplo, uno puede asegurarse de que el tipo de datos suministrados cumple con

nuestras expectativas bien que los se encuentran dentro del periodo de tiempo esperado).

La encapsulación define los niveles de acceso para elementos de esa clase. Estos

niveles de acceso definen los derechos de acceso para los datos, permitiéndonos el acceso a

datos a través de un método de esa clase en particular, desde una clase heredada o incluso

desde cualquier otra clase. Existen tres niveles de acceso:

público: funciones de toda clase pueden acceder a los datos o métodos de una clase

que se define con el nivel de acceso público. Este es el nivel de protección de datos

más bajo

protegido: el acceso a los datos está restringido a las funciones de clases heredadas,

es decir, las funciones miembro de esa clase y todas las subclases

privado: el acceso a los datos está restringido a los métodos de esa clase en

particular. Este es nivel más alto de protección de datos

Hacer las variables que son innecesarias para el tratamiento del objeto pero

necesarias para su funcionamiento privadas, así como las funciones que no necesitan

interacción del usuario o que solo pueden ser llamadas por otras funciones dentro del objeto

(Como por ejemplo, palpitar)

La encapsulación es muy conveniente y nos permite colocar en funcionamiento

nuestro objeto en cualquier tipo de sistema, de una manera modular y escalable (algunas de

las reglas de la ingeniería del software).

La técnica del encapsulamiento consiste en reunir todos los elementos que

pertenecen a una misma entidad y otorgarles un determinado nivel de aislamiento según

convenga. El aislamiento protege a los datos asociados a un objeto contra su modificación

por actores que no tengan derecho sobre ellos. Gracias a esto el usuario de la clase solo se

ha de concentrar en el uso de la misma y no en como realmente funcionan sus métodos.

Una clase representa la encapsulación de una abstracción. Esto, nos viene a decir que cada

clase ha de tener dos partes, una Interfaz y una implementación. La interfaz sería una

definición de los elementos de la clase y la implementación corresponde al funcionamiento

de la misma.

Conceptos del paradigma orientado a objetosbbeltran.cs.buap.mx/Unidad1.pdf · MC Beatriz Beltrán...

Documents

Transcript of Conceptos del paradigma orientado a objetosbbeltran.cs.buap.mx/Unidad1.pdf · MC Beatriz Beltrán...