SlideShare ist ein Scribd-Unternehmen logo
1 von 286
Downloaden Sie, um offline zu lesen
Lógica y programación
orientada a objetos:
Un enfoque basado
en problemas
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
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
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
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
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
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
Lógica y programación orientada a objetos:Un enfoque basado en problemas
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
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
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
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
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
Lógica y programación orientada a objetos:Un enfoque basado en problemas
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
Lógica y programación orientada a objetos:Un enfoque basado en problemas
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
Una didáctica para el aprendizaje de la programación



Diagrama de clases:




Diagrama de objetos:




                                                       10
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Lógica y programación orientada a objetos:Un enfoque basado en problemas
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
Lógica y programación orientada a objetos:Un enfoque basado en problemas
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
Fundamentos de Programación Orientada a Objetos




Diagrama de clases:




                                                  30
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Lógica y Programación orientada a objetos. Un enfoque basado en problemas



Ejemplo 2.3: evaluación de tres especímenes aritméticas


  1) 5 – 8 * 7 / 6 + Mat.elevar (2, 5) * 3 % 2

                                        32

      5 – 8 * 7 / 6 + 32 * 3 % 2

                56

      5 – 56 / 6 + 32 * 3 % 2

               9.33

      5 – 9.33 + 32 * 3 % 2

                          96

      5 – 9.33 + 96 % 2

                            0

      5 – 9.33 + 0

          -4.33

      – 4.33 + 0

          -4.33
                                 Respuesta




                                   55
Fundamentos de Programación Orientada a Objetos



   2) (5 – 8 * ( 7 / 6)) + Mat.elevar (2, 5) * 3 % 2

                             1.16


         (5 – 8 * 1.16) + Mat.elevar (2, 5) * 3 % 2

                       9.28


         (5 – 9.28) + Mat.elevar (2, 5) * 3 % 2

              -4.28


         -4.28 + Mat.elevar (2, 5) * 3 % 2

                                  32

         -4.28 + 32 * 3 % 2

                             96

         -4.28 + 96 % 2

                             0

         -4.28 + 0

              -4.28
                                           Respuesta




                                                   56
Lógica y Programación orientada a objetos. Un enfoque basado en problemas



3) (5 – 8) * 7 / (6 + (Mat.elevar (2, 5) * 3 ) % 2)

       -3

   -3 * 7 / (6 + (Mat.elevar (2, 5) * 3 ) % 2)

                              32


   -3 * 7 / (6 + (32 * 3 ) % 2)

                       96

   -3 * 7 / (6 + 96 % 2)

                       0

   -3 * 7 / (6 + 0)

                6

   -3 * 7 / 6

      -21

   -21 / 6

      -3.5
                      Respuesta




                              57
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
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
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas
Lógica y programación orientada a objetos:Un enfoque basado en problemas

Weitere ähnliche Inhalte

Was ist angesagt?

Lógica de Programacion. Efrain Oviedo
Lógica de Programacion. Efrain OviedoLógica de Programacion. Efrain Oviedo
Lógica de Programacion. Efrain Oviedosullinsan
 
Equipo 3. Secciones y perfiles en topografia.pptx
Equipo 3. Secciones y perfiles en topografia.pptxEquipo 3. Secciones y perfiles en topografia.pptx
Equipo 3. Secciones y perfiles en topografia.pptxMelRuiz9
 
Monografia matrices en la ing. civil
Monografia   matrices en la ing. civilMonografia   matrices en la ing. civil
Monografia matrices en la ing. civilMelvin Hallasi
 
Geometria descriptiva
Geometria descriptivaGeometria descriptiva
Geometria descriptivaToño Selem
 
Industria metalmecanica informe
Industria metalmecanica   informeIndustria metalmecanica   informe
Industria metalmecanica informeelmuniola
 
Estudio de mercado de BI en America Latina 2011
Estudio de mercado de BI en America Latina 2011Estudio de mercado de BI en America Latina 2011
Estudio de mercado de BI en America Latina 2011Pedro Chavez
 
Clase sem 1 mecanica aplicada 3 ciclo
Clase sem 1 mecanica aplicada 3 cicloClase sem 1 mecanica aplicada 3 ciclo
Clase sem 1 mecanica aplicada 3 cicloronaldopaucarmori
 
Investigación y Gestión de Proyectos
Investigación y Gestión de ProyectosInvestigación y Gestión de Proyectos
Investigación y Gestión de ProyectosVictor Zapata
 
