Introducción Al Paradigma de La Programación Orientada A Objetos

Introducción al
paradigma de la
programación
orientada a
objetos
PID_00249623
David García Solórzano
Tiempo mínimo de dedicación recomendado: 2 horas

© FUOC • PID_00249623 Introducción al paradigma de la programación orientada a objetos
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada,
reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico,
químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita
de los titulares del copyright.
© FUOC • PID_00249623 Introducción al paradigma de la programación orientada a objetos
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
1. Contexto: programación estructurada......................................... 7
2. Y llegó la programación orientada a objetos............................. 11
3. De la programación estructurada a la programación

orientada a objetos............................................................................ 13
3.1. Introducción a los conceptos básicos de la programación
orientada a objetos ..................................................................... 13
3.2. Dado un problema real, ¿cuál es el proceso a seguir? ................. 14
4. Beneficios de la programación orientada a objetos................. 17
5. Enfrentarse a la programación orientada a objetos................. 18
Resumen....................................................................................................... 19
Bibliografía................................................................................................. 21
© FUOC • PID_00249623 5 Introducción al paradigma de la programación orientada a objetos
Introducción
Este módulo sitúa la asignatura dentro del grado. Para ello, explicaremos el
punto de partida a partir del cual empezamos esta asignatura, que no es otro
que el paradigma de la programación estructurada que aprendimos en la asig-
natura anterior de programación, Fundamentos de programación, en el caso
de telecomunicaciones, y Programación en el de multimedia. Una vez estemos
situados, veremos cómo se llega al paradigma de la programación orientada a
objetos (POO), elemento principal de estudio de esta asignatura.
Este módulo es introductorio y, por consiguiente, muchos de los conceptos

que se comentan serán vistos con más detalle en futuros módulos.
Objetivos
El objetivo principal de este módulo es contextualizar la asignatura. Concre-

tamente:
1. Ser consciente del punto de partida tras haber cursado la asignatura de

programación anterior.
2. Conocer el concepto de paradigma de programación, haciendo énfasis en la

programación estructurada –ya conocida por el estudiante– y su evolución
hacia la programación orientada a objetos (POO); paradigma que se estu-
diará en esta asignatura.
3. Entender el razonamiento que se sigue al programar mediante el paradig-

ma POO.
4. Comprender de modo general los beneficios que nos aporta el paradigma

de la programación orientada a objetos.
5. Ser conscientes de las dificultades a las que un programador novel, como

nosotros, se afronta al intentar aprender el paradigma de la programación
orientada a objetos.
1. Contexto: programación estructurada
Después de cursar la primera de las asignaturas de programación –Fundamen-

tos de programación o Programación–, seguro que sois conscientes de que un
programa debe ser diseñado (es decir, pensado con detenimiento) antes de co-
dificarlo (es decir, antes de escribir su código). Esto es más cierto cuanto más
compleja es la tarea que debe realizar nuestro programa. Es decir, uno no pue-
de ponerse a codificar directamente un programa de cualquier complejidad.
Para garantizar que los programas complejos funcionan –es decir, hacen lo que
se espera de ellos–, son fiables y están bien escritos apareció, a finales de los
años cincuenta, una nueva disciplina llamada ingeniería�del�software. Esta
disciplina propone métodos y teorías tanto para analizar problemas complejos
como para diseñar programas que resuelvan dichos problemas. Cada conjunto
de métodos y teorías que determinan una manera específica de analizar y re-
solver un problema se le llama enfoque de programación o, más formalmente,
paradigma�de�programación.
Una definición más formal de paradigma de programación podría ser la

de colección de conceptos, métodos y teorías que guían el proceso de
construcción de un programa, determinando su estructura.
Así pues, un paradigma de programación determina la forma en que pensamos

y formulamos los programas.
En los años setenta, se empezó con un paradigma llamado programación�es-

tructurada. Este paradigma se basa en ver un programa –que es el problema
complejo a resolver– como un conjunto de diferentes subprogramas que ha-
cen tareas concretas. Estos subprogramas pueden estar divididos, a su vez, en
más subprogramas y así sucesivamente. Dependiendo de cómo se realiza la
creación de los subprogramas, se habla de un enfoque top-down (o diseño des-
cendiente) o bottom-up (o diseño ascendente). Básicamente:
1)�Top-down: para resolver un problema complejo, se descompone el proble-

