Manual de Programacion Orientada A Objetos

Introduccin al Paradigma de Objetos
1. LOS PARADIGMAS......................................................................................................................................3
1.1. QUE ES UN PARADIGMA .............................................................................................................................3
1.2. EL PARADIGMA DE OBJETOS .....................................................................................................................3
1.3. LA PROGRAMACIN ORIENTADA A OBJETOS .............................................................................................4
1.4. POR QUE OBJETOS ......................................................................................................................................4
2. MODELADO DE OBJETOS ........................................................................................................................6
2.1. QUE ES UN MODELO ..................................................................................................................................6
2.2. QUE ES UN OBJETO ....................................................................................................................................6
2.3. QUE ES UN MENSAJE .................................................................................................................................7
2.4. QUE ES EL COMPORTAMIENTO ...................................................................................................................7
2.5. QUE ES UN AMBIENTE................................................................................................................................8
2.6. EL SOFTWARE ORIENTADO A OBJETOS ......................................................................................................9
3. INTRODUCCIN AL PARADIGMA DE OBJETOS ...............................................................................9
3.1. LOS OBJETOS Y LAS CLASES ......................................................................................................................9
3.2. LOS ATRIBUTOS.......................................................................................................................................11
3.3. LOS TIPOS DE DATO ................................................................................................................................11
3.4. LAS OPERACIONES...................................................................................................................................12
3.5. LA VISIBILIDAD .......................................................................................................................................13
3.6. EL ENCAPSULAMIENTO............................................................................................................................14
3.7. LOS CONSTRUCTORES .............................................................................................................................15
3.8. LA SOBRECARGA DE OPERACIONES .........................................................................................................16
3.9. MECANISMO DE HERENCIA ......................................................................................................................17
3.10. POLIMORFISMO ......................................................................................................................................20
3.11. ATRIBUTOS DE CLASE ...........................................................................................................................22
3.12. OPERACIONES DE CLASE .......................................................................................................................23
4. INTRODUCCIN A UML..........................................................................................................................24
4.1. QU ES UML ...........................................................................................................................................24
4.2. COMO NACE UML ...................................................................................................................................24
4.3. DONDE SE UTILIZA ...................................................................................................................................25
5. INTRODUCCIN A LOS DIAGRAMAS DE UML ................................................................................26
5.1. INTRODUCCIN ........................................................................................................................................26
5.2. DIAGRAMA DE CLASES ............................................................................................................................26
5.3. DIAGRAMA DE OBJETOS ..........................................................................................................................26
5.4. DIAGRAMA DE CASOS DE USO .................................................................................................................26
5.5. DIAGRAMA DE ESTADOS ..........................................................................................................................26
5.6. DIAGRAMA DE ACTIVIDADES ..................................................................................................................27
5.7. DIAGRAMA DE COMUNICACIN ...............................................................................................................27
5.8. DIAGRAMA DE SECUENCIA ......................................................................................................................27
5.9. DIAGRAMA DE COMPONENTES ................................................................................................................27
5.10. DIAGRAMA DE DESPLIEGUE...................................................................................................................28
6. CLASIFICACIN DE DIAGRAMAS .......................................................................................................29
6.1. CATEGORAS ............................................................................................................................................29
6.2. DIAGRAMAS ESTTICOS ..........................................................................................................................29
6.3. DIAGRAMAS DINMICOS .........................................................................................................................29
6.4. DIAGRAMAS ESTRUCTURALES .................................................................................................................30
6.5. DIAGRAMAS DE COMPORTAMIENTO ........................................................................................................30
7. LABORATORIOS .......................................................................................................................................31
7.1. CONSIGNA ...............................................................................................................................................31
7.2. CASO DE ESTUDIO ...................................................................................................................................31
www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Lavalle 648 8vo Piso Capital Federal
Copyright 2011-Actualidad, educacionIT. Todos los derechos estn reservados
Pgina 1
7.3. EJERCICIO #1 DETECCIN DE CLASES ...................................................................................................32

7.4. EJERCICIO #2 DETECCIN DE ATRIBUTOS .............................................................................................33
7.5. EJERCICIO #3 DETECCIN DE OPERACIONES .........................................................................................34
7.6. EJERCICIO #4 RELACIONES SIMPLES .....................................................................................................35
7.7. EJERCICIO #5 RELACIONES MLTIPLES ................................................................................................36
7.8. EJERCICIO #6 USO DE OBJETOS .............................................................................................................37
7.9. EJERCICIO #7 HERENCIA .......................................................................................................................38
8. DIAPOSITIVAS ...........................................................................................................................................39

Pgina 2
1. Los Paradigmas
1.1. Que es un Paradigma
Un Paradigma es un concepto abstracto, la definicin de un modelo o patrn en
cualquier disciplina fsica.
Todo
paradigma
nace
de
la
filosofa
de
una
comunidad
cientfica
que,
especializada en un tema particular, decide plantear algn nuevo concepto

abstracto o forma de pensar. En este caso en particular, una parte de la
comunidad cientfica que estudiaba la computacin como una rama matemtica y
se especializaba en ello, forja esta nueva ideologa o forma de pensar que es el
Paradigma de Programacin Orientado a Objetos.
En programacin, el paradigma, nos determina como van a ser los bloques de
construccin de los programas, es decir, los elementos que los constituyen.
1.2. El Paradigma de Objetos

El paradigma de programacin orientada a objetos plantea que todo sistema o
proceso informtico puede modelarse con Objetos que se encuentren vivos en
algn tipo de Ambiente y se relacionan con otros Objetos enviando y recibiendo
Mensajes.
Es decir, programar bajo este paradigma, implica que
nuestros programas,
debern ser pensados slo con objetos y mensajes.

Un objeto, en OOP, es un ente completamente abstracto que sabe escuchar,
responder y enviar ciertos mensajes.
Un Mensaje es una comunicacin dirigida de un objeto a otro. Informacin
enviada desde emisor, hasta el receptor.
El paradigma de objetos tiene otros conceptos que completan este esquema de
Objeto-Mensaje, que se irn detallando a lo largo del curso.
Como todo concepto terico o abstracto que quiera ser llevado a la vida real o a
la prctica, requiere de algn tipo de implementacin.

Pgina 3
Si queremos desarrollar un software, con la idea terica o paradigma nicamente