Đề tài: Ứng dụng Mod Security để bảo vệ web server, HAY, 9đ - Gửi miễn phí qu...
Đề tài: Ứng dụng Mod Security để bảo vệ web server, HAY, 9đ - Gửi miễn phí qu...Đề tài: Ứng dụng Mod Security để bảo vệ web server, HAY, 9đ - Gửi miễn phí qu...
Đề tài: Ứng dụng Mod Security để bảo vệ web server, HAY, 9đ - Gửi miễn phí qu...Dịch vụ viết bài trọn gói ZALO: 0909232620
 
Estacion total significado que es y como funciona.pdf
Estacion total significado que es y como funciona.pdfEstacion total significado que es y como funciona.pdf
Estacion total significado que es y como funciona.pdfAlexisJavierToro
 

Was ist angesagt? (14)

Errores en la medición
Errores en la mediciónErrores en la medición
Errores en la medición
 
Instructivo topografía
Instructivo topografíaInstructivo topografía
Instructivo topografía
 
Lógica de Programacion. Efrain Oviedo
Lógica de Programacion. Efrain OviedoLógica de Programacion. Efrain Oviedo
Lógica de Programacion. Efrain Oviedo
 
Equipo 3. Secciones y perfiles en topografia.pptx
Equipo 3. Secciones y perfiles en topografia.pptxEquipo 3. Secciones y perfiles en topografia.pptx
Equipo 3. Secciones y perfiles en topografia.pptx
 
Monografia matrices en la ing. civil
Monografia   matrices en la ing. civilMonografia   matrices en la ing. civil
Monografia matrices en la ing. civil
 
Geometria descriptiva
Geometria descriptivaGeometria descriptiva
Geometria descriptiva
 
Industria metalmecanica informe
Industria metalmecanica   informeIndustria metalmecanica   informe
Industria metalmecanica informe
 
Estudio de mercado de BI en America Latina 2011
Estudio de mercado de BI en America Latina 2011Estudio de mercado de BI en America Latina 2011
Estudio de mercado de BI en America Latina 2011
 
3. medición y error
3. medición y error3. medición y error
3. medición y error
 
Clase sem 1 mecanica aplicada 3 ciclo
Clase sem 1 mecanica aplicada 3 cicloClase sem 1 mecanica aplicada 3 ciclo
Clase sem 1 mecanica aplicada 3 ciclo
 
Investigación y Gestión de Proyectos
Investigación y Gestión de ProyectosInvestigación y Gestión de Proyectos
Investigación y Gestión de Proyectos
 
Đề tài: Ứng dụng Mod Security để bảo vệ web server, HAY, 9đ - Gửi miễn phí qu...
Đề tài: Ứng dụng Mod Security để bảo vệ web server, HAY, 9đ - Gửi miễn phí qu...Đề tài: Ứng dụng Mod Security để bảo vệ web server, HAY, 9đ - Gửi miễn phí qu...
Đề tài: Ứng dụng Mod Security để bảo vệ web server, HAY, 9đ - Gửi miễn phí qu...
 
Estacion total significado que es y como funciona.pdf
Estacion total significado que es y como funciona.pdfEstacion total significado que es y como funciona.pdf
Estacion total significado que es y como funciona.pdf
 
Superficie
SuperficieSuperficie
Superficie
 

Ähnlich wie Lógica y programación orientada a objetos:Un enfoque basado en problemas

Code igniter guia_usuario_2.1.0
Code igniter guia_usuario_2.1.0Code igniter guia_usuario_2.1.0
Code igniter guia_usuario_2.1.0niko_afv
 
Contabilidad_de_costos_4a_ed_Colin_J_201.pdf
Contabilidad_de_costos_4a_ed_Colin_J_201.pdfContabilidad_de_costos_4a_ed_Colin_J_201.pdf
Contabilidad_de_costos_4a_ed_Colin_J_201.pdfASECONTRIMR
 
Contabilidad_de_Costos_3ed_Garcia.pdf
Contabilidad_de_Costos_3ed_Garcia.pdfContabilidad_de_Costos_3ed_Garcia.pdf
Contabilidad_de_Costos_3ed_Garcia.pdfASECONTRIMR
 