ma en varios problemas más pequeños y sencillos llamados subproblemas. Pa-
ra resolver cada subproblema, se trabaja cada uno de ellos por separado consi-
derándolos un nuevo problema que puede ser, a su vez, descompuesto en pro-
blemas más pequeños y así sucesivamente. Finalmente, se llegan a problemas
que pueden ser resueltos directamente sin necesidad de descomponer más.
Esto implica tener diferentes niveles de descomposición que van de lo general

–el problema complejo inicial– a lo particular o a un nivel de detalle mayor –
el subproblema de más bajo nivel de descomposición.
2)�Bottom-up: este enfoque empieza por abajo, es decir, con problemas que ya
se sabe cómo resolverlos (y para los cuales se puede reusar código ya hecho).
A partir de aquí, se trabaja hacia arriba (uniendo trozos/bloques) en busca
de una solución para el problema complejo inicial. Informalmente se podría
decir que es un enfoque estilo LEGO®: tengo pequeñas piezas –por ejemplo,
ladrillos– que unidas crean un objeto mayor, por ejemplo, una casa. Dicho de
otra forma, este enfoque consistiría en empezar por los subproblemas de más
bajo nivel e ir subiendo hasta llegar al problema inicial.
En este punto, si decimos que el problema complejo inicial es el programa,

podemos también decir que un subproblema es un subprograma. A estos sub-
programas se les suele llamar módulos, de ahí que en ocasiones también se
utilice el nombre de programación�modular para referirse a la programación
estructurada.
Un módulo se puede definir como una colección de constantes, varia-

bles, funciones y acciones (es decir, funciones que no devuelven nada)
relacionadas entre sí que están agrupadas en un mismo fichero.
Como se puede ver en la figura siguiente, tras descomponer el problema en

subproblemas (módulos), se obtiene una estructura piramidal o jerárquica
donde los módulos de los niveles superiores se encargan de las tareas de coor-
dinación, lógica de la aplicación y manipulación de los módulos inferiores.
Por su parte, los módulos inferiores realizan tareas de cálculo, tratamiento y
entrada/salida de información. Es decir, los módulos superiores realizan tareas
más generales/globales, mientras que los módulos inferiores se encargan de
tareas más concretas.
Diagrama jerárquico incompleto que muestra posibles módulos (o subprogramas) del

videojuego (o programa) Arkanoid.
El número de módulos que tiene un programa y cómo se estructuran cada

uno de ellos depende del programador. Lo único que se debe tener en cuenta
es que cada módulo debe cumplir una funcionalidad del programa. Así pues,
si nuestro programa es un videojuego como el que se muestra en la figura
anterior, un módulo se podría encargar de cargar y guardar partidas; otro de

todas las gestiones relacionadas con el pintado de la interfaz gráfica; otro de
controlar la física de los objetos del juego, etc. Los diferentes módulos pueden
interactuar entre sí. Por ejemplo, el módulo de física dirá al módulo de pintado
dónde dibujar una pelota que sigue un movimiento rectilíneo.
El paradigma de programación estructurada, con independencia del enfoque

(top-down o bottom-up), tiene las siguientes ventajas respecto de no seguir nin-
gún paradigma concreto:
• La�programación�es�más�sencilla, ya que se puede aplazar el desarrollo

de algunas tareas en beneficio del problema global.
• Facilita�el�trabajo�en�grupo. Varios programadores pueden tratar el pro-

blema complejo inicial encargándose cada uno de ellos de un módulo con-
creto.
• El�mantenimiento�es�más�sencillo de realizar, ya que se pueden modifi-

car segmentos de código (esto es, subprogramas/módulos) de manera in-
dependiente, sin que para ello se tenga que tocar el resto del programa.
• La�reutilización�de�código�ya�escrito�es�más�fácil tanto en el propio pro-

grama como en otros gracias a la organización basada en módulos. Ideal-
mente cada módulo debería poder ser usado en cualquier programa. In-
formalmente hablando, diríamos que un módulo debería ser un elemento
plug and play.
• Aumenta�la�legibilidad�del�código. Es mejor tener el código organiza-

do/repartido en diferentes módulos que siguen una cierta lógica, que tener
un único módulo con miles de líneas de código.
Normalmente, cuando se aborda un problema siguiendo el paradigma de pro-