no nos alcanzara, es necesario tener algo concreto con lo cual trabajar, una
implementacin del paradigma.
Un
paradigma,
en
tanto
que
es
un
concepto
terico,
tiene
infinitas
implementaciones. A la vez, por este mismo motivo, una implementacin es una

y slo una instancia posible que responde al Paradigma.
Cuando hablamos de una implementacin estamos hablando de un lenguaje de
programacin orientado a objetos (es decir, que contempla los conceptos tericos
del paradigma orientado a objetos). Cada uno de estos lenguajes implementar
cada uno de estos conceptos de forma diferente. Por eso es importante
diferenciar los conceptos del paradigma de la implementacin del paradigma.
Es decir, por ejemplo, primero es necesario conocer la definicin de un objeto
segn el paradigma, y luego, conocer la implementacin de un objeto para
determinado lenguaje de programacin.
Vamos a ir clarificando cada uno de estos conceptos a lo largo de las clases.
1.3. La Programacin Orientada a Objetos

OOP (Object Oriented Programming o en espaol Programacin orientada a
objetos en ingles) se basa en el concepto de agrupar cdigo y datos juntos en
una misma unidad llamada clase. Este proceso es usualmente referido como
encapsulamiento o informacin oculta.
Estas clases son esencialmente la representacin de un set de funciones
(llamadas mtodos) y variables (llamadas propiedades) designadas para trabajar
juntas y proveer una interfaz especifica.
Es importante entender que las clases son una estructura que no puede ser
utilizada directamente, estas deben ser instancia das en objetos, los cuales
podrn as interactuar con el resto de las aplicaciones.
Es posible pensar en clases como un plano para crear un auto, mientras el objeto
es de hecho el auto en si mismo, ya que se puede crear en una lnea de
produccin. Podramos decir que una clase es una fbrica de objetos.
1.4. Por que objetos

Pgina 4
La programacin orientada a objetos tiende a ser una simple idea. Esta simple
idea es: en lugar de crear estructuras de datos por un lado y cdigo por el otro,
la idea es asociar piezas de cdigo junto con los datos.
El mercado de lenguajes de programacin, tiende a utilizar este paradigma ya
que trae innumerables ventajas con respecto a la programacin estructurada.
A continuacin se enumeran algunas de ellas:
Escalabilidad: Capacidad de crecimiento. Que un sistema sea escalable,

significa que esta preparado para poder crecer sin limitaciones ni perjuicios.
En casos de desarrollo corporativos como por ejemplo el de un sistema
bancario,
donde constantemente se necesitan agregar nuevos mdulos y
cambios en su comportamiento, es necesario contar con lenguaje de

programacin que permita fcilmente administrar estos tipos de desarrollos
empresariales.
Mantenimiento: Una de las principales caractersticas del paradigma de

objetos, es su capacidad realizar cambios en el programa a muy bajo costo
(esfuerzo del programador). Gracias a una buena organizacin de las clases y
sus herencias es posible hacer pequeos pero importantes cambios que
impacten luego en todas las partes del sistema.
Seguridad: Este paradigma posee lo que se denomina como encapsulamiento

y visibilidad lo cual permite establecer diferentes niveles de seguridad dentro
de un equipo de desarrolladores, organizando el trabajo en equipo y limitando
la
posible
existencia
de
errores
incongruencias
cometidos
por
los
programadores.
Reutilizacin: A travs de la correcta utilizacin de jerarqua de clases, y la

redefinicin de funciones polimorfismo, se puede reutilizar un importante
porcentaje de cdigo, evitando escribir subprogramas parecidos dentro de un
mismo desarrollo.
Simplicidad: Cuando el cdigo de un programa desarrollado con lenguaje

estructurado, crece indefinidamente, se llega a un punto donde el mismo se
vuelve confuso y engorroso. El paradigma de objetos provee simplicidad al
poder organizar la complejidad del mismo a travs de su estructura de clases
y objetos.

Pgina 5
2. Modelado de Objetos
2.1. Que es un Modelo
Un modelo es una posibilidad de visualizar a escala o de una manera simulada
algo que ser construido en la realidad. Es posible decir que antes de construir un
edificio se realizan maquetas a escala que representa modelos a seguir, as como
tambin cuando se construye un auto se confeccionan distintos planos o modelos
a escala para intentar simular o prever su comportamiento.
Acadmicamente, es posible definirla como una abstraccin de la realidad, es una
simplificacin de la realidad, con el objetivo final de pasar del modelo a producto
real.
Los modelos pueden ser expresados en distintos niveles de precisin, desde algo
muy genrico presentando una visin, hasta algo mucho mas especifico que
representa un gran compromiso con el producto a construir.
2.2. Que es un Objeto

Un objeto en OOP es un ente completamente Abstracto que sabe escuchar,
responder, y enviar ciertos mensajes.
Bajando
ms
informtica,
podemos
definir
un
objeto
como
un
ente
computacional, que est dentro del software, y puede representar o no un ente

de la realidad que est fuera de la computadora.
Por ejemplo, un objeto Persona, o un Usuario, puede representar una persona
real, en el manejo de usuarios de una aplicacin.
Si seguimos con el ejemplo de Persona, una persona puede comer, vestirse,
trasladarse, leer, y muchas cosas ms! Si revisamos la primera definicin, dice
que sabe responder ciertos mensajes entonces, estos son, los mensajes de los
que hablbamos.
Y quin le enva los mensajes?
La respuesta es fcil, otro objetos, recordemos, que en el paradigma de objetos,
slo tenemos objetos y mensajes, y nada ms.
Y que pasa con los nmeros? Tambin son objetos?

Pgina 6
Va a depender del lenguaje. En principio, en un lenguaje orientado a objetos,

todo debera ser un objeto, pero esto no es tan as, existen algunos lenguajes
que eligen no respetar eso a rajatabla y modelan algunos conceptos muy bsicos
como tipos primitivos, como por ejemplo los nmero, los booleanos, los
caracteres.
2.3. Que es un Mensaje

