Este documento presenta un libro sobre lógica y programación orientada a objetos desde un enfoque basado en problemas. El libro introduce conceptos clave del paradigma de programación orientada a objetos a través de ejemplos y problemas resueltos. Además, incluye una herramienta llamada Sismoo que permite editar, compilar y ejecutar código escrito en un seudolenguaje similar a Java. El libro está dirigido a estudiantes y profesores interesados en aprender conceptos básicos de programación orientada a objet
2. Grupo de Investigación
en Ingeniería de Software
del Tecnológico de Antioquia
Proyecto Sismoo:
Sistema para el modelamiento por objetos
Investigadores principales:
RICARDO DE JESÚS BOTERO TABARES
CARLOS ARTURO CASTRO CASTRO
GABRIEL ENRIQUE TABORDA BLANDÓN
Coinvestigadores:
JUAN DAVID MAYA MONTOYA
MIGUEL ÁNGEL VALENCIA LÓPEZ
Ilustrador:
JAIME ROLDÁN ARIAS
ISBN: 978-958-8628-00-4
3. Contenido
PRESENTACIÓN........................................................................................................1
Capítulo 1. Una didáctica para el aprendizaje de la programación
1.1. ALGUNAS CONSIDERACIONES PEDAGÓGICAS PARA EL APRENDIZAJE
DE LA PROGRAMACIÓN ................................................................................11
1.2. FASES PARA LA SOLUCIÓN DE UN PROBLEMA ............................................14
1.3. TIPO DE PROBLEMAS A TRATAR ..................................................................21
1.4. REFERENCIAS ..............................................................................................24
Capítulo 2. Fundamentos de programación orientada a objetos
2.1. EL MUNDO DE LOS OBJETOS, EL MUNDO DE LAS COSAS ............................31
LOS CONCEPTOS DE OBJETO Y CLASE ............................................................32
PROBLEMA 1: HOLA MUNDO..........................................................................37
CREACIÓN DE OBJETOS Y PASO DE MENSAJES ...............................................42
PROBLEMA 2: OBJETOS TIPO CÍRCULO...........................................................43
2.2. TIPOS DE DATOS PRIMITIVOS Y VARIABLES ................................................47
2.3. OPERADORES Y EXPRESIONES ....................................................................51
iii
4. Contenido
2.4. CLASES DE USO COMÚN: UN MICRO MUNDO PARA EFECTOS DE
REUTILIZACIÓN ............................................................................................58
TIPOS DE DATOS ESTÁNDAR COMO OBJETOS .................................................58
LA CLASE ENTERO .............................................................................................
LA CLASE REAL ..................................................................................................
LA CLASE CARACTER .........................................................................................
LA CLASE LOGICO ..............................................................................................
PAQUETES DE USO COMÚN............................................................................65
2.5. CONFIGURACIÓN DE LAS CLASES DE USO COMÚN......................................67
LA CLASE OBJETO .........................................................................................67
LA CLASE TIPODEDATO .................................................................................68
LA CLASE FLUJO ...........................................................................................69
LA CLASE CADENA ........................................................................................70
LA CLASE MAT ..............................................................................................71
2.6. PROBLEMAS RESUELTOS CON LAS CLASES DE USO COMÚN ......................73
PROBLEMA 3: CLASES DE USO COMÚN .........................................................75
PROBLEMA 4: CONVERSIÓN DE UNA CONSTANTE A DIFERENTES
BASES NUMÉRICAS ....................................................................................79
2.7. EJERCICIOS PROPUESTOS ...........................................................................82
2.8. REFERENCIAS ..............................................................................................84
Capítulo 3. Clases: tipos de datos abstractos
3.1. ESTRUCTURA GENERAL DE UNA CLASE .......................................................91
3.2. MÉTODOS ....................................................................................................94
DEFINICIÓN DE UN MÉTODO ..........................................................................95
INVOCACIÓN DE UN MÉTODO .........................................................................97
MÉTODOS ESTÁTICOS ....................................................................................98
PROBLEMA 5: OPERACIONES CON UN NÚMERO ENTERO ...............................99
PASO DE PARÁMETROS POR VALOR VS. PASO DE PARÁMETROS POR
REFERENCIA ................................................................................................105
3.3. SOBRECARGA DE MÉTODOS .......................................................................106
PROBLEMA 6: EMPLEADO CON MAYOR SALARIO..........................................107
PROBLEMA 7: INFORME SOBRECARGADO ....................................................112
iv
5. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
3.4. ESTRUCTURAS DE CONTROL......................................................................117
LA ESTRUCTURA SECUENCIA .......................................................................118
LA ESTRUCTURA SELECCIÓN .......................................................................118
PROBLEMA 8: PRODUCTO MÁS CARO ..........................................................121
PROBLEMA 9: ESTADÍSTICAS POR PROCEDENCIA ........................................127
LA ESTRUCTURA ITERACIÓN ........................................................................133
PROBLEMA 10: PRIMEROS CIEN NATURALES...............................................139
3.5. BANDERA O INTERRUPTOR ........................................................................142
PROBLEMA 11: SUCESIÓN NUMÉRICA .........................................................142
3.6. MÉTODOS RECURSIVOS .............................................................................145
PROBLEMA 12: FACTORIAL DE UN NÚMERO ................................................146
PROBLEMA 13: CÁLCULO DE UN TÉRMINO DE FIBONACCI ...........................149
3.7. EJERCICIOS PROPUESTOS .........................................................................153
3.8. REFERENCIAS ............................................................................................156
Capítulo 4. Arreglos
4.1. OPERACIONES CON ARREGLOS .................................................................161
DECLARACIÓN DE UN ARREGLO ...................................................................162
ASIGNACIÓN DE DATOS A UN ARREGLO .......................................................164
ACCESO A LOS ELEMENTOS DE UN ARREGLO ..............................................165
PROBLEMA 14: SUCESIÓN NUMÉRICA ALMACENADA EN UN VECTOR ..........165
4.2. LA CLASE VECTOR .....................................................................................168
PROBLEMA 15: UNIÓN DE DOS VECTORES ...................................................176
PROBLEMA 16: BÚSQUEDA BINARIA RECURSIVA .........................................179
4.3. LA CLASE MATRIZ ......................................................................................182
PROBLEMA 17: PROCESO ELECTORAL .........................................................189
4.4. EJERCICIOS PROPUESTOS .........................................................................196
4.5. REFERENCIAS ............................................................................................200
Capítulo 5. Relaciones entre clases
5.1. TIPOS DE RELACIÓN ENTRE CLASES ........................................................205
ASOCIACIÓN ................................................................................................206
v
6. Contenido
DEPENDENCIA .............................................................................................209
GENERALIZACIÓN / ESPECIALIZACIÓN..........................................................209
AGREGACIÓN Y COMPOSICIÓN .....................................................................211
REALIZACIÓN ...............................................................................................212
PROBLEMA 18: SUMA DE DOS NÚMEROS ....................................................213
5.2. PAQUETES .....................................................................................................219
PROBLEMA 19: VENTA DE PRODUCTOS........................................................211
5.3. EJERCICIOS PROPUESTOS .........................................................................227
5.4. REFERENCIAS ............................................................................................229
Capítulo 6. Mecanismos de herencia
6.1. HERENCIA .................................................................................................235
HERENCIA SIMPLE .......................................................................................236
HERENCIA MÚLTIPLE: INTERFACES ..............................................................238
PROBLEMA 20: EMPLEADOS POR HORA Y A DESTAJO ..................................240
6.2. POLIMORFISMO .........................................................................................246
6.3. EJERCICIOS PROPUESTOS .........................................................................248
6.4. REFERENCIAS ............................................................................................251
Apéndices
A. ENTORNO INTEGRADO DE DESARROLLO SISMOO .....................................252
B. ELEMENTOS SINTÁCTICOS DEL SEUDO LENGUAJE ....................................260
C. GLOSARIO BÁSICO DE PROGRAMACIÓN ORIENTADA A OBJETOS ...............264
Índice analítico ...................................................................................................271
vi
7. Agradecimientos
L as sugerencias y aportes de estudiantes, egresados y profesores
de la Facultad de Informática del Tecnológico de Antioquia
fueron significativas durante la escritura de este libro. En particular,
agradecemos a los estudiantes de Tecnología en Sistemas: Carlos
Andrés García, Gloria Jazmín Hoyos, Steven Lotero, Emanuel Medina y
Luis Gabriel Vanegas; a los Tecnólogos en Sistemas: Orlando Alarcón,
Yeison Andrés Manco y Jader Rojas; a los ingenieros y profesores
Eucario Parra, Gildardo Quintero, Darío Soto y Luis Emilio Velásquez;
y al Comité para el Desarrollo de la Investigación del Tecnológico de
Antioquia –CODEI–, en especial a la ex directora de Investigación y
Posgrados, Amanda Toro, y a su actual director Jorge Ignacio Montoya.
vii
9. Presentación
L ógica y programación orientada a objetos: Un enfoque basado en problemas, es
el fundamento teórico y práctico para un primer curso de programación. Además
de incursionar de manera directa en el aprendizaje de un lenguaje que soporta el
paradigma orientado a objetos1, incluye ejercicios de aplicación de los conceptos
propios del paradigma, a saber: clase, objeto, encapsulación, paquete y herencia, que
conllevan a otros como atributo, método, visibilidad, constructor, estado de un objeto,
recolector de basura, ligadura estática y ligadura dinámica. De esta manera, el libro
responde a propósitos de renovación pedagógica orientados al diseño de currículos
“con base en la investigación, que promueven la calidad de los procesos educativos y
la permanencia de los estudiantes en el sistema”, uno de los desafíos de la educación
en Colombia propuesto en el Plan Nacional Decenal de Educación vigente [PNDE2006].
También responde a la estructura curricular del módulo Desarrollar Pensamiento
Analítico Sistémico I del proyecto Alianza Futuro Digital Medellín, del plan de estudios
72 del programa Tecnología en Sistemas del Tecnológico de Antioquia - Institución
Universitaria.
1 El paradigma orientado a objetos es un modelo o patrón para la construcción de software, entre
otros existentes como los paradigmas imperativo, funcional y lógico.
1
10. Contenido
Conviene señalar que este libro es el resultado del proyecto Sismoo – Sistema para
el modelamiento por objetos –, adelantado en la línea de investigación “Ingeniería
de software y sistemas de información”, inscrita en el grupo GIISTA – Grupo de
Investigación en Ingeniería de Software del Tecnológico de Antioquia–, clasificado a
2009 en la categoría C de Colciencias. El proyecto Sismoo fue también una consecuencia
de otro proyecto de la línea: MIPSOO – Método Integrado de Programación Secuencial y
programación Orientada a Objetos para el análisis, diseño y elaboración de algoritmos–,
que incluye un seudo lenguaje y una didáctica para el aprendizaje de la programación.
Ahora bien, el proyecto Sismoo aporta un intérprete del seudo lenguaje propuesto por
el MIPSOO, sencillo y fácil de utilizar, que busca agilizar los procesos de enseñanza y
aprendizaje de la programación de computadoras, e incluye un traductor al lenguaje de
programación Java. Se proyecta seguir mejorando este objeto de aprendizaje.
El método para el aprendizaje y la enseñanza de la programación orientada a
objetos del proyecto MIPSOO incluye elementos didácticos del aprendizaje basado
en problemas y principios pedagógicos constructivistas. Su didáctica propone el
seguimiento de cuatro fases para la solución de problemas:
Definición de la tabla de requerimientos.
Diseño del diagrama de clases.
Definición de las responsabilidades de las clases.
Desarrollo del seudo código (tiene una gran similitud con los lenguajes de
programación Java, C# y Visual Basic.Net)
Como complemento de MIPSOO, Sismoo es un proyecto de investigación aplicada
cuyo producto de desarrollo es una herramienta de software diseñada para que el
usuario pueda editar, compilar y ejecutar los problemas diseñados empleando el seudo
lenguaje propuesto por MIPSOO. Esta herramienta, denominada en el medio informático
Entorno Integrado de Desarrollo o IDE (Integrated Development Environment), fue
desarrollada en lenguaje Java y su diagrama estructural se asemeja al de cualquier
compilador (ver Figura 1):
2
11. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
Figura 1. IDE traductor SISMOO
Conocidos los objetivos y antecedentes de este libro, examinemos brevemente las
características de sus lectores y capitulación.
Como todo texto académico, este libro presupone dos lectores principales:
estudiantes y profesores, en particular, de tecnología e ingeniería de sistemas y áreas
afines; también admite otros lectores con conocimientos básicos en programación
estructurada o imperativa.
Los profesores encontrarán en el capítulo 1 (Una didáctica para el aprendizaje de la
programación) y en el apéndice B (Elementos sintácticos del seudo lenguaje), claves
para el diseño de problemas propios de la programación; sin embargo se recomienda
a los estudiantes la lectura de los apartados 1.2 y 1.3., donde pueden enterarse de las
fases para la solución de los problemas y los tipos de problemas, que encontrará en este
libro. Los capítulos restantes desarrollan teóricamente el paradigma orientado a objetos2
y presentan la didáctica para el aprendizaje de los fundamentos de programación.
Continuando con la descripción de los capítulos, en el número 2, (Fundamentos de
Programación Orientada a Objetos), se exponen los fundamentos de la programación
orientada a objetos, por ello su lectura es primordial para el estudiante, quien adquiere
las bases para abordar la lectura de los próximos capítulos. El capítulo 3, (Clases: tipos
de datos abstractos), profundiza lo concerniente al manejo de métodos e introduce el
empleo de las sentencias de control y los interruptores; aquí el estudio de la recursión
es importante, en tanto puede retomarse para un curso de estructuras de datos. El
capítulo 4, (Arreglos), es una incursión a las clases contenedoras lineales Vector y Matriz
(clases que almacenan conjuntos de objetos); es también un abrebocas a un módulo
2 Varios profesores nos referimos a él como “paradigma objetual”
3
12. Contenido
o curso relacionado con estructuras de datos donde se puede profundizar mucho más.
En los capítulos 5 (Relaciones entre clases) y 6 (Mecanismos de herencia) se tratan
las relaciones fundamentales entre clases, como las asociaciones y dependencias, y
los paquetes.
Una vez revisado el contenido del libro, quien tenga conocimientos del paradigma
objetual, sea estudiante o profesor, y desee interactuar de entrada con un micro mundo
de clases reutilizables (una visión bastante reducida de algo como la API de Java o
los espacios de nombres de .Net Framework), puede comenzar con la lectura de los
capítulos 2 y 3, y pasar a los capítulos finales, 5 y 6.
Se recomienda a un lector casual empezar a estudiar las historias que preceden
cada capítulo, cuentos ilustrados y representados con un diagrama de clases, en
consonancia con un artículo publicado por Zapata [Zapata1998].
Desde ahora es conveniente la lectura de los apéndices A (Entorno Integrado de
Desarrollo Sismoo), donde se exponen los elementos necesarios para interactuar
con el entorno integrado de desarrollo Sismoo; B (Elementos sintácticos del seudo
lenguaje) que presenta un listado de palabras reservadas para el seudo lenguaje
objetual, un resumen de las estructuras de control y los elementos estructurales que
permiten definir una clase, un método, un paquete y una interfaz; y C (Glosario básico
de programación orientada a objetos), que presenta un listado de términos con su
significado para consulta rápida en el proceso de aprendizaje de la programación.
A la vez, durante la lectura de este libro, puede ser consultado su índice analítico,
el cual contiene términos de relevancia que a nivel conceptual, deben ser claros para
plantear soluciones concretas a los problemas sugeridos; en el libro, estos conceptos
se escribieron en cursiva para facilitar su identificación en las páginas que señala el
índice. El CD anexo incluye el intérprete Sismoo, además el JDK6.7 con uno de sus
entornos (NetBeans 6.1) y el Microsoft .Net FrameWork 2.0 para el trabajo con el entorno
SharpDevelop 2.2.1.
En la siguiente página el lector encontrará una frase célebre como pretexto a la
familiarización con los diagramas de clase. Esperamos que este libro sea un disfrute
para los estudiantes de programación y para sus profesores.
Los autores
4
13. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
Quererse a sí mismo es el principio de un romance para toda la vida
Oscar Wilde
Diagrama de clases propuesto:
Un diagrama de objetos:
5
15. CAPÍTULO1
Una didáctica para el aprendizaje
de la programación
1.1. Algunas consideraciones pedagógicas para el aprendizaje de la
programación
1.2. Fases para la solución de un problema
1.3. Tipo de problemas a tratar
1.4. Referencias
17. TARARÍ Y TARARÁ
De: Alicia a través del espejo
Lewis Carroll
— Ahora está soñando -señaló Tarará- ¿y a que no sabes lo que está soñando?
— ¡Vaya uno a saber -replicó Alicia- ¡Eso no podría adivinarlo nadie!
— ¡Anda! ¡Pues si te está soñando a ti! -exclamó Tarará batiendo palmas en aplauso de su
triunfo-. Y si dejara de soñar contigo, ¿qué crees que te pasaría?
— Pues que seguiría aquí tan tranquila, por supuesto -respondió Alicia.
— ¡Ya! ¡Eso es lo que tú quisieras! -replicó Tarará con gran suficiencia-. ¡No estarías en
ninguna parte! ¡Como que tú no eres más que un algo con lo que está soñando!
— Si este Rey aquí se nos despertara -añadió Tararí- tú te apagarías… ¡zas! ¡Como una vela!
9
18. Una didáctica para el aprendizaje de la programación
Diagrama de clases:
Diagrama de objetos:
10
19. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
O bjetivo de aprendizaje
Definir una didáctica para la enseñanza y aprendizaje de la programación
orientada a objetos.
Para alcanzar este objetivo, consideramos que la didáctica de un profesor para
enseñar la programación de computadores debe sustentarse en metodologías
inspiradas en la ingeniería de sistemas, las tecnologías dominantes de la informática,
la aproximación a problemas reales, el rigor abstracto y lógico y la puesta en común
entre las necesidades expresadas por el sector informático donde se van a desenvolver
sus estudiantes como profesionales.
Es por lo anterior que este capítulo tiene por objetivo establecer algunos lineamientos
didácticos para el aprendizaje de la programación, a la vez que define el tipo de
problemas a tratar y las etapas para su solución.
1.1. ALGUNAS CONSIDERACIONES PEDAGÓGICAS PARA EL
APRENDIZAJE DE LA PROGRAMACIÓN
Aprender a programar computadores desde un enfoque basado en la solución de
problemas, involucra estrategias de enseñanza-aprendizaje constructivistas. Los
aprendizajes por descubrimiento, colaborativo, significativo y basado en problemas o
situado, son aplicados por los estudiantes de programación en mayor o menor grado
durante los diferentes estadios del proceso cognitivo. El profesor debe ser consciente de
la pedagogía latente en el proceso de formación para propiciar ambientes donde estos
aprendizajes se relacionen, porque de alguna manera todos ellos se complementan.
En el aprendizaje por descubrimiento [Bruner1966] la nueva información o
conocimiento se adquiere a través de los propios esfuerzos del estudiante (tiempo de
trabajo independiente), con los aportes del aprendizaje por exposición o instrucción
11
20. Una didáctica para el aprendizaje de la programación
impartido por el docente (horas de trabajo presencial). Los contenidos desarrollados deben
ser percibidos por el aprehendiente como un conjunto de problemas a tratar y relaciones
conceptuales a establecer. En el aprendizaje colaborativo [Zañartu2005], el estudiante
puede también ayudarse de los conocimientos de sus compañeros o de comunidades
externas, por medio de encuentros presenciales extra clase o con actividades propiciadas
por las tecnologías de la información y comunicación. En el aprendizaje significativo
[Ausubel1983], el aprendizaje del alumno depende de la estructura cognitiva previa que
se relaciona con la nueva información, de tal manera que el nuevo conocimiento adquiere
significado y puede enlazarse en nuevos procesos cognitivos.
En el aprendizaje basado en problemas [González2006] confluyen algunas
características de los aprendizajes anteriores: el estudiante descubre por sí mismo,
interactúa con los demás, adquiere conocimientos con significado en la medida que
estos se relacionan con los ya establecidos y sientan la base para otros venideros. En el
aprendizaje basado en problemas un grupo de alumnos se reúne, con la facilitación de
un tutor, para analizar y resolver un problema seleccionado o diseñado especialmente
para el logro de ciertos objetivos de aprendizaje.
Las estrategias de aprendizaje expuestas se posibilitan y consolidan en el aula3 con
las siguientes actividades:
Exposiciones del profesor para explicar los aspectos teóricos más relevantes, a la
vez que soluciona problemas concretos en clase.
Solución de talleres por el estudiante, quien se hace cargo de su propio proceso de
aprendizaje al retroalimentar los conceptos vistos en clase y solucionar dudas con
la colaboración de otros aprendices y el apoyo del tutor. En este punto adquieren
especial interés las actividades desarrolladas por el aprendiz en su tiempo de
trabajo independiente, en concreto las relacionadas con la trascripción y prueba
del seudo código con IDE Sismoo, la codificación de las soluciones en lenguajes
comerciales orientados a objetos, la relación con otras instituciones o Grupos de
Investigación interesados en el desarrollo de software y la propuesta de nuevos
problemas que conlleven a la creación de objetos de aprendizaje innovadores.
3 Se entiende por aula cualquier entorno propicio para el aprendizaje como un salón de clase, una
biblioteca, un espacio natural, un teatro, un ambiente virtual, entre otros.
12
21. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
Desarrollo de un proyecto integrador por parte del estudiante para aplicar todos o un
gran porcentaje de los conceptos aprendidos.
De esta forma, los siguientes criterios pueden servir de base para la incursión
didáctica apropiada en los cursos de fundamentos de programación:
La clase es constructiva y tiene el liderazgo del docente para incentivar el aprendizaje
del estudiante.
Desde las primeras incursiones en la clase, las herramientas de programación
apoyan el desarrollo de la lógica, respetando los momentos necesarios para la
consolidación conceptual y las prácticas en el computador por parte del estudiante.
La autoevaluación del estudiante y su descubrimiento autónomo, son factores
importantes en el proceso de aprendizaje. En este sentido, el mayor nivel se
alcanza cuando el mismo estudiante descubre los puntos críticos de sus algoritmos
y programas.
El desarrollo a partir de problemas y casos hacen de la clase un espacio para
aprendizajes contextualizados y significativos, en la medida que se proporcione
a los estudiantes información acerca de dominios económicos, administrativos,
financieros y logísticos, relacionados con la cotidianidad de los entornos productivos
de las empresas.
El paradigma de programación orientado a objetos debe concebirse como un
proceso. Esto lleva a considerar que la abstracción de objetos y comportamientos
debe hacer parte de la modelación desde los inicios del proceso de aprendizaje,
esto es, debe incluirse en los cursos de lógica de programación y estructuras de
datos. Así se garantiza su debido tratamiento en otras asignaturas relacionadas con
lenguajes de programación, bases de datos e ingeniería de software.
La actitud recursiva del estudiante es otro factor de éxito en la formulación de su
proyecto, así como en la interacción con las plataformas de desarrollo de software
durante la ejecución del mismo.
Una idea transversal debe marcar el norte de los cursos de programación:
estructurar los contenidos por problemas, en módulos que se comunican y que
permiten concebir sus soluciones como la integración de partes. Esto debe aportarle
a los estudiantes las bases para resolver problemas cuando estén por fuera de la
clase.
13
22. Una didáctica para el aprendizaje de la programación
Otro de los principios didácticos que todo docente, no sólo de programación, debe
tener en cuenta a la hora de diseñar sus clases, es que el aprendizaje de los contenidos
de una asignatura implica a sus estudiantes conflictos cognitivos que varían según
sus habilidades. Por esta razón, los docentes deben motivar a sus estudiantes
con actividades que impliquen un aprendizaje que trascienda lo individual como
el aprendizaje colaborativo; y que se dirija hacia el apoyo e interrelación con sus
compañeros: el aprendizaje basado en la solución de problemas.
Resumiendo, un enfoque constructivista como el que aquí se propone, se apoya
de variadas estrategias de enseñanza-aprendizaje: retoma del aprendizaje por
descubrimiento, los esfuerzos que debe hacer el estudiante para reconocer una nueva
información; y del aprendizajecolaborativo, el que un estudiante es capaz de cuestionar
y compartir sus conocimientos con los colegas de su grupo o con comunidades externas
contactadas a través de la Web. A su vez, del aprendizaje significativo valora la estructura
cognitiva previa del estudiante para vincular lo ya conocido con la nueva información; y
por último, reconoce del aprendizaje basado en problemas (que conlleva características
de los aprendizajes ya citados), lo siguiente: la adquisición de conocimientos como el
desarrollo de habilidades y actitudes hacen parte del entorno de la clase; un espacio
donde un grupo pequeño de alumnos se reúne con la facilitación de un tutor a analizar
y resolver un problema seleccionado o diseñado especialmente para el logro de ciertos
objetivos de aprendizaje propuestos en el curso.
En la próxima sección se explican con detalle las fases necesarias para la solución
de un problema en el curso de programación orientada a objetos que en este libro se
presenta.
1.2. FASES PARA LA SOLUCIÓN DE UN PROBLEMA
La solución de un problema conlleva una didáctica de cuatro fases:
a) Construcción de la tabla de requerimientos.
b) Abstracción de clases (diagramas conceptuales – si se requiere- y de clases
14
23. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
según formalismo de UML4).
c) Descripción de las responsabilidades de las clases, formalizadas con los
contratos de cada método.
d) Escritura de seudo código orientado a objetos.
Veamos cada fase con más detalle, aplicadas al siguiente problema: Visualizar la
suma de dos números enteros ingresados por el usuario.
a) Construcción de la tabla de requerimientos
La construcción de la tabla de requerimientos [Villalobos2006] forma parte del
análisis del problema. Los requerimientos hacen referencia a las necesidades de los
usuarios, es decir, identifican los aspectos que los usuarios del programa desean
resolver mediante software. Estos requerimientos se denominan funcionales al
sostener una relación directa con la funcionalidad del sistema.
La tabla de requerimientos está compuesta por cuatro columnas:
Identificación del requerimiento: es un código que identifica al requerimiento,
generalmente compuesto por una letra y un dígito. Identificadores comunes para los
requerimientos son R1, R2, R3, etc.
Descripción: consiste en una descripción concisa y clara, en lenguaje natural, del
requerimiento.
Entradas: son los insumos o datos necesarios para que el requerimiento se pueda
suplir con éxito.
Resultados o salidas: constituyen el cumplimiento del requerimiento, es decir, son
los resultados que dan solución a un requerimiento funcional definido por el usuario.
Apliquemos en el Ejemplo 1.1., la tabla de requerimientos para la suma de dos
números enteros.
4 UML (Unified Modeling Language) es un lenguaje para construir planos de software.
15
24. Una didáctica para el aprendizaje de la programación
Ejemplo 1.1. Tabla de requerimientos
Identificación del Resultados
Descripción Entradas
requerimiento (Salidas)
R1 Capturar dos Dos números enteros Dos números enteros
números enteros ingresados por el almacenados en
usuario memoria (variables
n1 y n2)
R2 Operar dos Las variables n1 La suma de los
números enteros y n2 números n1 y n2
Observaciones a tener en cuenta para el diseño de tablas de requerimientos:
Es común que la salida de un requerimiento se convierta en la entrada de otro; por
ejemplo, la salida del requerimiento R1 (las variables n1 y n2) es la entrada del
requerimiento R2.
Los requerimientos funcionales son casos de uso que describen de una manera
detallada el comportamiento del sistema con los distintos actores que interactúan
en él. Un caso de uso es la descripción de una secuencia de acciones que un
sistema ejecuta y que produce un resultado observable de interés para un actor
particular [Booch1999]. Un actor es un usuario del sistema.
b) Abstracción de clases
La abstracción de clases también forma parte del análisis del problema y es el
primer momento para diseñar la solución. Consiste en una representación gráfica del
problema, plano de software, donde se dibujan abstracciones de la realidad relacionadas
con el mundo del problema, modelables con software. El plano construido se puede
presentar en dos fases, que comprenden un diagrama conceptual y un diagrama de
clases. Es de aclarar que el primero de ellos es opcional en tanto no se requiere cuando
los problemas a tratar son pequeños o con cierto margen de trivialidad: mostrar un
mensaje, comparar dos cadenas, hallar una sumatoria, entre otros.
16
25. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
Ejemplo 1.2: Diagrama de clases para la suma de dos números.
En este diagrama la solución se presenta en dos clases: SumaDosNumeros que
contiene un método denominado principal( ), y Flujo, clase de uso común que se
estudiará en el apartado 2.5 (Configuración de las clases de uso común).
El rectángulo que representa la clase se divide en tres partes: en la primera se
coloca su nombre: SumaDosNumeros; en la segunda se ubican los atributos de la
clase (no existen para este caso), y en la tercera las operaciones o métodos: el único
método presentado en el ejemplo 1.2 es principal( ). Si el lector requiere una mayor
información sobre la estructura de una clase, puede encontrarla en la sesión 2.1 (El
mundo de los objetos, el mundo de las cosas).
c) Análisis de responsabilidades de las clases
El análisis de responsabilidades de las clases conlleva la descripción de los
métodos de cada clase mediante contratos que incluyen los requerimientos asociados,
la precondición o estado del objeto antes de ejecutar el método, la postcondición
que aclara el estado del objeto luego de ejecutar el método, y el modelo verbal que
consiste en una descripción en lenguaje natural de la solución planteada, algo similar
al denominado algoritmo cualitativo.
La identificación de responsabilidades forma parte de la documentación de la
solución o del futuro sistema basado en software.
17
26. Una didáctica para el aprendizaje de la programación
Ejemplo 1.3. Contrato de la clase SumaDosNumeros
Requeri-
Nombre del
mientos Precondición Postcondición Modelo verbal
método
asociados
principal ( ) R1 Se Se ha 1. Declarar variables
R2 desconocen calculado y 2. Capturar los dos
los números a visualizado números enteros
sumar la suma de 3. Sumar los números
dos números 4. Visualizar el resultado
enteros de la suma
d) Escritura del seudo código orientado a objetos
El seudo código orientado a objetos (OO) especifica la solución del problema,
porque da cuenta del cómo obtener una solución. Se escribe de una manera similar al
proceso de codificación en un lenguaje de programación como Java o C#.
Esta fase conlleva la aplicación de pruebas manuales para cada uno de los métodos
(correspondientes a las denominadas “pruebas de escritorio”), o de manera automática
con el traductor Sismoo.
Ejemplo 1.4. Seudo código OO para la suma de dos números
1. clase SumaDosNumeros
2. publico estatico vacio principal ( )
3. entero a, b, c
4. Flujo.imprimir (“Ingrese el primer número entero:”)
5. a = Flujo.leerEntero ( )
6. Flujo.imprimir (“Ingrese el segundo número entero:”)
7. b = Flujo.leerEntero ( )
8. c=a+b
9. Flujo.imprimir (a + “ + ” + b + “ = ” + c)
10. fin_metodo
11. fin_clase
18
27. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
Observaciones:
Para facilitar las explicaciones, en este ejemplo se han numerado las diferentes
instrucciones del algoritmo objetual.
Las palabras clave (o reservadas) del seudocódigo orientado a objetos se escribirán
en este libro siempre sin acentos y en negrita, con el objetivo diferenciarlas de los
identificadores usados por el analista para designar clases, variables, constantes,
atributos, métodos y objetos. Las palabras reservadas del ejemplo son clase,
publico, estatico, vacio, principal, entero, Flujo, fin_metodo y fin_clase. Para
una mayor información acerca de las palabras reservadas del seudo lenguaje
orientado a objetos utilizado en este libro, se recomienda revisar el apéndice B.
Las variables a, b y c son declaradas enteras, como se indica en la instrucción
3. Una buena práctica de programación es inicializar las variables cuando se
declaran, para evitar algunos errores en tiempo de ejecución. En lenguajes como
Java, C# y Visual Basic.Net se pueden presentar este tipo de situaciones con
algunas instrucciones; sin embargo, para evitar contratiempos en la ejecución, toda
declaración de variables en estos lenguajes implica su inicialización con valores
preestablecidos. Por ejemplo, las variables de tipo numérico son puestas a cero,
las cadenas en la cadena vacía y los objetos son inicializados en la constante nula.
En la siguiente tabla se observan los valores con los cuales se deben comenzar los
distintos tipos de variables.
Tabla 1.1. Valores de inicialización por omisión para los tipos estándar de datos
Valor con el que se debe Valor de inicialización por
Tipo
inicializar omisión (con descripción)
Cualquier número (depende
Numérica (entero, real) 0 (cero)
del problema)
carácter Cualquier carácter ‘ ’ (espacio)
cadena Cualquier cadena “ ” (cadena vacía)
lógico falso o cierto cierto (verdadero)
Objeto nulo nulo
19
28. Una didáctica para el aprendizaje de la programación
Observaciones:
Para la entrada de datos enteros se utiliza la clase Flujo y el método estático
leerEntero( ), como en la instrucciones 5 y 7 del seudo código OO para la suma de
dos números enteros:
a = Flujo.leerEntero ( )
b = Flujo.leerEntero ( )
La clase Flujo se encuentra definida en el paquete o espacio de nombres importado
por defecto, denominado sistema. Una vista parcial de este paquete se ilustra en la
figura 1.2.
Figura 1.2. Diagrama de clases UML
Para imprimir constantes y variables en el dispositivo de salida estándar (el monitor
o pantalla), se ha utilizado el método Flujo.imprimir( ), como en las instrucciones
4, 6 y 9.
Las instrucciones 4 y 6, dadas por Flujo.imprimir (“Ingrese el primer número
entero:”) y Flujo.imprimir (“Ingrese el segundo número entero:”), imprimen cada
una su respectiva constante de cadena.
La instrucción 9 tiene un matiz especial:
Flujo.imprimir (a + “ + ” + b + “ = ” + c) imprime una combinación de
20
29. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
variables y de constantes tipo carácter. Por ejemplo, si las variables a y b contienen
los valores 7 y 10 respectivamente, la instrucción visualizará la expresión:
7 + 10 = 17
En la instrucción 9 puede notarse la diferencia entre el símbolo cruz (+) no
encerrado entre comillas y el símbolo cruz que sí las tiene: en el primer caso se trata
del operador de concatenación, mientras que en el segundo se trata de la constante
“+” que se visualiza tal cual aparece en la expresión. De igual manera, en la
instrucción 8 (c = a + b) el símbolo cruz denota al operador aritmético de adición.
Se dice entonces que el operador cruz (+) se encuentra sobrecargado, porque
dependiendo del lugar donde se utilice denota suma de números o concatenación
de valores.
Se puede omitir el uso de la variable c haciendo visible el resultado de evaluar una
expresión aritmética de la siguiente manera:
Flujo.imprimir (a + “ + ” + b + “ = ” + (a + b))
Otras alternativas de solución para la suma de dos números, se presentan en el
problema 18 del apartado 5.1 (Tipos de relación entre clases).
1.3. TIPO DE PROBLEMAS A TRATAR
En la enseñanza y el aprendizaje de la programación es necesario plantear
problemas reales o ficticios, claros en su descripción y susceptibles de solucionar con
un programa de computadora.5
5 Es de aclarar que los problemas no determinísticos, denominados también NP completos, imposi-
bles hasta el momento de solucionar con un programa de computadora, no serán tratados en este
libro.
21
30. Una didáctica para el aprendizaje de la programación
A continuación, se presentan los cuatro tipos de problemas, ordenados según su
volumen y complejidad, y en los que será posible la aplicación de clases de uso común.
a) Problemas donde se reutilizan las clases de uso común
Aunque los cuatro tipos de problemas elegidos reutilizan las clases de uso común,
en esta primera categoría se hace énfasis en ellos. Se caracterizan porque presentan
soluciones donde es necesario utilizar componentes con una funcionalidad
preestablecida, probada y verificada, esto es, donde el funcionamiento interior de
los métodos pasa a un segundo plano. De esta manera, lo que interesa es reutilizar
la interfaz pública de un pequeño conjunto de clases requeridas en todas o en
una gran parte de las aplicaciones, lo cual permite simular las acciones realmente
ejecutadas por los programadores cuando trabajan con plataformas de desarrollo
comerciales como J2SE o.NET. Por simple que sea el problema a resolver, los
programadores siempre reutilizan algún componente de software predefinido.
Las clases de uso común que se emplean para las explicaciones de este texto
se encuentran almacenadas en el paquete sistema; algunas de ellas son Flujo
(controla la entrada y salida de datos estándar), Cadena (maneja textos o cadenas
de caracteres), Entero (maneja cantidades enteras), Mat (contiene funciones
matemáticas), entre otras. Para mayor información remitirse a la sesión 2.4. Clases
de uso común: un micro mundo para efectos de reutilización.
b) Problemas con una clase del ámbito de la solución (Proyecto) y métodos
analizadores estáticos (opcionales)
En este tipo de problemas se usan clases vacías, es decir, clases que carecen de
atributos, contienen uno o varios métodos analizadores (uno de ellos de carácter
obligatorio denominado principal), donde la solución se plantea sin la creación de
objetos.
En realidad nunca se tendrán clases sin atributos. Lo que se persigue con este tipo
de problemas es aprender a manejar las sentencias de control y los subprogramas
(denominados en adelante métodos), conceptos propios de la programación
22
31. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
imperativa. De esta manera el método de aprendizaje aplicado es mixto, es decir,
se fundamenta en la programación orientada a objetos y maneja conceptos de la
programación procedimental como una fase complementaria a la modelación por
objetos.
Los métodos analizadores utilizados son de naturaleza estática, y conducen a la
solución del problema con la estrategia de diseño “Divide y vencerás”: división de
un problema en otros más pequeños y sencillos de solucionar.
El uso de la clase Flujo es inamovible, porque en la mayoría de las situaciones
problemáticas se emitirán mensajes al usuario a través del método imprimir( ) o
se ingresarán datos por medio de los métodos leerEntero( ) y similares.
c) Problemas con varias clases asociadas entre sí
En este tipo de problemas es posible trabajar con propiedad la teoría de la orientación
a objetos, en tanto se aplican los conceptos de encapsulación de datos, métodos
constructores, métodos modificadores, métodos analizadores, creación de objetos y
paso de mensajes.
Aquí cobra relevancia el concepto de asociación entre dos clases, las cuales se
producen a partir del ámbito del problema, es decir, relacionadas directamente
con las percepciones del usuario. Abstracciones como Empleado, Producto, Viaje
y TransacciónBancaria, se consolidan en objetos dentro de la clase del ámbito de
la solución por excelencia, denominada en general Proyecto (puede adquirir otra
nominación según la preferencia del analista). Por último, es necesario resaltar que
en este tipo de problemas las clases asociadas con una funcionalidad común se
pueden agrupar en un paquete.
d) Problemas cuya solución involucra mecanismos de herencia
En estos problemas se tratan los conceptos de clase abstracta, clase base (o
superclase), clase derivada (o subclase), clase final, interfaces (para la herencia
múltiple) y polimorfismo.
23
32. Una didáctica para el aprendizaje de la programación
Observación:
Para finalizar la clasificación de los problemas a tratar en este libro, es necesario
reconocer que en ellos siempre estará presente la clase Proyecto, nombre que se
puede reemplazar, como ya se había dicho, por otro como Prueba, Solución, o algún
identificador nemotécnico para el caso que se trata: Universidad, Almacén, Producto,
etc. Esta clase puede carecer de atributos (algo absurdo en la realidad, pero que en
términos de software se puede manejar), pero siempre tendrá un método imprescindible
denominado principal ( ), punto de entrada y salida de la solución planteada. Además,
vale reiterar que en los cuatro tipos de problemas se podrán reutilizar las clases de uso
común, haciendo los diagramas de clase más expandidos, es decir, que incluyan dos o
más clases.
1.4. REFERENCIAS
[Ausubel1983]: Ausubel-Novak-Hanesian. Psicología Educativa: Un punto de vista
cognoscitivo. 2° Ed. TRILLAS, México, 1983.
[Booch1999]: Booch-Rumbaugh-Jacobson. El Lenguaje Unificado de Modelado. Addison
Wesley Iberoamericana, Madrid, 1999.
[Bruner1966]: Bruner, Jerome. Toward a Theory of Instruction. Cambridge, MA: Harvard
University Press, 1966
[Carrol1983]: Carroll, Lewis. Alicia a través del espejo. El libro de Bolsillo, Alianza Editorial,
Madrid, 1983.
[González2006]: González Ocampo, Juan Antonio. El aprendizaje basado en problemas
como forma de innovación pedagógica. U. de Manizales, Facultad de Ingeniería, Grupo de
investigación en innovación curricular. Disponible en:
http://www.umanizales.edu.co/programs/ingenieria/abpinnovacionpedagogica.pdf. 2006
[PNDE2006]: Plan Nacional Decenal de Educación 2006-2016. (Colombia). Disponible en:
http://www.plandecenal.edu.co
24
33. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
[Villalobos2006]: Villalobos J., Casallas R. Fundamentos de programación. Aprendizaje activo
basado en casos. Pearson - Prentice Hall. México, 2006
[Zañartu2000]: Zañartu, Luz María. Aprendizaje colaborativo: Una nueva forma de diálogo
interpersonal y en red. 2000 Disponible en: http://contextoeducativo.com.ar/2003/4/nota-02.htm.
[Zapata1998]: Zapata, Juan Diego. “El Cuento” y su papel en la enseñanza de la orientación
por objetos. IV Congresso RIBIE, Brasilia 1998. Disponible en: http://www.c5.cl/ieinvestiga/
actas/ribie98/146.html.
25
35. CAPÍTULO 2
Fundamentos de programación
orientada a objetos
2.1. El mundo de los objetos, el mundo de las cosas
2.1.1. Los conceptos de objeto y clase
Problema 1. Hola mundo
2.1.2. Creación de objetos y paso de mensajes
Problema 2. Objetos tipo Círculo
2.2. Tipos de datos primitivos y variables
2.3. Operadores y expresiones
2.4. Clases de uso común: un micro mundo para efectos de reutilización
2.4.1. Tipos de datos estándar como objetos
2.4.2. Paquetes de uso común
2.5. Configuración de las clases de uso común
La clase Objeto
La clase TipoDeDato
La clase Flujo
La clase Cadena
La clase Mat
2.6. Problemas resueltos con las clases de uso común
Problema 3. Clases de uso común
Problema 4. Conversión de una constante a diferentes bases numéricas
2.7. Ejercicios propuestos
2.8. Referencias
37. LA SOSPECHA
Lie Zi
Un hombre perdió su hacha; y sospechó del hijo de su vecino. Observó la manera de caminar del
muchacho – exactamente como un ladrón. Observó la expresión del joven – idéntica a la de un
ladrón. Observó su forma de hablar – igual a la de un ladrón. En fin, todos sus gestos y acciones lo
denunciaban culpable de hurto.
Pero más tarde, encontró su hacha en un valle. Y después, cuando volvió a ver al hijo de su vecino,
todos los gestos y acciones del muchacho le parecían muy diferentes a los de un ladrón.
29
39. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
O bjetivos de aprendizaje
Comprender el concepto de objeto como elemento esencial para la solución de
problemas.
Ilustrar el uso de clases incluidas en paquetes de uso común o reutilización de un
componente predefinido.
Reconocer el concepto de método como estrategia para la solución de un problema,
con la técnica de diseño “Divide y vencerás”.
Efectuar procesos de entrada y salida de datos.
2.1. EL MUNDO DE LOS OBJETOS, EL MUNDO DE LAS COSAS
Según el diccionario de la Real Academia de la Lengua Española, la primera acepción
de la palabra Cosa es “Todo lo que tiene entidad, ya sea corporal o espiritual, natural
o artificial, real o abstracta” [RAE2001]. En el mismo diccionario, el vocablo Objeto se
define como “Todo lo que puede ser materia de conocimiento o sensibilidad de parte del
sujeto, incluso este mismo”. Es claro que el mundo en que vivimos está lleno de cosas
y objetos.
En el lenguaje de la programación, los gestores del Unified Modeling Language
-UML indican que “los términos ‘instancia’ y ‘objeto’ son en gran parte sinónimos y, por
ello, la mayoría de las veces pueden intercambiarse”. En términos del paradigma de
programación orientado a objetos, un objeto es un elemento o instancia de una clase, la
cual es definida por Booch (1999) como “una descripción de un conjunto de objetos que
comparten los mismos atributos, operaciones, relaciones y semántica”. [Booch 1999].
Para aclarar los conceptos de objeto y clase, a continuación se presentarán sus
características y comportamientos.
31
40. Fundamentos de Programación Orientada a Objetos
LOS CONCEPTOS DE OBJETO Y CLASE
Un objeto es un elemento de una clase. Así, un reloj de pulso, el reloj de pared de
una morada específica, el reloj Big Ben de Londres, el reloj interno de un computador,
todos, pertenecen a una clase llamada Reloj. Asimismo, los caballos Bucéfalo de
Alejandro Magno, Strategos de Aníbal, Genitor de Julio César, Rocinante de Don Quijote,
Palomo de Bolívar y el corcel que más se recuerda en la vida, son todos objetos de la
clase Caballo. La consignación bancaria que realizó Juan Valdés hace dos semanas en
el banco principal de su pueblo natal y el retiro por cajero electrónico que su tío acaba
de realizar, son ambos objetos pertenecientes a la clase TransaccionBancaria.
Un objeto tiene las mismas características (atributos, variables) y comportamientos
(métodos, operaciones, algoritmos) de todos los elementos de la clase a la cual
pertenece. Así, todos los relojes tienen características de forma, marca, precio y tipo,
y comportamientos similares como sonar, mostrar hora, despertar y parar. Todos los
caballos tienen características de raza, color, peso, edad y alzada, y comportamientos
parecidos como correr, relinchar, pastar y dormir. Toda transacción bancaria tiene
características de tipo (retiro, consulta, consignación), valor, cuenta asociada, fecha y
hora, así como las operaciones de iniciar, finalizar y cancelar.
Los objetos se crean (nacen), interactúan entre sí (se envían mensajes) y mueren
(dejan de ser objetos). En un determinado instante, las características de un objeto
adquieren valores particulares que evidencian su estado. Dos transacciones bancarias
pueden tener los estados (“retiro”, 200000, 110107, octubre 17 de 2008, 11:45:23) y
(“consignación”, 550000, 235742, noviembre 10 de 2009, 15:00:01).
Las clases y objetos también admiten varias representaciones. Una de las más
aceptadas en el mercado del software es la establecida por UML, donde los rectángulos
preponderan por su sencillez y claridad, como se observa en las figuras 2.1 y 2.2.
32
41. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
Nombre de la clase
Caracterís cas
Comportamientos
Figura 2.1. Representación de una clase
Nombre de la clase: referencia a objeto
Valores de atributo
Figura 2.2. Representación de un objeto
Ejemplo 2.1. La figura 2.3 ilustra a la clase Caballo y dos objetos con algunas de sus
características.
Caballo Caballo: c1
Bucéfalo
nombre
Oriental-Turcomano
raza
Negro azabache
color
peso
edad
alzada
correr Caballo: c2
relinchar Palomo
pastar Ibérico-Norteafricano
dormir Blanco
Figura 2.3. La clase Caballo con los objetos c1 y c2
33
42. Fundamentos de Programación Orientada a Objetos
Los objetos por lo general ocultan sus características al mundo exterior y muestran
los comportamientos para poder comunicarse. Para representar lo anterior, con la
ayuda del UML se antepone un signo menos (-) a los atributos (significa que son de
visibilidad privada) y un signo más (+) a los comportamientos (significa que son de
visibilidad pública), tal como se observa en la figura 2.4. Para diferenciar un atributo
de un comportamiento, a este último se le pospone un par de paréntesis ( ) para
denotar acción. Por último, puede observarse que a los atributos se les asocia un tipo
de dato, resaltado en letra negrita.
Caballo
-raza: cadena
-color: cadena
-peso: real
-edad: entero
-alzada: real
+correr ( )
+relinchar ( )
+pastar ( )
+dormir ( )
Figura 2.4. La clase Caballo con atributos privados y comportamientos públicos
Un mecanismo interesante para la comprensión inicial y la ambientación al trabajo
con objetos, según [Zapata1998], es la expresión literaria del cuento, narración breve
de ficción donde los personajes (sustantivos propios) son los objetos, los sustantivos
comunes son las clases, los adjetivos son los atributos y los verbos los comportamientos.
Para comprender lo anterior, el lector puede retomar las historias que preceden a los
capítulos de este libro. En los diagramas que las acompañan, sus objetos se crean
mediante un método constructor, que tiene una identidad manifiesta en su estado,
el cual se controla a través de métodos denominados modificadores y tiene unos
comportamientos manifiestos a través de los métodos analizadores. En el lenguaje
de programación, el estado de un objeto está dado por los valores actuales de sus
34
43. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
atributos, y se puede cambiar con los métodos asignarX( ) y obtenerX( ), donde X
corresponde a cualquier atributo.
Para una mayor claridad, retomemos el ejemplo 2.1., representado en la figura
2.5. En ella puede observarse que se presenta la clase Caballo con los métodos ya
mencionados: un constructor (tiene el mismo nombre de la clase), doce métodos
modificadores (asignar y obtener para cada atributo) y los métodos analizadores ya
expuestos (correr, relichar, pastar, dormir).
Figura 2.5. La clase Caballo con métodos constructores,
modificadores y analizadores
35
44. Fundamentos de Programación Orientada a Objetos
El método Caballo( ) permite crear caballos (podríamos afirmar que este método
hace que “nazcan” caballos). Todos los métodos asignar requieren de un parámetro del
mismo tipo del atributo que modifican; los métodos obtener siempre retornan un valor
del misto tipo del atributo que recuperan. Para ilustrar todo esto véase el ejemplo 2.2.
Ejemplo 2.2. Crear un caballo llamado Trueno de raza Bávaro, color castaño, peso 350 kg,
edad 10 años y alzada 1.60 metros. Visualizar su estado, es decir, mostrar los valores de todos
sus atributos.
1. clase Caballeriza
2. l co e ta co ac o r nc al ( )
3. Caballo c = n e o Caballo ( )
4. c.asignarNombre (“Trueno”)
5. c.asignarRaza (“Bávaro”)
6. c.asignarColor (“Castaño”)
7. c.asignarPeso (350)
8. c.asignarEdad (10)
9. c.asignarAlzada (1.60)
10. Flujo.imprimir (“Los datos del caballo son: ”)
11. Flujo.imprimir (“Nombre: ” + c.obtenerNombre ( ))
12. Flujo.imprimir (“Raza: ” + c.obtenerRaza ( ))
13. Flujo.imprimir (“Color: ” + c.obtenerColor ( ))
14. Flujo.imprimir (“Peso: ” + c.obtenerPeso ( ))
15. Flujo.imprimir (“Edad: ” + c.obtenerEdad ( ))
16. Flujo.imprimir (“Alzada: ” + c.obtenerAlzada ( ))
17. n todo
18. n cla e
Observaciones:
La instrucción 3 crea un nuevo caballo sirviéndose del operador nuevo y el
constructor sin argumentos Caballo( ). El operador nuevo permite reservar memoria
para el objeto c.
De la instrucción 4 a la 9 se establece un estado para el objeto c, asignándole
valores a cada uno de sus atributos. Debe tenerse en cuenta que sería incorrecta
una instrucción como c.nombre = “Trueno” porque el tributo nombre tiene
visibilidad privada.
36
45. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
Si se hubiera definido en la clase Caballo otro constructor sobrecargado como:
Caballo (cadena n, cadena r, cadena c, real p, entero e, real a), las instrucciones
3 a la 9 se podrían resumir en una sola, así:
Caballo c = nuevo Caballo(“Trueno”, “Bávaro”, “Castaño”, 350, 10, 1.60)
Las instrucciones 11 a 16 obtienen el estado del objeto c y lo visualizan en pantalla
por medio del método imprimir de la clase Flujo. Debe notarse un error cuando
se escribe una instrucción como Flujo.imprimir (“Alzada:” + c.alzada), pues el
atributo alzada es de acceso privado.
A continuación se presentan algunos problemas para afianzar los anteriores
conceptos y procedimientos.
PROBLEMA 1: HOLA MUNDO
Visualizar el mensaje “Hola mundo”.
Este clásico problema se soluciona de forma “inmediata” con las cuatro fases
implícitas en la didáctica propuesta en el capítulo 1: Tabla de requerimientos, Diagrama
de clases, Contratos de clase y Seudo código orientado a objetos. Cabe anotar que
mientras más complejo sea el problema, la aplicación de cada fase se hace más
pertinente. Dada la trivialidad del problema, las tres primeras fases se pueden omitir,
pudiendo exponer de manera directa el seudo código. Sin embargo, aquí se exponen
todas las fases en la búsqueda de logros escuetamente didácticos.
a) Tabla de requerimientos
den cac n del
e cr c n ntrada e ltado al da
re er ento
Visualizar un El mensaje expuesto
R Ninguna
mensaje al usuario
37
46. Fundamentos de Programación Orientada a Objetos
b) Diagrama de clases
es a co ac o principal ( )
El diagrama de clases expuesto es el más simple que se pueda concebir en UML.
El rectángulo dividido en tres áreas representa, en el área superior, la clase, que
contiene su nombre (Proyecto o Flujo); el área del medio corresponde a la declaración
de atributos de clase (en este caso se encuentra vacía para ambas clases), y el área
inferior contiene la firma (cabecera o prototipo) de los métodos.
La clase Flujo se ha expuesto de manera parcial. Su estructura completa se
encuentra en el apartado 2.5. (Configuración de las clases de uso común).
En la firma “+ estático vacío principal ( )”, el signo cruz (+) indica que el método
tiene visibilidad pública; la palabra reservada estático indica que el método se puede
invocar haciendo uso del nombre de la clase, sin la intermediación de un objeto; y la
palabra reservada vacío especifica que el método no retorna valor.
Dado que el método principal( ) siempre estará presente en cualquier aplicación
porque constituye su punto de entrada y salida, bastará con especificar la visibilidad y
nombre, y se asumirá siempre por omisión que el método es estático y no retorna valor.
Por tanto, en un diagrama de clases la firma “+ principal( )” equivale a “+ estático
vacío principal( )”, y en el seudocódigo el encabezado de método “público principal(
)” equivale a “público estático vacío principal( )”. En varias apartes del libro se
utiliza la forma abreviada.
38
47. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
c) Contrato de la clase Proyecto
o re del e er ento
recond c n o tcond c n
todo a oc ado
No se ha
principal ( ) El mensaje “Hola
R visualizado el
mensaje
Nota: la columna “Modelo verbal” no aplica para este caso.
d) Seudo código orientado a objetos (OO)
clase Proyecto
l co e ta co ac o r nc al
Flujo.imprimir (“Hola mundo”)
n todo
n cla e
Observaciones:
El método estático imprimir( ) de la clase de uso común Flujo permite mostrar
información al usuario en el dispositivo estándar de salida (el monitor). Las clases
de uso común y los métodos estáticos se estudian en las secciones 2.4 y 3.2,
respectivamente.
El diseño del tipo abstracto de dato Proyecto, aquí presentado, no es el más
apropiado, debido a que se expone dicha clase carente de atributos. Otra posible
alternativa de solución al problema se presenta modificando la estructura de la
clase Proyecto de la siguiente manera:
39
48. Fundamentos de Programación Orientada a Objetos
En este caso se define el atributo estático mensaje, con el objetivo de almacenar allí
el mensaje “Hola mundo”.
Los atributos estáticos se comportan como variables globales para cualquier
método declarado como estático dentro de la clase; esto significa que todo método
estático puede referenciar directamente a una variable estática, como se observa en el
siguiente seudocódigo.
clase Proyecto
r ado e ta co cadena mensaje
publico e ta co ac o r nc al ( )
mensaje = “Hola mundo”
Flujo.imprimir (mensaje)
n etodo
n cla e
El método principal( ) se tiene que declarar como estático porque siempre es
llamado antes de que exista cualquier objeto. Los métodos y atributos estáticos se
pueden acceder sin la intermediación de un objeto de la clase donde fueron definidos;
estos conceptos se profundizarán en el ítem 3.2 (Métodos).
Una alternativa adicional donde se utiliza un objeto para imprimir el mensaje se
presenta a continuación.
40
49. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
La clase Mensaje consta de un atributo de tipo cadena y tres métodos: el constructor
(tiene el mismo nombre de la clase) y los métodos modificadores asignarContenido( ) y
obtenerContenido( ).
clase Mensaje
r ado cadena contenido
publico Mensaje ( )
n etodo
//------------------------------------------------
publico asignarContenido(cadena x)
contenido = x
n etodo
//------------------------------------------------
l co cadena obtenerContenido( )
retornar contenido
n etodo
n cla e
//*****************************************
clase Proyecto
publico e ta co ac o r nc al ( )
Mensaje saludo = n e o Mensaje( )
saludo.asignarContenido(“Hola mundo”)
Flujo.imprimir(saludo.obtenerContenido( ))
n etodo
n cla e
41
50. Fundamentos de Programación Orientada a Objetos
Se pueden notar en el diagrama de clases las relaciones de dependencia
representadas con líneas dirigidas punteadas, las cuales indican que la clase Proyecto
“usa” o utiliza un objeto de tipo Mensaje y un método de la clase Flujo.
CREACIÓN DE OBJETOS Y PASO DE MENSAJES
Un objeto se crea mediante el método constructor, fácil de identificar porque tiene
el mismo nombre de la clase a la cual pertenece. El formato general para la creación
de un objeto es:
NombreDeClase objeto = nuevo NombreDeClase( )
Nombre de la clase
Algunos ejemplos:
Entero num = nuevo Entero( )
Real x = nuevo Real( )
Producto p = nuevo Producto( )
Los objetos se comunican entre sí a través del paso de mensajes. Cuando un objeto
recibe un mensaje se obliga a la ejecución de un método. En general se tiene:
En particular, se enviarán tres mensajes, uno a cada objeto creado en los ejemplos
anteriores:
42
51. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
num.asignarValor(17)
max = x.obtenerMaxValor( )
p.asignarPrecio(23890.5)
PROBLEMA 2. OBJETOS TIPO CÍRCULO
La clase Círculo se encuentra definida de la siguiente manera:
Círculo
- x: entero
- y : entero
- radio: real
- colorContorno: caracter
- colorRelleno: caracter
+ Círculo ( )
+ Círculo (entero x1, entero y1, real r1)
+ asignarX (entero p)
+ asignarY (entero p)
+ asignarRadio (real p)
+ asignarColorC (caracter p)
+ asignarColorR (caracter p)
+ obtenerX ( ): entero
+ obtenerY ( ): entero
+ obtenerRadio ( ): real
+ obtenerColorC ( ): cadena
+ obtenerColorR ( ): cadena
+ dibujar ( )
+ área ( ): real
+ perímetro ( ): real
Los atributos x e y corresponden a las coordenadas del centro del círculo; el atributo
radio a la longitud del radio; los atributos de tipo carácter representan los colores del
contorno (negro, amarillo, azul o rojo) e interior del círculo (negro, amarillo, azul, rojo o
sin relleno).
43
52. Fundamentos de Programación Orientada a Objetos
Respecto a los métodos se debe observar lo siguiente:
- El constructor sin argumentos crea un círculo con centro (0, 0), radio igual a cero,
color de contorno negro y sin relleno.
- El constructor sobrecargado con los argumentos x1, y1 y r1 crea un círculo con
centro (x1, y1) y radio r1; también con un color de perímetro negro y sin relleno.
- Los métodos asignarX(entero p), asignarY(entero p) y asignarRadio(real p),
permiten modificar las coordenadas del centro y la longitud del radio.
- Los métodos asignarColorC(caracter p) y asignarColorR(caracter p) establecen
el color del contorno y el relleno, respectivamente. En ambos casos el parámetro
p tiene la siguiente interpretación:
‘n’ negro
‘a’ amarillo
p= ‘b’ azul
‘r’ rojo
‘s’ sin relleno
- Todos los métodos obtener devuelven el valor respectivo de su atributo; así,
obtenerX( ) retorna el valor de la abscisa del centro y obtenerY( ) el valor de la
ordenada; sin embargo, los métodos obtenerColorC( ) y obtenerColorR( ) retornan
la cadena correspondiente al color del contorno o del relleno, en lugar del carácter
asignado al color.
- El método dibujar( ), dibuja un círculo con centro, radio y colores de contorno y
relleno asignados al momento.
- El método área( ) calcula y retorna el área del círculo.
- El método perímetro( ) calcula y retorna el perímetro del círculo.
Se requiere escribir un pseudocódigo orientado a objetos que permita:
1. Dibujar el círculo c1 con centro (7, 8) y radio 9.2 cm, contorno negro y sin relleno.
2. Dibujar los círculos c2 (3, 4, 8.0) y c3 (-9, 3, 4.7). El círculo c2 debe tener contorno
rojo y relleno amarillo. El círculo c3 irá todo pintado de azul.
3. Imprimir el área y el perímetro de los tres círculos.
44
53. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
Solución:
a) Tabla de requerimientos
den cac n e ltado
del e cr c n ntrada al da
re er ento
Dibujar el círculo c1 con Primer círculo
centro (7, 8) y radio 9.2 (c1) dibujado.
R1 Ninguna
cm, perímetro negro y
sin relleno.
Dibujar los círculos c2 Segundo y tercer
(3, 4, 8.0) y c3 (-9, 3, círculo dibujados
R2 4.7), con los colores Ninguna (c2 y c3).
de contorno y relleno
El área y
Hallar el área y el perímetro de los
R3 perímetro de los tres Ninguna círculos c1, c2
círculos. y c3.
Observación:
La tabla de requerimientos indica que R1, R2 y R3 carecen de entradas. No sería
contraproducente especificar que se tienen entradas no nulas, en este caso constantes.
Por ejemplo, para el requerimiento R1 la entrada sería “Tres constantes enteras,
dos para el centro (7 y 8) y una para el radio (9.2)”. Sin embargo, se ha decidido
escribir “Ninguna” teniendo en cuenta que toda entrada implica un ingreso de datos
por el usuario o una lectura desde un dispositivo externo de memoria, como un disco
magnético.
b) Diagrama de clases
45
54. Fundamentos de Programación Orientada a Objetos
c) Seudocódigo
clase Solución
publico e ta co ac o r nc al ( )
// Requerimiento R1
Círculo c1 = n e o Círculo ( )
c1.asignarX (7)
c1.asignarY (8)
c1.asignarRadio (9.2)
c1.dibujar ( )
// Requerimiento R2
Círculo c2 = n e o Círculo (3, 4, 8.0)
c2.asignarColorC(‘r’)
c2.asignarColorR(‘a’)
c2.dibujar ( )
Círculo c3 = n e o Círculo (-9, 3, 4.7)
c3.asignarColorC(‘b’)
c3.asignarColorR(‘b’)
c3.dibujar ( )
// Requerimiento R3
Flujo.imprimir (“Área y perímetro de los tres círculos:”)
Flujo.imprimir (“Círculo 1:” )
Flujo.imprimir (“Área = “ + c1.área( ) + “cm2”)
Flujo.imprimir (“Perímetro = “ + c1.perímetro( ) + “cm”)
Flujo.imprimir (“Círculo 2:” )
Flujo.imprimir (“Área = “ + c2.área( ) + “cm2”)
Flujo.imprimir (“Perímetro = “ + c2.perímetro( ) + “cm”)
Flujo.imprimir (“Círculo 3:” )
Flujo.imprimir (“Área = “ + c3.área( ) + “cm2”)
Flujo.imprimir (“Perímetro = “ + c3.perímetro( ) + “cm”)
n etodo
n cla e
Observaciones:
El círculo c1 fue creado con el constructor sin argumentos y los círculos c2 y
c3 con el constructor sobrecargado.
Al imprimir el área y perímetro de un círculo, también se puede visualizar su
estado, es decir, la información referente a su centro y radio. Para el caso del
círculo c1 se tendría:
46
55. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
Flujo.imprimir (“Círculo 1:” )
Flujo.imprimir (“Centro: (” + c1.obtenerX( ) + “, ” + c1.obtenerY( ) + “)”)
Flujo.imprimir (“Radio: “ + c1.obtenerRadio( ) + “cm”)
Flujo.imprimir (“Área = “ + c1.area( ) + “cm2”)
Flujo.imprimir (“Perímetro = “ + c1.perímetro( ) + “cm”)
Un diseño orientado a objetos más adecuado, que se estudia en el capítulo 5
(Relaciones entre clases), es el siguiente:
Solución
- c1: Círculo
c1, c2, c3 - c2: Círculo <<usar>>
Círculo Flujo
- c3: Círculo
+ principal ( )
Se deja propuesto el desarrollo del pseudocódigo concerniente.
2.2. TIPOS DE DATOS PRIMITIVOS Y VARIABLES
Un dato es la representación formal de hechos, conceptos o instrucciones, adecuada
para su comunicación, interpretación y procesamiento por seres humanos o medios
automáticos. Un tipo de datos es la especificación de un dominio (rango de valores) y
de un conjunto válido de operaciones a los que normalmente los traductores6 asocian
un esquema de representación interna propio.
6 Un traductor es un lenguaje que decodifica las instrucciones escritas en un lenguaje de programa-
ción para que un computador las pueda interpretar.
47
56. Fundamentos de Programación Orientada a Objetos
Cuando un tipo de datos está definido para un lenguaje o seudo lenguaje, se habla
de tipos de datos primitivos o estándar, utilizados para la construcción de expresiones
o nuevos tipos de datos. El seudo lenguaje definido en el proyecto Método Integrado de
Programación Secuencial y Programación Orientada a Objetos -MIPSOO [GIISTA2006],
utiliza cinco tipos de datos:
entero: números enteros con signo almacenados en 32 bits (4 bytes), comprendidos
entre -2147483648 a 2147483647 (-231 a 231 -1)
Ejemplos:
-56789, 403, 0, 2344521567
real: denota un tipo simple que almacena valores de punto flotante de 32 bits, en
un rango aproximado de 3.4 * 10 38 a 3.4 * 1038.
Ejemplos:
3.1416, -88.7, 49795.1, 17, -1.0
Las cantidades reales anteriores, separadas por comas, incluyen punto decimal.
Teniendo en cuenta que los números enteros son un subconjunto de los números reales,
la cifra 17 dada en los ejemplos se podría haber escrito de igual manera como 17.0.
caracter: se utiliza para declarar un carácter Unicode. Todo carácter va encerrado
entre comillas simples.
Ejemplos:
‘@’, ‘,’, ‘b’, ‘B’, ‘4’,’ ’, ´+´
Se puede notar que los caracteres pueden ser numéricos como ’4’, alfabéticos como
‘B’ y especiales como’@’. La barra espaciadora (carácter blanco) se representa como
dos comillas simpes vacías (‘ ’).
logico: se utiliza para declarar variables que almacenan el valor de verdad cierto
o falso, únicos valores posibles para una variable de este tipo, propios del algebra
de Boole.
48
57. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
cadena: este tipo representa una cadena de caracteres Unicode. Toda cadena se
escribe entre comillas dobles.
Ejemplos:
“XYZ123”, “Programar con OO es fascinante”, “Ser o no ser”, “123”
Los tipos de datos se utilizan para declarar variables locales, definir atributos de
clases, declarar parámetros formales y especificar valores de retorno de los métodos
que se comportan como una función.
Una variable se considera como un compartimiento de memoria con una dirección
y nombre únicos, cuyo contenido puede variar en tiempo de ejecución del programa.
Para efectos de procesamiento de una variable, interesa conocer su nombre y no su
dirección. Un nombre de variable es un identificador que debe cumplir las siguientes
características:
Debe comenzar con una letra.
No puede contener espacios ni caracteres especiales, a excepción del guión bajo o
underline.
No puede coincidir con una palabra reservada del seudo lenguaje o con un tipo de
datos estándar. El apéndice B expone el listado de palabras reservadas.
No existe límite para la longitud de un identificador, aunque en general se aconseja
que no exceda los 15 caracteres para facilitar su escritura y manejo. A continuación
se dan ejemplos de identificadores válidos y observaciones sobre su creación.
Tabla 2.1. Identificadores válidos
Algunos identificadores inválidos se presentan en la siguiente tabla:
IDENTIFICADOR OBSERVACIÓN
suma
contadorDePlantas
díasConFrío Los cinco identificadores contienen sólo letras
árbol
mesa
49
58. Fundamentos de Programación Orientada a Objetos
Ambos identificadores son distintos: se diferencian
por la vocal e tildada. Es necesario aclarar que
cedula
se evitarán las tildes en los identificadores para
cédula
facilitar el proceso de codificación a un lenguaje de
programación
promedioAnual Los seis identificadores están formados por dos
promedio_anual palabras; si no se utiliza el guión bajo, la letra inicial
tiempoEsperado de cada nueva palabra, a excepción de la primera,
tiempo_esperado va en mayúsculas para efectos de claridad en su
deporteExtremo lectura. Si las palabras van separadas por guión bajo,
deporte_extremo se puede escribir todo en minúsculas
PI
Por estar escritos en mayúsculas, deben hacer
VALOR_MIN
referencia a constantes figurativas
CONST_DE_AVOGADRO
Animal
Al comenzar con letra mayúscula deber hacer
Producto
referencia a nombres de clases
CuentaBancaria
mes7,
cont123, Contienen combinaciones de letras, dígitos y guiones
a1b2_c
Tabla 2.2. Identificadores inválidos
IDENTIFICADOR OBSERVACIÓN
suma total Contiene un espacio
3cedula Comienza con un dígito
si
Clase
Coinciden con palabras reservadas del seudo lenguaje
fin_si
segun
entero
Coinciden con tipos de datos estándar o primitivos
caracter
Entero
Mat
Coinciden con clases de uso común
Real
Cadena
calle#31
valorEn$, Contienen caracteres especiales no permitidos
pago*mes
50
59. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
Para declarar variables se sigue la siguiente sintaxis general:
tipoDeDato lista_de_identificadores_separados_por_comas
veamos:
entero x
real y
entero edad, contador
logico sw, sexo, estado
Si un identificador se declara como parámetro o al interior de un método se
considera campo variable local o simplemente variable local; si se declara por fuera
de todo método se convierte en un atributo de clase. Por ejemplo, en la figura 2.6
codigo y precio son atributos, mientras que c y p son variables locales pasadas como
parámetros.
Figura 2.6. Diferencia entre atributos y variable
2.3. OPERADORES Y EXPRESIONES
Se utilizarán en este libro los operadores binarios del lenguaje C, especificados en
la tabla 2.3.
51
60. Fundamentos de Programación Orientada a Objetos
Tabla 2.3. Operadores binarios del lenguaje C
TIPO DE OPERADOR OPERADORES DESCRIPCIÓN
+ Suma
– Resta
* Producto
Aritméticos
/ División
% Módulo
– Menos unitario
&& Conjunción
Lógicos || Disyunción
! Negación
<
Menor que
<=
Menor o igual que Mayor
>
Relacionales que
>=
Mayor o igual que Igual a
==
Diferente de
!=
De asignación = Asignación
De concatenación + Concatenar con
Una expresión, es una combinación válida de operadores y operandos que devuelven
un valor único. En la expresión a + b – c, las variables a, b y c son operandos y los
símbolos + y – son operadores.
Una expresión puede ser aritmética, lógica, relacional, de asignación o de
concatenación, como se indica en la tabla contigua:
Tabla 2.4. Tipos de expresiones
TIPO DE
EXPRESIONES DESCRIPCIÓN
EXPRESIÓN
Suma de dos variables
a+b
Producto de dos constantes
5*7
Expresión compuesta: resta a la variable
valor – 17 % 9
Aritmética valor el resultado de 17 % 9
Expresión que incluye a la clase de uso
Mat.seno (30) – Mat.
común Mat para calcular el seno de un
coseno (45) * 2
ángulo y el coseno de otro
52
61. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
Expresión lógica compuesta. Las variables p,
Lógica p && q || r
q y r son de tipo lógico
a<b Compara dos variables
salario >= 2500000 Compara una variable con una constante
Relacional numérica
nombre == “Ana” Compara una variable con una constante
de cadena
x=9 Asigna a una variable, una constante
numérica entera
De asignación
nombre = “Darío” Asigna a una variable, una constante de
tipo cadena
De “Total =” + total Concatena un texto (o constante de tipo
concatenación cadena) con una variable de tipo cadena.
Observaciones:
Una expresión lógica puede combinar sub-expresiones aritméticas, lógicas y
relacionales, como en el siguiente caso:
(7 % 5 < 9) && (edad > 20) || (indicativo == cierto)
En los operadores aritméticos el módulo (%) sólo opera con enteros y el resultado
es otro entero.
La operación 33 % 7 da como resultado el residuo de la división entera, es
decir 33 % 7 == 5 porque
El menos unitario devuelve el mismo tipo que el operando. En el resto de los
operadores aritméticos, si algún operador es real, el resultado será real.
Para los operadores lógicos los operandos deben ser del mismo tipo.
En la asignación sólo se pueden operar datos del mismo tipo en los miembros
izquierdo (que siempre es una variable) y derecho (que puede ser otra variable,
53
62. Fundamentos de Programación Orientada a Objetos
una constante o una expresión). Para la asignación entre diferentes tipos, se puede
aplicar la conversión forzada de tipos (casting), como en el siguiente caso:
entero a, b
real c
c = (real) a + b
La prioridad de un operador hace referencia al orden en el cual se ejecuta dentro
de una expresión. La prioridad se puede alterar con el uso del agrupador paréntesis,
en cuyo caso se evalúa primero su contenido. Obsérvese la tabla 2.5, organizada de
arriba hacia abajo según la precedencia del operador, donde el agrupador paréntesis
posee la mayor prioridad; y los operadores de relación y asignación, la menor.
Tabla 2.5. Prioridad de los operadores
Prioridad de los operadores
Paréntesis ()
Operadores unitarios -, +
Operaciones de la clase Mat Mat.elevar( ), Mat.aleatorio( ), etc.
Operadores multiplicativos *, /,%, &&
Operadores auditivos +, -, ||
Operadores de relación ==, !=, <, <=, >, >=
Operador de asignación =
En el ejemplo 2.3. se evaluarán tres expresiones donde se utilizan los mismos
operandos y operadores, pero se cambia el orden de prioridad con el uso de paréntesis.
Los círculos debajo de las llaves indican el orden en el cual se efectúan las operaciones.
Notar que los tres resultados son distintos.
54
66. Fundamentos de Programación Orientada a Objetos
2.4. CLASES DE USO COMÚN: UN MICRO MUNDO PARA EFECTOS
DE REUTILIZACIÓN
Las clases de uso común, como su nombre lo indica, son de uso generalizado para
una gran variedad de problemas y establecen un marco de trabajo similar a un pequeño
mundo reutilizable.
TIPOS DE DATOS ESTÁNDAR COMO OBJETOS
Los tipos de datos primitivos entero, real, caracter, logico y cadena representan
valores simples, no objetos complejos. En ciertos casos, el uso de tipos de datos
primitivos puede aumentar el rendimiento por cuestiones de almacenamiento interno.
Sin embargo, en ocasiones la eficiencia así lograda dificulta ciertos procesos, resultando
más conveniente el tratamiento de los tipos de datos en base a objetos.
En lo que sigue se analizarán las clases de uso común. Debe aclararse que el
nombre de las clases correspondientes a cada tipo de datos coincide con el nombre del
dato primitivo; sólo cambia la primera letra del nombre del tipo a mayúscula: Entero,
Real, Caracter, Logico y Cadena.
58
67. Lógica y Programación orientada a objetos. Un enfoque basado en problemas
LA CLASE ENTERO
Entero
- valor: entero
- con t e ta co entero MIN_VALOR = -2.147.483.648
- con t e ta co entero MAX_VALOR = 2.147.483.647
+ Entero ( )
+ asignarValor (entero x)
+ obtenerValor ( ): entero
+ obtenerMinValor( ): entero
+ obtenerMaxValor( ): entero
e ta co obtenerMinValor( ): entero
e ta co obtenerMaxValor( ): entero
+ esIgual ( ntero x): logico
+ convBin ( entero x): adena
+ convBin ( ): adena
e ta co convBin (entero x ): adena
+ convOctal (entero x ): adena
+ convOctal ( ): adena
e ta co convOctal (entero x ): adena
+ convHex (entero x ): adena
+ convHex ( ): adena
e ta co convHex (entero x ): adena
+ cadena x): entero
e ta co cadena x): entero
Miembros dato de la clase Entero:
valor: cantidad que representa el valor entero, comprendido entre -2.147.483.648
y 2.147.483.647 (almacenamiento de un entero en 4 bytes).
MIN_VALOR: constante estática entera igual a -2.147.483.648
MAX_VALOR: constante estática entera igual a 2.147.483.647
59