gramación estructurada, se suelen combinar el enfoque top-down con el en-
foque bottom-up, aunque el enfoque top-down tiene predominancia. Algunos
motivos por los que se combinan ambos enfoques son:
1) Si el problema, además de complejo, es nuevo para el programador, suele

ser más sencillo pensar de manera descendiente (top-down).
2) Si durante el descenso se detecta algún módulo que ya se tiene hecho de

otro programa anterior (por ejemplo, guardar y cargar partidas), se puede tratar
de aprovechar (es decir, reutilizar) y, en consecuencia, adaptar los módulos
superiores para que hagan uso de él.
3) Si se sigue exclusivamente un diseño descendiente (top-down), las funciones

de más bajo nivel desarrolladas son muy dependientes del problema que pre-
tenden resolver, y difícilmente pueden ser aprovechadas para otros programas.
4) Si se ha seguido exclusivamente un diseño descendiente (top-down) y en el

futuro hay cambios funcionales en el programa, este se ve muy afectado por
estos cambios, pudiendo obligar a reescribir buena parte del programa.
Independientemente de cuál sea el enfoque predominante –top-down o bot- Enfoque bottom-up

tom-up–, el grado de éxito que podemos tener al seguir el paradigma de progra-
Como vemos, el enfoque top-
mación estructurada es directamente proporcional a la capacidad de abstrac- down tiene más inconvenientes
ción que seamos capaces de aplicar al problema complejo al que nos enfren- que ventajas, por eso la pro-
gramación orientada a objetos
tamos. Nuestra capacidad de abstracción nos permite reconocer los diferentes sigue un enfoque bottom-up,
como ya veremos.
subproblemas del problema complejo inicial y dividirlos (enfonque top-down)
y/o juntarlos (enfoque bottom-up) según sea necesario.
Enlace de interés
Todo lo comentado hasta ahora os debería ser familiar, puesto que en la asig-
Para entender mejor el con-
natura de programación anterior implementasteis programas siguiendo el pa- cepto de abstracción, se re-
comienda leer el aparta-
radigma de programación estructurada y, más concretamente, siguiendo un do «Create by abstracting»
enfoque descendiente (top-down). Si no os acordáis, contestad a estas pregun- del siguiente artículo web:
http://worrydream.com/
tas: LearnableProgramming/
• ¿He�usado�módulos? Sí. Cuando escribías un programa en C o PHP orga-

nizabas el código en ficheros con extensión .c o .php que contenían varia-
bles y funciones.
• ¿He�seguido�un�enfoque�descendiente�(top-down)? Sí. Además de mó-

dulos, cuando escribías una función A y esta hacía muchas tareas, la sub-
dividías en funciones más sencillas que llamabas desde la función A.
• ¿He�aplicado�abstracción? Sí. En cada nivel de descomposición, has sido

capaz de considerar solo aquellos aspectos necesarios para analizar el pro-
blema y tomar decisiones. Por ejemplo, decidías sobre cuestiones como: en
cuántos módulos dividías el programa, qué hacía cada módulo, qué fun-
ciones implementabas en cada módulo, qué cabecera tenía cada función,
qué variables necesitabas, etc.
Todos estos conceptos –abstracción, modulación, reutilización, etc.–

son necesarios tenerlos bien asimilados antes de empezar esta asignatu-
ra, puesto que la programación orientada a objetos no solo los utiliza,
sino que los potencia y, además, añade nuevos elementos.
2. Y llegó la programación orientada a objetos
Los lenguajes de programación, por lo general, están ligados (o favorecen) a

un paradigma de programación. De este modo, el lenguaje C está claramente
alineado con la programación estructurada.
Si bien la programación estructurada es útil, la complejidad que han ido ad-

quiriendo los programas a lo largo de los años ha obligado a pensar nuevos
paradigmas. Así es como en los años ochenta nació un nuevo paradigma lla-
mado programación�orientada�a�objetos�(o�POO).
Si retomamos el paradigma que ya conocemos –la programación estructura-

da–, nos daremos cuenta de que para un programador que quiera usar un mó-
dulo que no ha programado él, no es tan importante saber cómo está imple-
mentado dicho módulo como saber qué es lo que puede hacer con él y cómo
debe utilizarlo. Así pues, al programador le interesa saber qué funciones puede
usar, qué hacen, cómo se usan y qué devuelven. Por el contrario, no le interesa
saber si el programador que hizo el módulo al escribir una función ha utilizado
una serie de sentencias if o ha preferido usar un switch, o ha usado un while
en vez de un for.
Siguiendo con el mismo razonamiento, muchos módulos incluyen variables