En una aplicacin orientada a objetos, entonces, tenemos objetos que se piden
cosas entre s. Por lo que, un mensaje, es una comunicacin entre dos objetos,
emisor y receptor, donde el emisor le pide algo al receptor, y puede (o no)
obtener algo como respuesta.
Por ejemplo, si a un objeto Persona le pido que me diga su edad, voy a recibir
como respuesta un nmero que representa la edad de la persona.
Si tengo un objeto Alumno, podra pedirle los cursos que est haciendo
actualmente, y en este caso que me devuelve? Me devuelve un objeto que
representa el conjunto de cursos que esta haciendo.
Un objeto entiende cualquier mensaje que se le enva?
No! Nosotros, como programadores de objetos, debemos definir cuales son los
mensajes que entiende cada objeto.
Y que pasa si le mando un mensaje que no entiende?
Esto depender del lenguaje, pero en principio, esto causa un error, ya que si un
objeto no entiendo el mensaje que se le est mandando, entonces nuestro
programa no estara andando bien.
2.4. Que es el Comportamiento

Pgina 7
Ya dijimos que un objetos era un ente abstracto, que saba enviar y responder
mensajes. Y que nosotros debemos definir cuales son los mensajes que un objeto
debe entender.
El comportamiento, es el conjunto de mensajes que un objeto entiende, y a los
que me puede o no responder. Lo importante, es que lo entiende.
Con este nuevo concepto, podramos entonces entender un objeto como:
Un ente computacional que exhibe comportamiento.
De esta forma, dado un objeto, por ejemplo Persona, uno podra preguntar, cul
es el comportamiento de una Persona? Y ah uno debe responder con todo lo que
el objeto persona sabe hacer. Esto, lo define el programador de ese objeto.
Dicho de otra manera, el comportamiento son las cosas que sabe hacer un
objeto, el conjunto de mensajes que un objeto le va a poder enviar.
2.5. Que es un Ambiente

Los objetos nacen y mueren, o sea viven. En general nacen porque alguien los
creo quin es ese alguien? un objeto! como todo... y se mueren porque alguien
los destruye, esto tambin depender del lenguaje, pero vamos a hablar de esto
ms adelante.
Los objetos viven dentro de la computadora, en algn lugar determinado, que
es el responsable de contenerlos, manejar su ciclo de vida, dar el contexto para
la creacin y el envo de mensajes.

Pgina 8
2.6. El Software Orientado a Objetos

Con estos conceptos, podemos decir que es el software. Es el resultado de la
interaccin de un conjunto de objetos que viven en un ambiente y que se
comunican entre s envindose mensajes.
Es importante definir software desde el punto de vista de la programacin
orientada a objetos, ya que esta es la forma que voy a tener de pensar en una
programa, en la construccin de un programa.
Entonces, de ahora en ms, para pensar un programa, tenemos que pensar:
Que objetos vamos a incluir en la aplicacin
Que mensajes va a entender cada objeto
Como van a interactuar los objetos entre s
3. Introduccin al Paradigma de Objetos

3.1. Los Objetos y las Clases
En este paradigma todo se lleva a cabo con clases y objetos. Qu es un
objeto? Un objeto
es un conjunto
de
atributos (estado) y operaciones
(comportamiento).
Debemos entender los objetos como abstracciones de la realidad con ciertas
caractersticas
representativas.
Estos
objetos
representan
(o
deberan
representar) ideas del mundo real, ideas concretas como por ejemplo animales o
personas.
En el POO (Paradigma Orientado a Objetos) existen dos conceptos claves que
deben ser comprendidos, los conceptos de clase y objeto.
Las clases son plantillas que contienen atributos y operaciones, se consideran los
moldes para los objetos. Las clases se detectan como sustantivos en singular el
99%
de
las
veces,
esto
significa
que
suelen
tener
nombres
como
CuentaCorriente o Automovil.
Ahora bien, qu es un objeto exactamente? Un objeto es la instancia de una
clase, podemos decir que el objeto representa algo en particular y la clase algo

Pgina 9
en general. Por ejemplo si tuviramos la clase Automovil, podramos crear las

instancias (objetos) llamados renault, volkswagen o ford.
Si tenemos una clase CuentaBancaria, podemos tener infinita cantidad de

objetos de CuentaBancaria, pero cada una tendr sus valores individuales,
aunque todas pertenezcan a esta clase.
Decimos que un objeto pertenece a una clase, cuando es una instanciacin de esa
clase; es decir, al crear un objeto de la clase Banco y asignarle el nombre
bancoNacion, el objeto bancoNacion es una instanciacin de Banco.
Continuando con este ejemplo, podramos crear ms instanciaciones de Banco y
asignarles nombres como bancoRio o bancoCityBank, y todos ellos tendran
algo en comn, que pertenecen a la clase Banco, a pesar de que cada objeto
tenga sus distintos valores, como por ejemplo, distinta cantidad de clientes, de
sucursales, etc (representados por los atributos).
A continuacin se muestran algunas clases representadas grficamente:

Pgina 10
Las clases estn compuestas por atributos y operaciones, y sern presentadas a

continuacin.
3.2. Los Atributos

Como mencionamos anteriormente, los atributos son las variables contenidas por
los objetos. Las clases definen los atributos y los objetos los completan. Las
variables de una clase definen las caractersticas de sus objetos, por ejemplo:
En este caso creamos una clase Automovil y colocamos atributos color, modelo,
precio, y usado que al adquirir valores en un objeto, lo diferenciarn a este de
otras instancias (objetos) de la clase Automovil.
Lo mismo podramos hacer con una clase CuentaBancaria, como se muestra a
continuacin:
En este caso la clase CuentaBancaria cuenta con un atributo saldo.

En resumen, los atributos son las caractersticas de una clase.
3.3. Los Tipos de Dato

Podemos encontrar la definicin de atributo, mediante la cual definimos que un
objeto tiene un conjunto de caractersticas que lo describe, y que se definen en
una clase.
Por ejemplo, el atributo nombre, va ser una palabra, es decir, va a ser un String,
de la misma manera, la edad, es un nmero, es decir, va a ser un int.
int y String son tipos. Un tipo es la forma de describir o almacenar un dato.
Cuando decimos que tenemos un dato del tipo int, estamos diciendo que podra
ser cualquier nmero de tipo entero.

Pgina 11
De la misma manera, un objeto Persona podra tener un atributo Trabajo,