LIBRO_DE_CONTABILIDAD_DE_COSTOS.pdf
LIBRO_DE_CONTABILIDAD_DE_COSTOS.pdfLIBRO_DE_CONTABILIDAD_DE_COSTOS.pdf
LIBRO_DE_CONTABILIDAD_DE_COSTOS.pdfASECONTRIMR
 
Contabilidad de costos, 3ra Edición.pdf LIBRO.pdf
Contabilidad de costos, 3ra Edición.pdf LIBRO.pdfContabilidad de costos, 3ra Edición.pdf LIBRO.pdf
Contabilidad de costos, 3ra Edición.pdf LIBRO.pdfLeslieSanchez64
 
Tutorial lego-mindstorm
Tutorial lego-mindstormTutorial lego-mindstorm
Tutorial lego-mindstormesandemetrio
 
Elastix a ritmo de merengue v-1-3
Elastix a ritmo de merengue v-1-3Elastix a ritmo de merengue v-1-3
Elastix a ritmo de merengue v-1-3unad
 
Code igniter spanish_userguide
Code igniter spanish_userguideCode igniter spanish_userguide
Code igniter spanish_userguideNelson Salinas
 
Code igniter spanish_userguide
Code igniter spanish_userguideCode igniter spanish_userguide
Code igniter spanish_userguidecombamx
 
Tutorial lego-mindstorm-1
Tutorial lego-mindstorm-1Tutorial lego-mindstorm-1
Tutorial lego-mindstorm-1wendy castillo
 
Tutorial lego mindstorm
Tutorial lego mindstormTutorial lego mindstorm
Tutorial lego mindstormsamuel luque
 
CAP I-II Proyectos de Inversión, 2da Edicion - Nassir Sapag Chaín.pdf
CAP I-II Proyectos de Inversión, 2da Edicion - Nassir Sapag Chaín.pdfCAP I-II Proyectos de Inversión, 2da Edicion - Nassir Sapag Chaín.pdf
CAP I-II Proyectos de Inversión, 2da Edicion - Nassir Sapag Chaín.pdfARASCELLIDELOSANGELE
 
Instalador de fontanería y energías renovables
Instalador de fontanería y energías renovablesInstalador de fontanería y energías renovables
Instalador de fontanería y energías renovablesManager Asesores
 
presupuestos-teoria-y-practica
presupuestos-teoria-y-practicapresupuestos-teoria-y-practica
presupuestos-teoria-y-practicafita cedño
 
Cardenas y-napoles-raul-andres-presupuestos-teoria-y-practica-2ed-1-1
Cardenas y-napoles-raul-andres-presupuestos-teoria-y-practica-2ed-1-1Cardenas y-napoles-raul-andres-presupuestos-teoria-y-practica-2ed-1-1
Cardenas y-napoles-raul-andres-presupuestos-teoria-y-practica-2ed-1-1ShanyAlvarez1
 

Ähnlich wie Lógica y programación orientada a objetos:Un enfoque basado en problemas (20)

Code igniter guia_usuario_2.1.0
Code igniter guia_usuario_2.1.0Code igniter guia_usuario_2.1.0
Code igniter guia_usuario_2.1.0
 
Contabilidad_de_costos_4a_ed_Colin_J_201.pdf
Contabilidad_de_costos_4a_ed_Colin_J_201.pdfContabilidad_de_costos_4a_ed_Colin_J_201.pdf
Contabilidad_de_costos_4a_ed_Colin_J_201.pdf
 
Contabilidad_de_Costos_3ed_Garcia.pdf
Contabilidad_de_Costos_3ed_Garcia.pdfContabilidad_de_Costos_3ed_Garcia.pdf
Contabilidad_de_Costos_3ed_Garcia.pdf
 
LIBRO_DE_CONTABILIDAD_DE_COSTOS.pdf
LIBRO_DE_CONTABILIDAD_DE_COSTOS.pdfLIBRO_DE_CONTABILIDAD_DE_COSTOS.pdf
LIBRO_DE_CONTABILIDAD_DE_COSTOS.pdf
 
Contabilidad de costos, 3ra Edición.pdf LIBRO.pdf
Contabilidad de costos, 3ra Edición.pdf LIBRO.pdfContabilidad de costos, 3ra Edición.pdf LIBRO.pdf
Contabilidad de costos, 3ra Edición.pdf LIBRO.pdf
 
Tutorial lego-mindstorm
Tutorial lego-mindstormTutorial lego-mindstorm
Tutorial lego-mindstorm
 