globales que pueden ser usadas por otros módulos, o bien accediendo a ellas
directamente, o bien a través de funciones proporcionadas por el módulo que
las declara. Al comienzo de los ochenta, se popularizó la segunda forma de
trabajar, es decir, los módulos de un programa no accedían directamente a las
variables de otro módulo, sino que lo hacían a través de funciones proporcio-
nadas por el módulo que contenía las variables a usar. Esto tiene una serie de
ventajas respecto de acceder directamente, como por ejemplo:
• Se asegura la consistencia de la variable. Por ejemplo, si una variable es

un array, al usar una función para acceder a él, será dicha función quien
compruebe si el índice al que se desea acceder (pasado por parámetros) es
correcto o no. Además, se garantiza que todos los accesos al array hechos
a través de la función se harán de igual manera y se harán las mismas
comprobaciones.
• Se exime�de�responsabilidades al programador que utiliza el módulo, ya

que al utilizar las funciones proporcionadas, la responsabilidad recae en
quien o quienes las han programado.
• Facilidad� de� mantenimiento. Si se cambia el tipo de variable o existe

algún error en una de las funciones proporcionadas por el módulo, solo
hay que cambiar el código del módulo que la contiene. De este modo,
los cambios se ven reflejados automáticamente en otros módulos que la

utilicen.
Como se puede apreciar, poco a poco surgió la tendencia de ir ocultando in- Ved también
formación acerca de la implementación de los módulos. O dicho de otro mo-
El concepto de encapsulación
do, de hacer de un módulo una caja negra de la cual se supiera lo mínimo. se trata en el módulo «Encap-
Este hábito de ocultar información y controlar el acceso a ella –especialmente sulación y extensión» de esta
asignatura.
datos, es decir, variables– está íntimamente relacionado con el concepto de
encapsulación.
Dadas las ventajas, los programadores tenían cada vez más interés en poder
escribir módulos que facilitaran la encapsulación; así es como surgieron nue-
vos lenguajes (por ejemplo, C++) que daban soporte a esta técnica y a nuevos
paradigmas de programación más adecuados. De esta forma surgió el paradig-
ma de la programación orientada a objetos (POO).
3. De la programación estructurada a la
programación orientada a objetos
3.1. Introducción a los conceptos básicos de la programación

orientada a objetos
A nivel muy introductorio –ya veremos todo con más detalle a lo largo de
la asignatura–, cabe destacar que el elemento principal de la programación
orientada a objetos (POO) es el objeto. La POO modela la funcionalidad de un
sistema (es decir, del problema a resolver) intentando asemejarse lo máximo
posible a la realidad. El modo en que intenta imitar la realidad es definiendo
un conjunto de objetos que interactúan entre sí enviándose y respondiendo
a mensajes. Gracias a la colaboración entre objetos, el programa es capaz de
realizar la funcionalidad esperada (o de resolver el problema planteado).
De igual modo que en el lenguaje C hay el tipo integer (int, entero), character
(char, carácter), etc. para definir una variable, en los lenguajes que soportan la
POO el tipo de los objetos es una clase. Una clase se asemejaría a lo que en
programación estructurada llamamos módulo, puesto que una clase contiene
datos (en forma de variables) y funciones. A los datos (variables) de una clase
se les suele llamar atributos, mientras que a sus funciones se les suele llamar
métodos. De igual modo, tanto a los atributos como a los métodos se les suele
llamar miembros�de�una�clase.
Así pues, cuando definimos un objeto tenemos que indicar su tipo. Este no será
ni un int, ni un char, sino una clase. De hecho, muchas veces a los objetos se les
llama instancias de una clase o, simplemente, instancias (del inglés, instance),
aunque su correcta traducción al español debería ser ‘ejemplo/caso’. Por lo
tanto, un objeto sería un ejemplo/caso particular de una clase. Es importante
entender que podemos tener tantos objetos/instancias como queramos de una
misma clase.
Como hemos dicho, las clases –que definen el tipo de los objetos– tendrán
que modelar la realidad del problema que estamos tratando, lo cual nos obliga
a definir las clases siguiendo una estrategia totalmente diferente a la que se-
guimos cuando definimos módulos en la programación estructurada. Si en la
programación estructurada los módulos los definíamos siguiendo un criterio,
más o menos lógico, como agrupar funciones que traten una misma tarea (por
ejemplo, pintado, control de reglas, control de físicas, etc.), en la POO esta
estrategia no nos servirá (del todo).
A continuación, veamos un ejemplo sencillo que nos permita entender los