donde trabajo es tambin un objeto con sus propias caractersticas, es decir, el
trabajo podra tener un empleador, un nombre, una ubicacin, etc. De esta
manera, estamos diciendo que Persona, tiene como atributo Trabajo, que ser
de que tipo? De tipo trabajo!
Ac empezamos a ver la potencia de los objetos.
Anteriormente, nosotros trabajbamos con un conjunto acotado de tipos para
las variables (int, String, boolean, etc), ahora, con los objetos, nosotros podemos
crear nuestros propios tipos. Cualquier clase que nosotros creamos, de ahora
en ms, eso va a ser un nuevo tipo con el que podemos trabajar.
De la misma manera si creamos un clase Banco, de ahora en ms vamos a
tener objetos que son instancias de la clase Banco, o tambin podemos decir que
tenemos objetos del tipo Banco.
3.4. Las Operaciones

Las operaciones son acciones contenidas por el
objeto que
definen su
comportamiento.
En este caso hemos agregado dos operaciones a la clase Automovil. Estas

operaciones le permiten acelerar o frenar, como indican sus respectivos nombres
(cuanto ms autoexplicativos sean los nombres, mejor).
Las operaciones son, en el 99% de los casos, verbos.
Las operaciones pueden admitir parmetros. Los parmetros son variables que
utilizar la operacin para generar cierto comportamiento. Las operaciones
acelerar y frenar tienen como parmetros dos valores int (nmeros enteros)
que representan la velocidad y el tiempo que acelerar o frenar.
Las operaciones de una clase CuentaBancaria podran ser las siguientes:

Pgina 12
Las operaciones depositar y extraer tienen un solo parmetro, este parmetro

representa el monto a extraer o depositar.
En resumen, las operaciones son acciones contenidas por un objeto que definen
su comportamiento.
3.5. La Visibilidad
La visibilidad o accesibilidad determina el alcance que tiene un atributo u
operacin. El alcance (scope) de un miembro representa qu partes pueden
acceder a dicho miembro. El alcance est determinado por los modificadores de
visibilidad, presentados como publico (su simbologa es el signo +) y como
privado (su simbologa es el signo -)
Que un atributo u operacin sea privado significa que aquel atributo u operacin
solo puede ser accedido desde dentro del objeto que lo contiene. En cambio si
este atributo u operacin fuera pblico podra ser accedido por cualquier objeto.
En el siguiente ejemplo podemos ver los miembros pblicos y privados de la clase
Auto diferenciados por los signos - y +:
Esto mismo se puede aplicar con la clase CuentaBancaria:
Una de las dudas que surgen a la hora de entender los modificadores de acceso
es por qu debera de tener un miembro privado?. Hacer que un atributo sea

Pgina 13
privado se utiliza para tratar con datos o valores los cuales no queremos que
sean accedidos ms que por el objeto contenedor. Las operaciones privadas
cobran sentido como procesamientos internos del objeto que no queremos sean
accedidas por otros objetos (tanto porque no tiene sentido que la accedan otros
objetos como porque podra resultar peligroso para la integridad del objeto
contenedor).
El porqu de utilizar miembros privados se aclarar a continuacin junto con el
tema Encapsulamiento.
En resumen, la visibilidad determina el alcance (scope) del atributo u operacin
en cuestin
3.6. El Encapsulamiento
El encapsulamiento es una de las caractersticas representativas de la POO. Este
concepto tiene que ver con la forma correcta de pensar en clases y objetos.
Significa aislar o independizar las clases de nuestro programa de tal manera que
su funcionamiento sea independiente del de las otras clases.
La clase Automovil posee un atributo privado que representa la velocidad y

posee una operacin pblica que le permite interactuar con otros objetos. Esta
operacin recibe como parmetro un valor que representa la velocidad que se le
quiere asignar a dicho automvil. Si esta operacin recibiera un valor negativo,
podra pasarlo a un nmero positivo, mantener la velocidad anterior o hacer
cualquier otra cosa evitando que aparezcan errores en el objeto por un dato
invlido (velocidad negativa). Si en vez de utilizar un atributo privado y una
operacin pblica, utilizramos directamente un atributo pblico, este tipo de
casos no podran ser manejados y se atentara contra la integridad del objeto.
El ocultamiento puede visualizarse mejor en el siguiente grfico:

Pgina 14
El grafico representa que los atributos estn encerrados por operaciones, es decir
que los atributos son privados y las operaciones son pblicas. Esto significa que
para poder acceder a un atributo es necesario utilizar una operacin, es decir que
no hay posible acceso al atributo sino no se utiliza una operacin.
A continuacin se presenta el encapsulamiento con la clase CuentaBancaria:
Para poder modificar al atributo saldo, es necesario hacerlo a travs de las

operaciones depositar() o extraer().
En resumen, el encapsulamiento es la capacidad que tienen las clases de permitir
que ciertos miembros sean accesibles y ciertos miembros no lo sean, y as lograr
ocultar el estado interno de sus instancias.
3.7. Los Constructores

Toda clase tiene un constructor. Los constructores son operaciones que son
invocadas al instanciar una clase. Los constructores se encargan de inicializar
atributos y configurar todo lo que sea necesario antes de que comience a existir
el objeto.
Al
tratarse
de
operaciones,
los
constructores pueden
contener
cualquier
comportamiento, aunque estas no tengan que ver exactamente con construir el

objeto. Es posible tener ms de un constructor en una misma clase; en este caso,
cada constructor debe aceptar parmetros distintos para poder as distinguirlos.

Pgina 15
Los constructores suelen llamarse con el mismo nombre de las clases, como se
muestra a continuacin:
Por lo tanto la clase Automovil tendr un constructor llamado Automovil(), y

la clase CuentaBancaria tendr un constructor llamado CuentaBancaria(). En
los ejemplos anteriores los constructores no tienen parmetros.
En resumen, un constructor es una operacin que es invocada al instanciar una
clase.
3.8. La Sobrecarga de Operaciones

As como es posible tener ms de un constructor (que es una operacin), es
posible tener ms de una operacin con el mismo nombre dentro de la misma
clase. Para poder hacer esto es necesario que se cumplan las mismas condiciones
que para los constructores, es decir, que cada sobrecarga de operacin tenga
distintos tipos de parmetros.
Para qu podra servir tener varias operaciones con el mismo nombre pero con
distintos parmetros? Por ejemplo, si quisiramos crear una operacin llamada
extraer() que extraiga un determinado saldo de una cuenta, podramos querer
utilizarla sin determinar un tipo de moneda (utilizando la moneda del pas como
por defecto), o determinando un tipo de moneda para hacer la extraccin de
ese tipo de moneda (euro, dlar, etc).
La sobrecarga de operaciones nos permite utilizar el mismo nombre de operacin
para dos operaciones distintas, es decir, que aceptan distintos parmetros y
tienen distinta funcionalidad. Sin la existencia de este mecanismo, se debera
crear una operacin distinta por cada versin de nuestra operacin. Sin la
sobrecarga de operaciones, las operaciones estn limitadas a los parmetros de
una sola definicin de operacin.