Elastix a ritmo de merengue v-1-3
Elastix a ritmo de merengue v-1-3Elastix a ritmo de merengue v-1-3
Elastix a ritmo de merengue v-1-3
 
Code igniter spanish_userguide
Code igniter spanish_userguideCode igniter spanish_userguide
Code igniter spanish_userguide
 
Code igniter spanish_userguide
Code igniter spanish_userguideCode igniter spanish_userguide
Code igniter spanish_userguide
 
Code igniter spanish_userguide
Code igniter spanish_userguideCode igniter spanish_userguide
Code igniter spanish_userguide
 
Contenido
Contenido Contenido
Contenido
 
Tutorial lego-mindstorm-1
Tutorial lego-mindstorm-1Tutorial lego-mindstorm-1
Tutorial lego-mindstorm-1
 
Tutorial lego mindstorm
Tutorial lego mindstormTutorial lego mindstorm
Tutorial lego mindstorm
 
CAP I-II Proyectos de Inversión, 2da Edicion - Nassir Sapag Chaín.pdf
CAP I-II Proyectos de Inversión, 2da Edicion - Nassir Sapag Chaín.pdfCAP I-II Proyectos de Inversión, 2da Edicion - Nassir Sapag Chaín.pdf
CAP I-II Proyectos de Inversión, 2da Edicion - Nassir Sapag Chaín.pdf
 
Instalador de fontanería y energías renovables
Instalador de fontanería y energías renovablesInstalador de fontanería y energías renovables
Instalador de fontanería y energías renovables
 
Gestion de la calidad
Gestion de la calidadGestion de la calidad
Gestion de la calidad
 
Captivate 5.5
Captivate 5.5Captivate 5.5
Captivate 5.5
 
Carpintería metálica
Carpintería metálicaCarpintería metálica
Carpintería metálica
 
presupuestos-teoria-y-practica
presupuestos-teoria-y-practicapresupuestos-teoria-y-practica
presupuestos-teoria-y-practica
 
Cardenas y-napoles-raul-andres-presupuestos-teoria-y-practica-2ed-1-1
Cardenas y-napoles-raul-andres-presupuestos-teoria-y-practica-2ed-1-1Cardenas y-napoles-raul-andres-presupuestos-teoria-y-practica-2ed-1-1
Cardenas y-napoles-raul-andres-presupuestos-teoria-y-practica-2ed-1-1
 

Lógica y programación orientada a objetos:Un enfoque basado en problemas

  • 1. Lógica y programación orientada a objetos: Un enfoque basado en problemas
  • 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
  • 38. Fundamentos de Programación Orientada a Objetos Diagrama de clases: 30
  • 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
  • 63. Lógica y Programación orientada a objetos. Un enfoque basado en problemas Ejemplo 2.3: evaluación de tres especímenes aritméticas 1) 5 – 8 * 7 / 6 + Mat.elevar (2, 5) * 3 % 2 32 5 – 8 * 7 / 6 + 32 * 3 % 2 56 5 – 56 / 6 + 32 * 3 % 2 9.33 5 – 9.33 + 32 * 3 % 2 96 5 – 9.33 + 96 % 2 0 5 – 9.33 + 0 -4.33 – 4.33 + 0 -4.33 Respuesta 55
  • 64. Fundamentos de Programación Orientada a Objetos 2) (5 – 8 * ( 7 / 6)) + Mat.elevar (2, 5) * 3 % 2 1.16 (5 – 8 * 1.16) + Mat.elevar (2, 5) * 3 % 2 9.28 (5 – 9.28) + Mat.elevar (2, 5) * 3 % 2 -4.28 -4.28 + Mat.elevar (2, 5) * 3 % 2 32 -4.28 + 32 * 3 % 2 96 -4.28 + 96 % 2 0 -4.28 + 0 -4.28 Respuesta 56
  • 65. Lógica y Programación orientada a objetos. Un enfoque basado en problemas 3) (5 – 8) * 7 / (6 + (Mat.elevar (2, 5) * 3 ) % 2) -3 -3 * 7 / (6 + (Mat.elevar (2, 5) * 3 ) % 2) 32 -3 * 7 / (6 + (32 * 3 ) % 2) 96 -3 * 7 / (6 + 96 % 2) 0 -3 * 7 / (6 + 0) 6 -3 * 7 / 6 -21 -21 / 6 -3.5 Respuesta 57
  • 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