conceptos que han ido apareciendo.
Elena, Marina y David son objetos/instancias (ejemplos/casos) de la clase�Persona. Una

Ved también
Persona tiene unos datos y unas funciones/comportamientos, es decir, unos atributos y
unos métodos. Ejemplos de atributos que todas las personas compartimos son: nombre,
apellido, fecha de nacimiento, lugar de nacimiento, género, raza, peso y altura. Mientras Para terminar de entender los
que ejemplos de métodos que compartimos todas las personas pueden ser: hablar, escu- conceptos básicos de la POO,
se recomienda ver el vídeo
char, andar, comer, aumentar la altura, aumentar el peso y reducir el peso, entre otros.
«Clase, objeto, atributo y mé-
todo» que encontraréis en el
Una vez sabemos que Elena, Marina y David son objetos de Persona, es fácil intuir que aula de la asignatura.
cada uno de ellos tendrá unos valores diferentes para los atributos de la clase Persona
y harán ciertas acciones (métodos) de una forma distinta, aunque se llamen igual. Por
ejemplo, el valor del atributo nombre de la clase Persona ya es diferente para cada uno
de los tres objetos, puesto que un objeto tiene el valor Elena, otro Marina y otro David.
Asimismo, mientras que el valor del atributo género para David es hombre, para Elena y
Marina el valor es mujer.
Si Marina es un bebé de trece meses, es fácil imaginar que los valores para los atributos
altura y peso no pueden ser iguales a los de los adultos Elena y David y, que a su vez, los
valores de estos atributos serán distintos entre Elena y David. Del mismo modo, la forma
de hablar de Marina será muy distinta a la de Elena y David, puesto que aún no tiene
vocabulario suficiente para expresarse.
Por otro lado, si imaginamos que David es el padre de Marina, este podría pedirle a Marina
que comiera enviándole el mensaje «Marina come» (es decir, llamando al método comer de
Marina). A su vez, Marina podría responderle o bien comiendo (por ejemplo, devolviendo
su método comer un true o un 1) o bien negándose a ello (por ejemplo, devolviendo
un false o 0). De esta manera, vemos cómo interactúan (se comunican o colaboran) los
diferentes objetos.
De manera simplificada y visual, podemos ver este ejemplo en la figura siguiente.
En la clase hemos indicado el tipo simple/básico (entero, cadena de caracteres, booleano,

etc.) de los atributos, mientras que los métodos los hemos distinguido abriendo y cerran-
do paréntesis al lado de su nombre. En el caso de los objetos, ponemos el valor que tiene
cada atributo.
3.2. Dado un problema real, ¿cuál es el proceso a seguir?
La programación orientada a objetos (POO) intenta modelar el mundo real (o

el problema real que queremos resolver) sobre la base de dos elementos: los
objetos y las clases.
El diseñador del programa sigue un proceso de abstracción en el que, a partir de

elementos concretos (los objetos), intenta generalizar hasta llegar a diferentes
plantillas (las clases). Concretamente, el proceso que suele seguir es:
1)� Identificar� los� objetos que interactúan en el problema. Dado un tex-

to/enunciado del problema, los objetos suelen ser sustantivos o sintagmas no-
minales.
En el ejemplo del subapartado 3.1, hemos identificado Elena, Marina y David como ob-
jetos.
2) Analizar los objetos identificados con el objetivo de reconocer�sus�carac-

terísticas�y�acciones/funcionalidades. Dado un texto/enunciado, las carac-
terísticas se corresponden con sustantivos o sintagmas nominales, mientras
que las acciones se suelen corresponder con verbos o sintagmas verbales. Co-
mo veremos más adelante, las características pasarán a llamarse atributos y las
acciones se llamarán métodos.
En el ejemplo del subapartado 3.1, hemos identificado nombre y edad como atributos,
mientras que andar, hablar y comer eran los métodos.
3)�Identificar�las�clases que agrupan a los diferentes objetos. Cada clase ten-