Pgina 16
Si quisiramos aplicar la sobrecarga de operaciones en una clase Automovil:
La operacin acelerar() tiene dos definiciones, en una acepta como argumento

la cantidad de tiempo que debe acelerar, y en la otra la cantidad de tiempo que
debe acelerar y si el auto utiliza turbo o no, representado por el segundo
parmetro de tipo booleano
En resumen, la sobrecarga de operaciones es la capacidad de poder crear
comportamientos distintos para la misma operacin aceptando distintos tipos de
parmetros.
3.9. Mecanismo de Herencia

El mecanismo de herencia es otro de los conceptos clave de la POO, y uno de sus
puntos fuertes. Este mecanismo nos permite que una clase "herede de otra clase"
o "extienda otra clase" recibiendo o heredando todos los atributos y operaciones
de su clase "padre".
En el siguiente diagrama podemos ver como est compuesto un tpico rbol de
herencia simple:

Pgina 17
En el diagrama anterior vemos como una clase puede tener tanto superclases
como subclases. Esto significa que una clase hereda de una superclase o clase
padre, y es heredada por subclases o clases hijas. La flecha indica quien
hereda a quien, es decir, el origen de la flecha es la clase hija y el destino de la
flecha es la clase padre.
Se considera clases hijas a las clases que heredan directamente de una clase y
subclases tanto a las clases hijas como al resto de clases que tengan menor
jerarqua en el rbol de herencia; se considera clase padre a la clase de la que se
hereda directamente.
Cuando una clase hereda de otra, todas las operaciones y atributos pasan a estar
disponibles en la clase hija, es decir que partimos de todos estos elementos e

Pgina 18
incluso podemos agregar nuevos o modificar estos ya heredados. Con las clases
heredadas ampliamos la descripcin de un concepto de la vida real, lo volvemos
ms especfico.
Para comprender mejor la herencia y la naturaleza de las clases heredadas, es
necesario entender que una clase hija es ms especfica conceptualmente que la
clase padre, a la vez que la clase padre es ms general conceptualmente que la
clase hija. Esto lo podemos visualizar mejor de la siguiente manera:

Pgina 19
En este diagrama podemos ver a la clase padre Vehiculo y su rbol de herencia.

Por comodidad no hemos colocado las clases hijas de las clases VehiculoAereo y
VehiculoAcuatico. Qu tendran en comn las clases Avion y Motocicleta?
Que ambas clases tienen como superclase a la clase vehculo, es decir, ambas
SON Vehculo.
Es importante destacar que una clase ES UN cualquiera de sus superclases, es
decir: Motocicleta ES UN VehiculoTerrestre y ES UN Vehculo,
Con cada subclase, se amplia la cantidad de elementos de dicha clase con
respecto a sus superclases, volvindola ms especfica. As, por ejemplo, la clase
vehculo hace referencia a cualquier tipo de transporte, en cambio la clase
VehiculoTerrestre hace referencia a cualquier tipo de transporte que se desplace
en un medio slido, y la clase Automovil hace referencia a un tipo de transporte
especfico. Podramos ir ms all en el rbol de herencia y crear clases para cada
modelo de automvil y hacer que extiendan a la clase Automovil.
Otro rbol de herencia podra ser el siguiente:
En este caso, la clase padre es CuentaBancaria y las clases hijas son

CajaDeAhorro
CuentaCorriente,
donde
CajaDeAhorro
ES
UNA
CuentaBancaria y CuentaCorriente ES UNA CuentaBancaria

Resumiendo, el mecanismo de herencia es la capacidad que tienen las clases de
recibir el comportamiento (operaciones) y estado (atributos) de otras clases.
3.10. Polimorfismo
Otro mecanismo presente en el POO es el polimorfismo. En el POO encontramos
dos tipos de polimorfismo, uno de ellos ya lo vimos y se conoce comnmente
como "Sobrecarga de Operaciones". El otro, el que veremos ahora, tiene que ver
con la capacidad que tienen las clases de redefinir el comportamiento de una
operacin heredada de la clase padre.

Pgina 20
Esto significa que, en una clase padre conceptualmente ms general, al tener un

mtodo al cual le dimos cierto comportamiento bsico, que puede no ser
exactamente lo que debe suceder al invocar ese mtodo desde un objeto
correspondiente a una clase hija, debemos sobrescribir esa operacin en la clase
hija con la funcionalidad o comportamiento apropiado. Si la clase hija no
redefiniera ese comportamiento, el comportamiento sera el mismo de la clase
padre (tras invocar a dicho mtodo).
Por lo cual, tendramos una clase padre con la operacin hacerAlgo que hace x
cosa, y una clase hija con la operacin hacerAlgo que hace y cosa., es decir
que la misma operacin tiene comportamientos distintos segn la clase
En el siguiente caso:
La clase AutomovilDeCarrera debe reemplazar el comportamiento de la

operacin acelerar() heredado de la clase Automovil, ya que el tipo de
aceleracin es completamente distinta. Lo mismo sucede con las siguientes
clases:

Pgina 21
En este caso, las operaciones extraer() de ambas clases deben tener

comportamientos distintos debido a que el lmite de dinero a extraer es distinto
en cada clase. La clase CajaDeAhorro no tiene la posibilidad de extraer en
descubierto, sin embargo la clase CajaDeAhorroConDescubierto permite extraer
dinero aun cuando ya no hay mas saldo en la caja. Es decir que ambas clases
permiten extraer dinero pero de formas distintas.
En resumen, el polimorfismo es el mecanismo que permite que un objeto sea
tratado como alguna de sus superclases conservando los miembros de su propia
clase.
3.11. Atributos de Clase

Tambin llamados atributos estticos, son atributos que pertenecen a la clase y
no a un objeto o instancia de clase. Esto significa que son atributos compartidos
por todos los objetos.
Por ejemplo en una clase CajaDeAhorroConDescubierto podramos declarar un
atributo esttico llamado descubierto que contenga el valor en pesos de
descubierto que puede brindar esa caja de ahorro a los clientes, es decir, no
necesitamos que cada instancia de CajaDeAhorroConDescubierto almacene un
valor independiente, sino tan solo uno que sirve para todas las instancias. Este es
el tipo de usos que se le da a los atributos estticos.
En el diagrama anterior el atributo descubierto aparece subrayado, esto es lo

que nos indica que es un atributo esttico. Lo mismo sucedera para una clase
Automovil con un atributo esttico velocidadMaxima:
En resumen, los atributos de clase (o estticos) son atributos que existen en la

clase y no en cada uno de los objetos, motivo por el cual son compartidos por
todos los objetos.

Pgina 22
3.12. Operaciones de Clase

Tambin llamadas operaciones estticas, son operaciones que corresponden a la
clase y no a las instancias de dicha clase, es decir a los objetos.
La explicacin es anloga a la presentada en el tema anterior de atributos de
clase.
En los siguientes ejemplos se aplican operaciones estticas:
Se debe observar que en ambas clases se dispone de un atributo esttico y dos

operaciones estticas, y en este caso ambas operaciones estticas se utilizan
modificar los atributos estticos.
En resumen, las operaciones de clase (o estticas) son operaciones que existen
en la clase y no en cada uno de los objetos, motivo por el cual son compartidos
por todos los objetos.

Pgina 23
4. Introduccin a UML
4.1. Qu es UML
UML es un lenguaje grafico que permite modelar, visualizar y documentar
sistemas. Esta compuesto por distintos diagramas que permiten ir representando
las distintas vistas de un sistema, cada diagrama tiene un objetivo bien definido.
UML significa Unified Modeling Language o Lenguaje Unificado de Modelado, y
esta basa en tres principios fundamentales:
Es un Lenguaje: est formado por elementos y reglas bien definidas,
que poseen su propia sintaxis y semntica
Esta Unificado: unifica los distintos criterios utilizados antes de su
creacin, es decir que toma las mejores propuestas de herramientas previas

para presentar una propuesta sumamente abarcativa e integradora
Permite Modelar: est basado en la construccin de modelos que
permite representar abstracciones de la realidad.

UML esta estrechamente ligado con el paradigma de objetos, lo que permite
construir sistemas de informacin de una forma mucho mas intuitiva, integrada y
sencilla con el proceso de desarrollo.
UML no es una metodologa que presenta los pasos a seguir para realizar un
desarrollo, sino que es un lenguaje grafico de modelado.
4.2. Como nace UML

La historia cuenta que UML da sus primeros pasos con al unin de los tres
amigos: Booch, Rumbaugh y Jacobson.
En los aos 80 cada uno utilizaba un lenguaje propietario aunque como
denominador comn tenan como objetivo el desarrollo de sistemas, con previa
modelizacin. A partir de los aos 90 comienzan a intercambiar ideas para
intentar unificar criterios.
Booch es el fundador de Rational Software Corp, y recluta en el ao 1995 a
Rumbaugh y Jacobson para comenzar a determinar una especificacin genrica,
sencilla y abarcativa.

Pgina 24
As es como las grandes empresas de tecnologas de informacin entre ellas

Rational - deciden forman un consorcio para la construccin de un Lenguaje
Unificado de Modelado: UML. La primer versin de UML, la 1.0, sale a la luz en el
ao 1997, y a partir de 1998 un organizacin llamada OMG (Object Management
Group) se encargo de generar nuevas revisiones. En el ao 1998 UML se
establece como Standard de facto en la industria del Software.
4.3. Donde se utiliza

UML se utiliza dentro del marco de IT, aunque puede utilizarse en proyectos que
no son de tecnologa de la informacin, como ser el modelado de un motor o de
una turbina.
En el campo de IT, se utiliza tanto para sistemas monolticos como para sistemas
distribuidos, abarca desde proyectos pequeos hasta grandes proyectos. Permite
realizar la integracin del software, donde representa el correcto enlace de los
roles para lograr el xito de la constriccin del sistema. En proyectos de software,
es utilizado desde la gestacin hasta la instalacin y el testing.
Si bien para utilizar UML es posible realizar los distintos diagramas con papel y
lpiz, es conveniente contar con alguna herramienta del tipo IDE que facilite su
construccin, correccin e integracin ente diagramas.

Pgina 25
5. Introduccin a los diagramas de UML

5.1. Introduccin
UML esta organizado en una serie de diagramas que tienen objetivos bien
definidos, con una sintaxis y semntica determinada, que intentan representar /
modelar distintas vistas de un sistema.
5.2. Diagrama de Clases

El Diagrama de Clases tiene como objetivo describir las clases del dominio y
sus relaciones. Permite modelar la estructura del sistema desde un punto de
vista esttico, modelando las clases desde distintos enfoques de acuerdo a la
etapa del proyecto.
Esta compuesto por clases, relaciones entre clases y opcionalmente los paquetes
que agrupan a las clases.
5.3. Diagrama de Objetos

El Diagrama de Objetos tiene como objetivo describir los objetos del dominio
y sus relaciones. Permite representar al sistema en un momento determinado
del tiempo, es proporcional a obtener una fotografa o snapshot del sistema en un
momento determinado.
Esta compuesto por objetos y relaciones de enlace. Tambin es posible pensarlo
como una instancia de un Diagrama de Clases.
5.4. Diagrama de Casos de Uso

El Diagrama de Casos de Uso tiene como objetivo describir las acciones del
sistema desde el punto de vista del usuario. Representa las formas que tiene
un usuario de utilizar un sistema, y se puede utilizar como un contrato entre
cliente y proveedor de software para determinar la funcionalidad del sistema, es
decir los requisitos funcionales.
Esta compuesto por actores (agentes externos al sistemas, pueden ser usuarios u
otros sistemas), casos de uso y distintos tipos de relaciones. Es posible construir
diagramas con diferentes niveles de detalle.
5.5. Diagrama de Estados

Pgina 26
El Diagrama de Estados tiene como objetivo describir los estados por los
cuales puede pasar un objeto durante su ciclo de vida. Permite modelar
tanto estas simples como compuestos y concurrentes.
Esta compuesto por estados, pseudo-estados y transiciones entre estados.
5.6. Diagrama de Actividades