drá las características y acciones/funcionalidades comunes de los objetos que
representa. Dado un texto/enunciado, las clases, si aparecen, suelen ser sus-
tantivos o sintagmas nominales. Si no aparecen, debemos asignarle un nom-
bre inventado por nosotros que tenga una cierta lógica.
En el ejemplo del subapartado 3.1, hemos identificado una única clase llamada Persona.
4) Asignar cada objeto a una clase.
En el ejemplo del subapartado 3.1, hemos identificado que los objetos Elena, Marina y
David compartían atributos y métodos y que, por consiguiente, pertenecían a la misma
clase, en este caso, la clase Persona.
Como podemos ver, el proceso seguido se basa en un enfoque bottom-up, pues-

to que vamos desde lo más concreto o bajo nivel (los objetos) hasta lo más
general o alto nivel (las clases).
Finalmente, cabe tener presente que no todos los sustantivos y verbos del tex-
to/enunciado son objetos, atributos, métodos o clases. Pueden darse los si-
guientes casos:
• Redundancia�(o�sinónimos): un objeto/clase/atributo/método es deno-

minado de diferentes maneras dentro del texto. Es decir, aparecen dos o
más sustantivos/verbos para indicar el mismo elemento. En estos casos te-
nemos que quedarnos con una de las maneras de referirnos a ese elemento.
• Irrelevancia: puede darse que algún elemento que hemos identificado,

por lo que sea, tiene poco o nada que ver con el problema que queremos
solucionar. Es decir, no nos es útil para el problema/contexto en el que
estamos. Dicho de otro modo, nos es irrelevante.
• Roles: existen sustantivos y verbos que indican cuál es el papel de una cla-
se u objeto dentro del problema. A veces esta información es superflua y,
por lo tanto, la podemos descartar. En otras ocasiones, los roles se corres-

ponden con atributos, operaciones o relaciones que nos son importantes.
Si nos fijamos en el ejemplo del subapartado 3.1, podemos ver que hemos seguido el
proceso bottom-up que acabamos de explicar. Fijaros en que hemos ido de abajo (objetos:
Elena, Marina y David) hacia arriba (clase: Persona). Concretamente, primero hemos iden-
tificado tres objetos –Elena, Marina y David– y a partir de aquí hemos detectado que estos
tres objetos compartían una serie de atributos y métodos, lo cual nos estaba indicando
que Elena, Marina y David podrían tratarse del mismo tipo de objeto, es decir, que podrían
pertenecer a la misma clase. Esta clase la hemos llamado Persona.
Ved también
Esta identificación de los «elementos compartidos» requiere, por nues-
tra parte, ejercer un nivel de abstracción mayor del que solemos hacer Para terminar de entender el
concepto de abstracción y el
en el paradigma de programación estructurada. enfoque bottom-up, se reco-
mienda ver el vídeo «Abstrac-
ción y paradigma bottom-up»
que encontraréis en el aula de
Podíamos haber hecho una clase para Elena, otra para Marina y una tercera para David, la asignatura.
pero en vez de esto, hemos hecho un ejercicio de abstracción y hemos buscado elementos
comunes cuyo resultado ha sido una clase común llamada Persona.
Esta forma de pensar un programa nos ayuda a hacer un diseño mejor orga-
nizado, más reducido en cuanto a líneas de código y, por consiguiente, más
fácil de mantener y escalar.
A diferencia de la programación estructurada que se centra en las fun-

ciones, la POO se centra en la estructura de los datos (es decir, cómo
estos se organizan). Este cambio, aunque puede parecer sutil, es vital
que se comprenda y asimile para tener éxito con la POO.
4. Beneficios de la programación orientada a objetos
La POO ha traído nuevas ventajas o mejoras con respecto a la programación

estructurada. Algunas de ellas son:
• Mayor�facilidad para abordar problemas complejos:

– Naturalidad: el análisis y el diseño que dividen un dominio en cla-
ses/objetos están más acordes con la realidad que una descomposición
funcional (como hace la programación estructurada).
– Modularidad: gracias a la definición de clases, los objetos son auto-

contenidos y tienen definida de forma clara la manera de comunicarse
con otros objetos.
• Seguridad: la POO, mediante la encapsulación, permite controlar el acceso

a los atributos y métodos. De esta manera, la consistencia de los datos (o
sea, de los atributos) es mayor, puesto que se puede evitar que se accedan
directamente a ellos. Asimismo, en una clase, un método que realiza una
tarea compleja puede estar dividido en métodos auxiliares más sencillos
que no deben ser ni accedidos por otros objetos ni conocidos por alguien
que no sea el programador de la clase.
• Reutilización: las clases bien diseñadas pueden utilizarse como base de