El Diagrama de Actividades tiene como objetivo describir las acciones que
ocurren dentro de un proceso. Se utiliza principalmente para modelar flujo de
trabajo o workflow, con lo cual visualiza las acciones de manera ordenada.
Esta compuesto por acciones simples y concurrentes, y transiciones entre las
acciones.
5.7. Diagrama de Comunicacin

El Diagrama de Comunicacin tiene como objetivo describir como colaboran o
se comunican los distintos objetos entre s para conseguir un objetivo. Se
lo suele llamar tambin Diagrama de Colaboracin. Es posible verlo como una
extensin del Diagrama de Objetos, ya que es muy parecido pero tiene como
valor agregado los mensajes que se envan entre los objetos.
Esta compuesto por objetos, relaciones de enlace y relaciones del tipo llamadas,
representando que objeto se comunica con que otro.
Es semnticamente equivalente al Diagrama de Secuencia.
5.8. Diagrama de Secuencia

El Diagrama de Secuencia tiene como objetivo describir como colaboran los
distintos objetos entre s para conseguir un objetivo a lo largo del
tiempo. Esta directamente relacionado con el Diagrama de Comunicacin ya que
el objetivo es el mismo, pero tiene la particularidad de estar obligatoriamente
ordenado en el tiempo.
Esta compuesto por objetos y relaciones del tipo llamadas, representando que
objeto se comunica con que otro.
Es semnticamente equivalente al Diagrama de Comunicacin.
5.9. Diagrama de Componentes

Pgina 27
El Diagrama de Componentes tiene como objetivo describir la relacin que

existe entre los distintos componentes del sistema. Esta directamente
vinculado con el diseo del sistema, permitiendo modelar las relaciones e
interfaces que existen entre los componentes. Est orientado a la implementacin
del sistema.
Esta compuesto por componentes, interfaces y sus relaciones.
5.10. Diagrama de Despliegue

El Diagrama de Despliegue tiene como objetivo describir la arquitectura de un
sistema. Es posible representar la arquitectura desde el punto de vista lgico,
basndose en la organizacin del software, o desde una punto de vista fsico,
representando directamente cada unidad de hardware.
Esta compuesto por nodos, componentes y sus relaciones.

Pgina 28
6. Clasificacin de Diagramas
6.1. Categoras
Es posible clasificar a los diagramas segn si tienen alguna relacin con el tiempo
o no. Existen dos posibles categoras, los diagramas estticos y los diagramas
dinmicos.
6.2. Diagramas Estticos

Los Diagramas Estticos son aquellos que no tienen ninguna relacin con el
tiempo. Generalmente representan a estructuras o a posibles acciones pero sin
una relacin directa con el tiempo.
Estos diagramas son:
Diagrama de Clases
Diagrama de Objetos
Diagrama de Casos de Uso
Diagrama de Componentes
Diagrama de Despliegue
6.3. Diagramas Dinmicos

Los Diagramas Dinmicos son aquellos que tienen relacin con el tiempo. Estn
directamente vinculados con acciones que ocurren bajo cierta secuencia, es decir
primero una accin, luego otra, y as sucesivamente.
Diagrama de Actividades
Diagramas de Interaccin (es una subcategora, que incluye a los
Diagramas de Secuencia y Comunicacin)
Diagrama de Estado

Pgina 29
6.4. Diagramas Estructurales

Los Diagramas Estructurales son aquellos que reflejan relaciones estticas de
una estructura.
Diagrama de Clases
Diagrama de Objetos
Diagrama de Componentes
Diagrama de Despliegue
6.5. Diagramas de Comportamiento

Los Diagramas de Comportamiento son aquellos que reflejan caractersticas
de comportamiento del sistema o modelan procesos de negocios.
Diagrama de Casos de Uso
Diagrama de Comunicacin
Diagrama de Secuencia
Diagrama de Actividades
Diagrama de Estados

Pgina 30
7. Laboratorios
7.1. Consigna
Los ejercicios sern realizados en forma grupal, en grupos de 4 o 5 personas,
analizando un caso de estudio y armando una solucin utilizando el pensamiento
de objetos.
El caso de estudio y su solucin consisten en pensar e identificar cules son los
objetos que tendramos en nuestro sistema de gestin bancaria.
7.2. Caso de Estudio

BancoMax es el primer banco privado del sistema financiero argentino en ahorro
(depsitos ms fondos comunes) y en volumen de crdito. La entidad cuenta con
276 sucursales, ms de 2 millones de clientes (entre ellos ms de 100 mil PyMEs
y aproximadamente 1.100 empresas corporativas), tiene presencia en 20
provincias y en la Ciudad Autnoma de Buenos Aires. Es uno de los bancos lderes
en medios de pago, en comercio exterior, servicios transaccionales y cash
management a travs de la gestin de cuentas comerciales de caja de ahorro y
cuentas corrientes. Y tambin uno de los principales protagonistas en los
mercados burstiles, de ttulos pblicos y cambiarios.
El Banco desarrolla asimismo un amplio programa de responsabilidad social
corporativa, focalizado en la educacin superior y que incluye tambin proyectos
para generacin de empleo. Estas acciones estn en lnea con lo que BancoMax
realiza en las comunidades en donde est presente.
De acuerdo a su estructura de organizacin, BancoMax cuenta con una jerarqua
bien definida de cadena de mando, con un director general, un director por regin
y un director responsable de cada sucursal.
BancoMax integra una amplia red de servicios financieros internacionales que
brinda el Grupo BancoMaxGroup. Las capacidades internacionales han llevado a
BancoMax a ocupar tambin una posicin de liderazgo en el Reino Unido y
Latinoamrica. Es uno de los principales grupos financieros del mundo, logrando
este lugar gracias a su calidad de servicios, innovacin, dinamismo, disciplina y
visin global. Con ms de 11.000 sucursales, BancoMax es el grupo financiero
con ms sucursales en todo el mundo.

Pgina 31
7.3. Ejercicio #1 Deteccin de Clases

Identificar las clases iniciales y necesarias para construir un sistema de gestin
bancaria
TIP: las clases se detectan como sustantivos en singular

Pgina 32
7.4. Ejercicio #2 Deteccin de Atributos

A partir de las clases detectadas en el ejercicio anterior, identificar los atributos
que consideres necesarios en cada clase. Cada atributo deber tener establecido
un tipo de dato. Se requiere identificar al menos tres atributos por clase.
Los tipos de datos a utilizar para este ejercicio son: String, int, long, float,
double, Date
TIP: los atributos son caractersticas de una clase
Pregunta: en que clase ubicaras los siguientes atributos?
cantidadDeEmpleados
numeroDeCuenta
edad

Pgina 33
7.5. Ejercicio #3 Deteccin de Operaciones

A partir de las clases y los atributos detectados en los ejercicios anteriores,
identificar al menos dos operaciones que realiza cada clase.
Tip: las operaciones son verbos
Pregunta: en que clase ubicaras las siguientes operaciones ?
informarSaldo()
informarSucursales()
informarClientes()
depositarDinero(monto)
informarDatosDeCuenta(nroDeCuenta)

Pgina 34
7.6. Ejercicio #4 Relaciones Simples

A partir de las clases detectadas previamente, identifique las relaciones simples
que existen entre las mismas.
Para este ejercicio, asumiremos que cada cliente puede tener una nica cuenta.

Pgina 35
7.7. Ejercicio #5 Relaciones Mltiples

A partir de las clases detectadas previamente, identifique las relaciones mltiples
que existen entre las mismas.
Para este ejercicio, asumiremos que un cliente corporativo puede tener ms de
una cuenta corriente.

Pgina 36
7.8. Ejercicio #6 Uso de Objetos

Asumiendo que un cliente individual utiliza el cajero automtico para realizar un
depsito de $2500, ingresa su DNI nmero 27.014.589 como pin y realiza el
depsito.
El cdigo que respalda las siguientes operaciones es el siguiente:
ClienteIndividuo c = ClienteIndividuo(27014589);
CajaDeAhorro cda = c.obtenerCajaDeAhorro();
cda.depositar(2500);
Suponiendo ahora que un cliente corporativo desea realizar una extraccin de
una cuenta corriente, teniendo en cuenta los siguientes datos:
el cuit de la empresa es 30-12345678-1
desea extraer $20.000
en la cuenta hay disponible $18.000
el giro en descubierto es de $5.000
TIP: el giro en descubierto es el monto mximo que el banco le presta al cliente
en caso de que el saldo en su cuenta sea cero. Es decir que si el cliente no tiene
fondos en la cuenta, y desea realizar una extraccin o un pago, puede utilizar
automticamente hasta $5.000
Realizar
el
cdigo
en
forma
genrica
utilizando
las
clases
Programa,
ClienteCorporativo y CuentaCorriente.

Pgina 37
7.9. Ejercicio #7 Herencia

A partir de las clases detectadas previamente, identificar las relaciones de
herencia que existen.
Si consideras til y/o necesario, puedes proponer nuevas clases.

Pgina 38
8. Diapositivas

Pgina 39

Pgina 40

Pgina 41

Pgina 42

Pgina 43

Pgina 44

Pgina 45

Pgina 46

Pgina 47

Pgina 48

Pgina 49

Pgina 50

Pgina 51

Pgina 52

Pgina 53

Pgina 54

Pgina 55

Pgina 56

Pgina 57

Pgina 58

Pgina 59

Pgina 60

Pgina 61

Pgina 62

Pgina 63

Pgina 64

Pgina 65

Pgina 66

Pgina 67

Pgina 68

Pgina 69

Pgina 70

Pgina 71

Pgina 72

Pgina 73

Pgina 74

Pgina 75

Pgina 76

Pgina 77

Pgina 78

Pgina 79

Pgina 80

Pgina 81

Pgina 82

Pgina 83

Pgina 84

Pgina 85

Pgina 86

Pgina 87

Pgina 88

Pgina 89

Pgina 90

Pgina 91

Pgina 92

Pgina 93

Pgina 94

Pgina 95

Pgina 96

Pgina 97

Pgina 98

Pgina 99

Pgina 100

Pgina 101

Pgina 102

Pgina 103

Pgina 104

Pgina 105

Pgina 106

Pgina 107

Pgina 108

Manual de Programacion Orientada A Objetos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Manual de Programacion Orientada A Objetos

Uploaded by

Copyright:

Available Formats

Introduccin al Paradigma de Objetos

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

7.3. EJERCICIO #1 DETECCIN DE CLASES ...................................................................................................32

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

especializada en un tema particular, decide plantear algn nuevo concepto

1.2. El Paradigma de Objetos

debern ser pensados slo con objetos y mensajes.

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

Si queremos desarrollar un software, con la idea terica o paradigma nicamente

implementaciones. A la vez, por este mismo motivo, una implementacin es una

1.3. La Programacin Orientada a Objetos

1.4. Por que objetos

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

Escalabilidad: Capacidad de crecimiento. Que un sistema sea escalable,

donde constantemente se necesitan agregar nuevos mdulos y

cambios en su comportamiento, es necesario contar con lenguaje de

Mantenimiento: Una de las principales caractersticas del paradigma de

Seguridad: Este paradigma posee lo que se denomina como encapsulamiento

Reutilizacin: A travs de la correcta utilizacin de jerarqua de clases, y la

Simplicidad: Cuando el cdigo de un programa desarrollado con lenguaje

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

2.2. Que es un Objeto

computacional, que est dentro del software, y puede representar o no un ente

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

Va a depender del lenguaje. En principio, en un lenguaje orientado a objetos,

2.3. Que es un Mensaje

2.4. Que es el Comportamiento

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

2.5. Que es un Ambiente

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

2.6. El Software Orientado a Objetos

3. Introduccin al Paradigma de Objetos

atributos (estado) y operaciones

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

en general. Por ejemplo si tuviramos la clase Automovil, podramos crear las

Si tenemos una clase CuentaBancaria, podemos tener infinita cantidad de

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

Las clases estn compuestas por atributos y operaciones, y sern presentadas a

3.2. Los Atributos

En este caso la clase CuentaBancaria cuenta con un atributo saldo.

3.3. Los Tipos de Dato

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

De la misma manera, un objeto Persona podra tener un atributo Trabajo,

3.4. Las Operaciones

En este caso hemos agregado dos operaciones a la clase Automovil. Estas

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

Las operaciones depositar y extraer tienen un solo parmetro, este parmetro

Esto mismo se puede aplicar con la clase CuentaBancaria:

www.educacionIT.com.ar | Tel. (54) (011) 4328-0457

Introduccin al Paradigma de Objetos

La clase Automovil posee un atributo privado que representa la velocidad y