otros programas. Para facilitar la reutilización, la POO ha definido princi-
palmente un mecanismo denominado herencia. La herencia permite bási-
camente dos cosas:
– Crear un módulo (mejor dicho, una clase) a partir de uno ya existen-
te, extendiendo así las funcionalidades del módulo reutilizado y sin
afectarlo.
– Definir y utilizar de forma clara clases funcionalmente incompletas,

pero que ayudan a definir el problema.
• Escalabilidad: la herencia y la naturaleza del paradigma en sí permiten

que el esfuerzo no aumente exponencialmente con el tamaño y la com-
plejidad del proyecto ni con un cambio de especificaciones.
• Comprensión: mejora la legibilidad del código con respecto a la progra-

mación estructurada. Al estar encapsulados los datos y procedimientos que
conforman los objetos en un mismo compartimento (esto es, la clase), los
objetos pueden ser desarrollados y probados de forma independiente. Asi-
mismo, al testear un objeto, se está testeando de paso su clase.
5. Enfrentarse a la programación orientada a objetos
En este apartado veremos los inconvenientes que la POO tiene para un pro-
gramador novel:
• Curva�de�aprendizaje�costosa: aprender el paradigma de POO y un len-

guaje orientado a objetos concreto es más complejo que aprender un len-
guaje imperativo tradicional basado en un paradigma de programación
estructurada.
• Cambio�de�enfoque: generalmente se aprende a programar siguiendo un

enfoque top-down –como ha sido vuestro caso–, pero la POO se basa en un
enfoque bottom-up. La POO se centra en los conceptos (abstracciones) del
dominio de la aplicación. La capacidad de abstracción de un programador
novel suele ser una de sus debilidades.
• Reutilizaciones�ineficientes: las clases en sí mismas no son reutilizables,

hay que programar pensando en la reutilización. Esto requiere dar un paso
más en vuestra capacidad de abstracción.
Todo esto se resume en que, desde este momento, debéis ser conscientes de que
esta asignatura os va a exigir muchas horas de dedicación delante del ordena-
dor, porque, como se suele decir: «A programar, se aprende programando».
Resumen
En este módulo hemos visto, en el apartado 1, el punto de partida una vez su-
perada la asignatura Fundamentos de programación o Programación, es decir,
el paradigma de programación estructurada. Hemos recordado en qué consiste
el enfoque descendiente (top-down) usado en la asignatura anterior y hemos
comentado brevemente el enfoque ascendiente (bottom-up), que será la base
de la programación orientada a objetos (POO).
Para hacer lo más natural y simple posible el paso del paradigma de programa-
ción estructurada top-down al paradigma de la programación orientada a obje-
tos (afín a un enfoque bottom-up), hemos visto, en el apartado 2, las necesida-
des que originaron la aparición de este segundo paradigma y, en el apartado
3, qué similitudes tienen o se pueden hacer de manera informal entre ambos
paradigmas. Esto nos ha permitido, por un lado, introducir conceptos y térmi-
nos utilizados en la POO –por ejemplo: objeto, clase, etc.–, y, por otro, conocer
el proceso de abstracción que debemos seguir a la hora de diseñar programas
basados en POO. A partir de aquí, en el apartado 4 hemos visto además, sin
entrar en demasiados detalles, los beneficios que presenta el paradigma de la
programación orientada a objetos.
Finalmente, en el aparado 5, como sois programadores noveles y en esta asig-

natura se plantea un enfoque (es decir, un paradigma de programación) total-
mente diferente al que estáis acostumbrados, hemos planteado una serie de
cuestiones que debéis tener en cuenta a la hora de cursar esta asignatura.
Bibliografía
Booch, G.; Maksimchuk, R.; Engle, M.; Conallen, J.; Houston, K. (2007). Object-Orien-
ted Analysis and Design with Applications. Pearson Education.
Joyanes, L. (1998). Programación orientada a objetos. Madrid: McGraw-Hill.
Meyer, B. (1999). Construcción de software orientado a objetos. Madrid: Prentice Hall.

Introducción Al Paradigma de La Programación Orientada A Objetos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Introducción Al Paradigma de La Programación Orientada A Objetos

Cargado por

Copyright:

Formatos disponibles

Introducción al

David García Solórzano

Tiempo mínimo de dedicación recomendado: 2 horas

1. Contexto: programación estructurada......................................... 7

2. Y llegó la programación orientada a objetos............................. 11

3. De la programación estructurada a la programación

4. Beneficios de la programación orientada a objetos................. 17

5. Enfrentarse a la programación orientada a objetos................. 18

Este módulo es introductorio y, por consiguiente, muchos de los conceptos

El objetivo principal de este módulo es contextualizar la asignatura. Concre-

1. Ser consciente del punto de partida tras haber cursado la asignatura de

2. Conocer el concepto de paradigma de programación, haciendo énfasis en la

3. Entender el razonamiento que se sigue al programar mediante el paradig-

4. Comprender de modo general los beneficios que nos aporta el paradigma

5. Ser conscientes de las dificultades a las que un programador novel, como

1. Contexto: programación estructurada

Después de cursar la primera de las asignaturas de programación –Fundamen-

Una definición más formal de paradigma de programación podría ser la

Así pues, un paradigma de programación determina la forma en que pensamos

En los años setenta, se empezó con un paradigma llamado programación�es-

1)�Top-down: para resolver un problema complejo, se descompone el proble-

Esto implica tener diferentes niveles de descomposición que van de lo general

En este punto, si decimos que el problema complejo inicial es el programa,

Un módulo se puede definir como una colección de constantes, varia-

Como se puede ver en la figura siguiente, tras descomponer el problema en

Diagrama jerárquico incompleto que muestra posibles módulos (o subprogramas) del

El número de módulos que tiene un programa y cómo se estructuran cada

anterior, un módulo se podría encargar de cargar y guardar partidas; otro de

El paradigma de programación estructurada, con independencia del enfoque

• La�programación�es�más�sencilla, ya que se puede aplazar el desarrollo

• Facilita�el�trabajo�en�grupo. Varios programadores pueden tratar el pro-

• El�mantenimiento�es�más�sencillo de realizar, ya que se pueden modifi-

• La�reutilización�de�código�ya�escrito�es�más�fácil tanto en el propio pro-

• Aumenta�la�legibilidad�del�código. Es mejor tener el código organiza-

Normalmente, cuando se aborda un problema siguiendo el paradigma de pro-

1) Si el problema, además de complejo, es nuevo para el programador, suele

2) Si durante el descenso se detecta algún módulo que ya se tiene hecho de

3) Si se sigue exclusivamente un diseño descendiente (top-down), las funciones

4) Si se ha seguido exclusivamente un diseño descendiente (top-down) y en el

Independientemente de cuál sea el enfoque predominante –top-down o bot- Enfoque bottom-up

• ¿He�usado�módulos? Sí. Cuando escribías un programa en C o PHP orga-

• ¿He�seguido�un�enfoque�descendiente�(top-down)? Sí. Además de mó-

• ¿He�aplicado�abstracción? Sí. En cada nivel de descomposición, has sido

Todos estos conceptos –abstracción, modulación, reutilización, etc.–

2. Y llegó la programación orientada a objetos

Los lenguajes de programación, por lo general, están ligados (o favorecen) a

Si bien la programación estructurada es útil, la complejidad que han ido ad-

Si retomamos el paradigma que ya conocemos –la programación estructura-

Siguiendo con el mismo razonamiento, muchos módulos incluyen variables

• Se asegura la consistencia de la variable. Por ejemplo, si una variable es

• Se exime�de�responsabilidades al programador que utiliza el módulo, ya

• Facilidad� de� mantenimiento. Si se cambia el tipo de variable o existe

los cambios se ven reflejados automáticamente en otros módulos que la

3.1. Introducción a los conceptos básicos de la programación

A continuación, veamos un ejemplo sencillo que nos permita entender los

Elena, Marina y David son objetos/instancias (ejemplos/casos) de la clase�Persona. Una

De manera simplificada y visual, podemos ver este ejemplo en la figura siguiente.

En la clase hemos indicado el tipo simple/básico (entero, cadena de caracteres, booleano,

3.2. Dado un problema real, ¿cuál es el proceso a seguir?

La programación orientada a objetos (POO) intenta modelar el mundo real (o

El diseñador del programa sigue un proceso de abstracción en el que, a partir de

1)� Identificar� los� objetos que interactúan en el problema. Dado un tex-

2) Analizar los objetos identificados con el objetivo de reconocer�sus�carac-