LA PROGRAMACION ORIENTADA A OBJETOS FRENTE A LA

PROGRAMACION ESTRUCTURADA
En el articulo se describe las caractersticas, ventajas y desventajas de la Programacin
Orientada a Objetos frente a la metodologa tradicional como lo es la Programacin
Estructurada para el desarrollo de software. Como tambin se ace una comparacin de dos
niveles! macroscpica y microscpica.
Carlos Alberto Vanegas

Introd!!"#n
Cuando ablamos de la crisis del software acemos nfasis en todos los inconvenientes "ue
se presentan en el proceso de desarrollo, en la calidad de los programas "ue se producen y
en los procesos de mantenimiento. Estos problemas an incidido directamente en el
incremento en los costos de construccin del software. El costo del mantenimiento
#correctivo y evolutivo$ pueden alcan%ar alrededor del &'( del costo total del producto.
)as posibles fuentes de estos problemas se deben buscar en el proceso mismo de
construccin de software y, en especial, en las metodologas utili%adas para tal fin.
El ciclo de vida del software esta dividido en tres etapas! *n+lisis, ,ise-o e
implementacin. En la etapa de an+lisis, estudiamos el problema y establecemos los
re"uerimientos "ue se desean satisfacer. En la etapa de dise-o se implanta una solucin al
problema. En la etapa de implementacin se desarrolla el software. despus "ue a estado
en uso, se reali%an cambios en los re"uerimientos o errores de funcionamiento. /amos a
centrarnos en la implementacin.
El factor central de la subetapa de dise-o es el modelaje del mundo en el "ue se presenta el
problema, lo "ue se logra es abstrayendo y copiando las caractersticas de sus elementos y
sus relaciones, lo mismo "ue el problema "ue desea resolver. Esta es, indudablemente la
etapa donde se determina las caractersticas estructurales de la solucin. ,e acuerdo con
esto, una metodologa de dise-o es una forma de lograr un modelo del mundo del
problema, un lenguaje de programacin es una sinta0is para implantar el modelo y un
es"uema de implantacin es una manera de traducir el modelo a un lenguaje de
programacin. E0isten mucos modelos validos para un mismo mundo, mucas maneras
de lograrlo, mucas sinta0is para e0presarlo y mucas maneras para acer la implantacin,
siendo todas perfectamente utili%ables. En consecuencia, el programador se debe plantear,
entre otras mucas las siguientes preguntas, 1ajo "ue criterios debe escoger una
metodologa de dise-o2, 3ue caractersticas del problema acen "ue una metodologa sea
m+s conveniente "ue otra2, etc..

4ngeniero de 5istemas 6niversidad 4ncca de Colombia, estudios de Especiali%acin en 4ngenieria de

5oftware 6niversidad ,istrital 7.8.C. .Profesor *dscrito a la 7acultad 9ecnolgica de la 6niversidad ,istrital
7.8.C.
/amos a reali%ar comparaciones de la Programacin Orientada a Objetos #POO$ con la
metodologa de Programacin Estructurada #PE$.

En la PE e0iste uniformidad en la terminologa y en los conceptos "ue se manejan la PE
debido al tiempo "ue an tenido para madurar y su gran difusin. Esto no sucede con la
POO en donde ay un gran problema grave de terminologa y una tendencia preocupante
acia la trivili%acin de todos los conceptos.
$% LA PROGRAMACION ORIENTADA A OBJETOS &POO'
El paradigma de la POO se basa en la idea "ue el mundo puede ser modelado como un
conjunto de objetos "ue interactuan entre s, de manera "ue programar se reduce a
identificar dicos objetos y copiar adecuadamente las caractersticas y comportamientos.
El objetivo central del dise-o es "ue todo elemento del mundo #objeto real$ corresponda
directamente a un objeto del mundo computacional #objeto formal$ "ue lo modele. El
proceso de programacin se puede resumir de la siguiente manera!
a. 4dentificar las clases de objetos y sus atributos.
b. 4dentificar y especificar sus operaciones
c. 4mplantar las clases de objetos
Cada uno de estos pasos corresponde a refinamientos progresivos, buscando cada ve% el
mejoramiento del modelaje "ue se est+ aciendo del mundo. Es muy usual tener "ue
regresar a pasos anteriores para mejorar alg:n aspecto del dise-o. )a POO se basa en
cuatro conceptos b+sicos! Objetos, Clases, mtodos y erencia.
Ob(eto! Cada elemento del mundo involucrado en el problema debe tener una adecuada
representacin dentro de un programa. 6n objeto es la representacin de un elemento del
mundo real #muco mas "ue un dato, muco mas "ue un simple conjunto de variables con
un conjunto de procedimientos asociados$. Para acer esto debemos copiar todas las
caractersticas observables e interesantes #para el problema$ del objeto como tambin su
comportamiento. 6n objeto esta compuesto por un conjunto de atributos #objetos m+s
simples$ "ue mantienen el estado actual del objeto y un conjunto de mtodos "ue representa
su comportamiento, es decir, la forma de reaccionar a los diversos estmulos "ue se le
pueden presentar. Cada objeto reconoce y puede responder a determinadas acciones
denominadas eventos. 6n evento es una actividad especifica y predeterminada, iniciada por
el usuario o por el sistema.
Clase! 5i programar utili%ando el enfo"ue orientado por objetos consistiera en modelar
individualmente todos y cada uno de los elementos del mundo real involucrados en el
problema, la tarea sera realmente pesada y larga. 5e deben tratar entonces de no
concentrarse en describir elementos individuales, si no de encontrar patrones de objetos
"ue, por sus caractersticas comunes, puedan ser representados de una manera similar. Cada
uno de estos patrones se denomina una clase. )as clases son los pa"uetes principales de la
programacin orientada a objetos. )as clases y los objetos est+n estrecamente
relacionados, pero no son lo mismo, una clase contiene informacin sobre el cu+l debe ser
la apariencia y el comportamiento de un objeto. 6na clase es el plano o es"uema de un
objeto. Por ejemplo, el es"uema elctrico y de dise-o de un telfono seria similar a una
clase. El objeto, o una instancia de la clase, seria el telfono.
)a estructuracin de una clase en un lenguaje de programacin orientada a objetos seria!
class ;ombre<de<la<clase
=
atributos. >> encapsulamiento de los datos
metodos#$. >> comportamientos del objeto
?
M)todo! El comportamiento de los objetos de una clase se representa a travs de mtodos.
Estos le indican la manera de reaccionar a los diversos estmulos "ue le pueden llegar. )a
interaccin entre los objetos del sistema se ace por medio de mensajes! 6n objeto enva a
otro un mensaje a manera de estmulo para obtener de ste una respuesta. El receptor del
mensaje decide cual de sus mtodos debe activar para responder. 6n mtodo es una
secuencia de mensajes a otros objetos m+s simples #en la mayora de los casos a sus
atributos$ para simular la reaccin a un mensaje #encontrar la forma de resolverlo$.
*eren!"a! Es un mecanismo por el cual se puede aprovecar el dise-o de clases ya
e0istente para definir nuevas clases, ya sea especiali%ando sus caractersticas y
comportamiento #erencia sencilla$, o aciendo una composicin de varias de ellas
#erencia m:ltiple$, en la cual la clase resultante corresponde a la suma de todas las clases.
)a reutili%acin de cdigo aorra tiempo en el desarrollo de software.
)a metodologa sugerida por la POO se puede resumir muy brevemente de la siguiente
manera!
a. Ident"+"!ar las !lases de ob(etos , ss atr"btos! Para reali%ar este proceso el
programador debe identificar, como primera medida, los objetos directamente
involucrados en el problema. Para cada uno de estos objetos debe decidir el conjunto de
caractersticas importantes para el problema #sus atributos$. Esto produce un conjunto
de objetos del mundo real, con todos sus atributos modelados, en trminos de objetos
m+s simples.
b. Ident"+"!ar , es-e!"+"!ar ss o-era!"ones! Cada objeto formal debe tener suficientes
mtodos para "ue cual"uier transformacin imaginable en el mundo real sobre el
elemento "ue se modela sea e0presable en trminos de las operaciones incluidas en el
dise-o y, por lo tanto, sea simulable en el mundo formal #6n conjunto completo de
operaciones$. @ientras no se llegue a este estado es necesario incluir nuevas
operaciones en la clase del objeto.
c. I.-lantar las !lases de ob(etos! E0isten tres opciones b+sicas para acer la
implantacin. )a primera es utili%ar lenguajes Orientados por Objetos puros como
5malltalA o Eiffel, en los cuales no es necesario tener un es"uema de implantacin. )a
segunda opcin es utili%ar lenguajes orientados por Objetos Bbridos como Object
Pascal o CCC, para los cuales es necesario establecer un es"uema de implantacin "ue
no resulta muy complicado y "ue depende de la calidad de la e0tensin eca a los
lenguajes originales para manejo de Objetos. )a tercera opcin es utili%ar lenguajes
imperativos tradicionales como C y Pascal.
/% PROGRAMACI0N ESTRUCTURADA
)a metodologa de la programacin Estructurada est+ basada en la idea "ue se re"uiere para
resolver un problema y no el mundo en el cual ste ocurre. El modelo representa una
solucin al problema y corresponde a un conjunto de procesos jer+r"uicos conectados por
medio de flujos de datos, el cual se logra utili%ando la tcnica de refinamiento a pasos para
descomponer las funciones del sistema. 6n proceso o modulo es una serie de instrucciones
"ue puede ser invocada por su nombre y se encarga de transformar los datos de entrada en
datos de salida. )a jerar"ua entre los procesos significa "ue la funcin "ue reali%a un
modulo o el problema "ue se resuelva, puede ser descompuesto en varios subprocesos
donde cada uno resuelve un subproblema del problema final. )a definicin de los flujos de
datos "ue intervienen en el modelo es lo "ue se llama diccionario de datos.
Podemos es"uemati%ar este proceso de construccin del modelo en los siguientes pasos!
a. 7ormali%ar los resultados del an+lisis
b. 4dentificar los mdulos
c. Elaborar el diccionario de datos
d. Especificar los mdulos
e. 4mplantar los mdulos
/amos a mostrar de manera general cada uno de ellos!
a. For.al"1ar los resltados del an2l"s"s! Para obtener mejores resultados y para
facilitar la aplicacin de la metodologa, se presupone "ue se a usado an+lisis
estructurado para identificar y anali%ar el problema. En este paso se elaboran los
diagramas de flujo de datos "ue muestren como fluye la informacin entre los
diferentes procesos. 5e crea un diccionario de datos preliminar y se describen las
funciones "ue reali%an los procesos.
b. Ident"+"!ar los .#dlos! )os diagramas de flujo de datos se definen por
descomposicin, esto es, se parte de un diagrama de conte0to en donde se define el
sistema como una caja negra comunicada con el medio e0terior por medio de datos de
entrada y de salida. * medida "ue avan%a el dise-o, este diagrama de conte0to se
descompone en niveles en donde la gran caja negra se subdivide en subprocesos
conectados por datos. * partir de estos diagramas se define una estructura arborescente
de mdulos tratando de descomponer cada modulo en mdulos de entrada, un modulo
de transformacin y un modulo de salida.
c. Elaborar el d"!!"onar"o de datos! El diccionario de datos se debe actuali%ar para el
proceso de descomposicin modular. Cada uno de los flujos de datos se ace por
medio de una e0presin regular donde las cadenas terminales son los elementos de
informacin.
d. Es-e!"+"!ar los .#dlos! Para cada uno de los mdulos identificados se debe reali%ar
especificaciones en trminos de los datos de entrada "ue recibe y de los datos de salida
"ue produce. E0isten varias maneras para acer estas especificaciones de mdulos.
*lgunos se deben de acer utili%ando el espa-ol estructurado o seudocdigo, en donde
se origina un macroalgoritmo del proceso "ue soluciona el modulo. Otra manera es
utili%ar el *da o Prolog como lenguaje de especificacin.
e. I.-lantar los M#dlos! )a implantacin se reduce a acer la codificacin en un
lenguaje de programacin #de preferencia procedimental y estructurada$, donde a cada
modulo corresponde un procedimiento escrito en tal lenguaje. Es un proceso muy
simple la cual nos da la visin de datos pasivos y procesos de modificacin sobre stos
es muy natural usar lenguajes imperativos. Por otro lado se definen formalmente las
bases de datos a partir del diccionario de datos.
3% COMPARACI0N DE LA POO CON LA PE
/amos a acer la comparacin de dos niveles. 6n primer nivel en el cual se muestra de
manera macroscpica las ventajas y desventajas de la POO con respecto a la programacin
estructurada y un segundo nivel en el "ue se discuten aspectos puntuales de la POO "ue a
primera vista pueden parecer especialmente fuertes o especialmente dbiles con respecto a
la PE.
3%$ NIVEL MACRO
)as caractersticas propias de las dos metodologas permiten destacar "ue la escogencia de
una de las dos opciones representa un compromiso! 7acilidad en el dise-o o facilidad de
mantenimiento.
El proceso de dise-o en POO re"uiere un mayor esfuer%o "ue el "ue se re"uiere en la
PE, ya "ue es muco m+s difuso y fr+gil debido a la ausencia de una gua salida como
es el mismo problema "ue se re"uiere resolver para el caso de la PE. *dem+s el eco
de buscar tanta generalidad #Clases completas$e0ige indudablemente un trabajo
adicional.
El proceso de mantenimiento en POO resulta, en el caso tpico, m+s simple "ue en la
PE. 5i la evolucin corresponde a cambios en el problema #como ocurre en la mayora
de los casos, ya "ue las funciones son el componente m+s variable dentro de un sistema$
es muy inconveniente "ue la estructura del modelo dependa directamente del problema,
por"ue su mantenimiento podra implicar cambios en la ar"uitectura misma de la
solucin y esto puede resultar difcil y costoso. 5i la evolucin es debida a alteraciones
en el mundo, en POO los cambios son f+cilmente locali%ables en el modelo puesto "ue
e0iste una clara correspondencia entre este y el mundo. )a dificultad para acer los
cambios depende b+sicamente del tama-o de estos. En la PE el principal problema es
locali%ar los puntos del modelo donde se deben de acer las modificaciones y los
posibles efectos laterales "ue esto puede implicar #no e0iste encapsulamiento$. 6na
caracterstica del mundo puede encontrarse repartida por todo el modelo y comunicada
por medio de los flujos de datos por m:ltiples mdulos, todos los cuales es necesario
actuali%ar.
* mi modo de ver la POO tiene dos grandes ventajas sobre la PE. )a primera es "ue el
proceso de dise-o es muco m+s f+cil de apoyar mediante erramientas y guas "ue el
proceso de mantenimiento, y solo es cuestin de tiempo tenerlas en el mercado. En la PE
se an eco todos los esfuer%os imaginables para apoyar la labor de mantenimiento sin
lograr resultados satisfactorios. Esto no debera de sorprender a nadie, ya "ue por la misma
ar"uitectura del modelo y por la imposibilidad de prever en la fase de dise-o su posible
evolucin es muy difcil trabajar en metodologas generales de soporte para el proceso de
mantenimiento. )a segunda ventaja es "ue, debido a las facilidades de reutili%acin de
dise-os y de software "ue permite la POO, el costo en tiempo y recursos no resulta, en el
caso tpico, m+s alto "ue el logrado utili%ado ,E. Para mucas aplicaciones resulta m+s
econmico utili%ar POO "ue PE.
)a decisin "ue a primera vista puede resultar favorable a la POO no es tan clara si se
piensa con un poco de detenimiento! la teora y la practica no siempre est+n de acuerdo. ;o
e0isten suficientes erramientas no son tan poderosas como las "ue tiene la PE. ;o ay
personal capacitado en POO y esta labor de aprendi%aje no parece nada trivial. )os
)enguajes Orientados por Objetos no se encuentran tan difundibles como los lenguajes
imperativos, lo cual podra dificultar la portabilidad. ;adie garanti%a, a pesar de la gran
cantidad de profetas, "ue alg:n da la POO ser+ una metodologa slida, apoyada y
completa.
3%/ NIVEL MICRO
/amos a comparar aora las dos metodologas a un nivel mas detallado, teniendo en cuenta
algunas caractersticas de su utili%acin y la manera de integrar ciertos aspectos al modelo
"ue maneja.
So+t4are "ntera!t"5o! )a interfa% es la parte de un programa en cargada de la
comunicacin con el usuario. Para facilitar su dise-o y posterior mantenimiento, debe
e0istir una clara divisin entre la interfa% y el resto del programa. 5i tenemos en cuenta "ue
dentro del cdigo de un programa la interfa% puede llegar a constituir cerca de la mitad del
mismo #D'($, podemos concluir "ue una buena metodologa debe incluir una forma de
dise-ar la interfa% y contemplar una manera de integrarla #sin me%clarla$ con el resto del
programa. ;inguna de las dos metodologas contempla este problema. En algunas
e0tensiones recientes la PE incluye un mtodo adicional para dise-ar sistemas interactivos.
,e las dos metodologas, la PE es la "ue menos problemas presenta a este respecto puesto
"ue la interfa% se puede incluir sin dificultades en el modelo ya "ue ace parte del problema
"ue se "uiere resolver, aun"ue no es clara la forma de integrarla al modelo sin necesidad de
me%clar. El problema con la POO es "ue el mundo del usuario #la pantalla, el teclado, el
ratn, las ventanas, etc.$ no ace parte del mundo del problema #no corresponde a
elementos del mundo real "ue se est+ modelando$ y, por esta ra%n, no es claro como debe
incluirse la interfa% dentro del software, ni cmo debe modelarse la comunicacin con el
usuario. 9odos los elementos del mundo del usuario resultan e0tra-os dentro del mundo
formal, luego no ay manera de establecer una relacin entre ellos y los objetos formales
#por lo menos no de manera natural al modelo$. En POO la solucin puede ser de dos tipos!
,ejar "ue los objetos "ue modelan elementos del mundo real interactuen con el usuario #es
muy inconveniente para efectos de mantenimiento$ o aumentar el modelo de tal manera "ue
e0istan modelos "ue modelen el mundo del usuario "ue se comuni"uen con los objetos del
mundo real mediante mecanismos est+ndares de mensajes. Es una lastima "ue la parte de la
interfa% est tan descuidada en las dos metodologas por "ue en la actualidad la mayora de
sistemas se basan en una buena y amigable comunicacin con el usuario y esto implica
costos adicionales en el dise-o, en la implantacin y en el mantenimiento.
Me.or"a Se!ndar"a! El dise-o de un programa debe incluir la manera de almacenar y
mantener la informacin mediante el uso de arcivos en memoria secundaria o de un
sistema de base de datos. 6na metodologa debe guiar este proceso de dise-o, lo mismo "ue
incluir dentro del modelo el concepto de persistencia como una caracterstica adicional de
sus elementos. En la PE e0isten mtodos claros y muy bien estructurados para aprovecar
la informacin contenida en el diccionario de datos y dise-ar a partir de este los arcivos en
memoria secundaria y las bases de datos "ue dan soporte al sistema. En este aspecto es
ideal utili%ar esta metodologa! 5i el problema es una simple administracin de informacin
soportada por un sistema de arcivos, la PE es, sin ninguna duda la metodologa adecuada.
En POO el problema es un poco m+s complicado. El concepto de dato no ace parte del
modelo y por esta ra%n al utili%ar un sistema de arcivos de la manera tradicional, se est+
perdiendo el encapsulamiento de la informacin "ue, mediante un conjunto de mtodos,
asegura "ue la interpretacin "ue se ace de estos es la adecuada. Por esta ra%n, las mal
llamadas bases de datos orientadas por objetos, o son un enfo"ue orientados por objetos de
una base de datos corrientes #perfectamente utili%ables desde la PE, por ejemplo$ o son
bases de objetos, en las cuales no e0isten datos como tal sino modelos completos #con su
sem+ntica$ de elementos del mundo real. *ctualmente se utili%an en POO sistemas
corrientes de arcivos y de bases de datos, sin "ue aya muca claridad con respecto a su
integracin con el modelo y las consecuentes dificultades de mantenimiento.
D"se6o de +n!"ones! )as funciones del sistema son el conjunto de servicios "ue puede
prestar el programa al usuario #en el fondo corresponden al problema "ue se "uiere
resolver$. 5u dise-o y posterior inclusin en el modelo debe estar considerado en toda
metodologa. En la PE, donde el modelo se construye precisamente para resolver el
problema planteado por un conjunto especifico de funciones, no e0iste ning:n problema.
)a fase de an+lisis debe identificar claramente dicas funciones y la metodologa la utili%a
desde un comien%o para construir el modelo, bas+ndose en ella para obtener su ar"uitectura.
)a POO por su parte tiene algunos inconvenientes en este aspecto. ;o es claro como debe
de enfrentar el proceso de dise-o de funciones, ni en "ue parte del modelo se deben colocar.
*lgunos autores proponen colocar como parte del modelo algo llamado la funcin de
control "ue seria la encargada de EadministrarE el modelo, de acuerdo a las funciones "ue
debe tener, pero tiene dos problemas! el primero, es "ue no da guas sobre como dise-ar
esta funcin #puede resultar un problema tan complicado como el mismo modelaje del
mundo$, y el segundo es "ue no corresponde a ninguno de los elementos planteados dentro
del modelo de objetos #no es un mtodo$ luego abra "ue aumentar el modelo para incluir
la comunicacin entre la funcin de control y los objetos formales.
I.-lanta!"#n del s"ste.a! 6no de los aspectos fundamentales de una metodologa es "ue
el modelo "ue se logre en la fase de dise-o sea f+cilmente implantado. Para esto lo ideal es
"ue el modelo y el lenguaje de programacin se muevan dentro del mismo marco
conceptual, de manera "ue sea mnima la traduccin. 5i esto no ocurre, es necesario incluir
como parte del dise-o un es"uema de implantacin "ue indi"ue la manera de traducir cada
uno de los elementos del modelo al lenguaje de programacin escogido. esto va a
ocasionar, en menor o mayor grado, problemas de mantenimiento. En la PE el problema de
implantacin esta resuelto. )os lenguajes estructurados manejan los mismos elementos "ue
acen parte del modelo #modulosFprocedimientos, flujo de datosFparametros, etc.$, adem+s
de "ue la metodologa sugiere "ue las especificaciones de los mdulos sean tan completas
"ue la etapa de implantacin se redu%ca a una simple labor de codificacin. En la POO
e0isten G opciones para acer la implantacin del modelo. )enguajes orientados por objetos
puros, lenguajes bridos o lenguajes imperativos tradicionales. )as dificultades dependen
del tipo de lenguaje escogido. *l utili%ar un lenguaje puro, la traduccin es natural no es
necesaria la separacin entre las fases de dise-o e implementaron puesto "ue la lnea
divisora no e0iste, permitiendo "ue despus el mantenimiento se vuelva m+s sencillo. 5i se
escoge un lenguaje brido, todo depende de la calidad de la e0tensin del lenguaje
original, siendo CCC una de las m+s slidas "ue e0isten. 5e debe definir con cuidado un
es"uema de implantacin, pero no representa mayores dificultades. En el caso de usar
lenguajes tradicionales, "uedamos sin patrones, ni garantas, luego no es lo ideal.
Ret"l"1a!"#n del so+t4are! )a mejor manera de disminuir los costos de produccin de
software y de tiempo "ue se debe gastar para su desarrollo es reutili%ando programas
anteriores. )a programacin debera reducirse a conectar adecuadamente un conjunto de
elementos ya ecos y aprobados, en lugar de reinventar cada ve% algoritmos "ue se an
utili%ado siempre. En la PE cada modulo se desarrolla para satisfacer un problema muy
concreto, con una especificacin muy precisa dentro del conte0to definido por el problema
global. Esto ace "ue la reutili%acin del software no sea posible #por lo menos de una
manera natural$, ya "ue sera necesario "ue ocurriera e0actamente el mismo problema en
dos mdulos distintos. En la POO la reutili%acin del software resulta de alguna manera
natural. )os lenguajes Orientados a Objetos manejan polimorfismos, generecidad, alcance
din+mico, etc., lo cual permite con muca mayor facilidad el intercambio de pie%as
completas entre programas.
E7tend"b"l"dad! *ctualmente el software f+cil de mantener #e0tendible$ es una necesidad.
,ados los altos costos de los programas, es necesario asegurarles una larga vida :til. 5i
tenemos en cuenta "ue la evolucin de un sistema las acciones reali%adas tienden a ser la
parte m+s cambiable #vol+til$, parece muco m+s conveniente guiar la ar"uitectura del
modelo por la estructura del mundo y no por las funciones "ue reali%a. *dem+s, es mas
frecuente los errores en la fase de an+lisis "ue, aun"ue se piense en software poco
din+mico, el mismo ajuste inicial puede ser mas complicado. )o ideal es "ue pe"ue-os
cambios en la especificacin signifi"uen pe"ue-os cambios en el modelo y no una
reestructuracin del mismo.
Fa!"l"dades -ara desarrollo de -rotot"-os! )o ideal para poder crear prototipos de los
programas es tener ambientes y lenguajes cercanos al modelo. Esto permite acer
evaluacin a nivel de dise-o sin necesidad de esperar asta terminar la fase de
implantacin. En PE y POO e0isten erramientas "ue lo permiten#ambientes como Eiffel y
aun 5malltalA$. 5i para POO sumamos las facilidades de desarrollo de prototipos y las
facilidades de e0tendibilidad, obtenemos una metodologa "ue permite la creacin
incremental de software, algo muy deseado en la actualidad.
Co.-at"b"l"dad entre los .odelos! @ucas cosas se an dico sobre la compatibilidad de
los modelos obtenidos a partir de las dos metodologas, entendiendo compatibilidad como
la posibilidad de pasar del uno al otro mediante un proceso autom+tico de traduccin. Es
claro, por ejemplo, "ue en el modelo obtenido con PE se a perdido informacin sobre
ciertas caractersticas del mundo "ue son indispensables para construir el modelo de POO.
6n ejemplo pr+ctico seria!
Crear un programa "ue permita la iniciali%acin de dos y tres variables respectivamente.
F Ut"l"1ando la Progra.a!"#n Or"entada a Ob(etos
4mplementamos tres clases! 7igura, Punto y PuntoG,. ,esde la clase 7igura iniciali%aremos
las dos y tres variables. Heali%amos la Herencia de PuntoG, a Punto, esto con el fin de
usar la reutili%acin de cdigo "ue e0iste en la P.O.O.
En esta codificacin se utili%ara el constructor de Punto para iniciali%ar dos de las tres
variables de puntoG,. Esto nos aorra la escritura de cdigo y la repeticin de procesos "ue
ya e0isten.
I 6n constructor es a"uel "ue se iniciali%a autom+ticamente y lleva el mismo nombre de la
clase
class 7igura=
int aJG,bJK, cJL.
PuntoG, p.
Punto pM.
public void init#$ =
pJnew PuntoG,#a,b,c$.
pMJnew Punto#a,b$.
?
?
class PuntoG, e0tends Punto =
public int %.
>>iniciali%ar las variables utili%ando el constructor de punto
PuntoG,#int 0, int y$ =
super#0, y$. >>super llama al constructor de Punto
tis.% J '.
?
?
public class Punto =
public int 0.
public int y.
Punto #int 0M, int yM$ =
0 J 0M.
y J yM.
?
?
F Ut"l"1ando Progra.a!"#n Estr!trada
4mplementamos dos funciones! Punto y PuntoG,, adem+s creamos el programa principal y
por medio de las funciones enviamos las tres variables "ue vamos a iniciali%ar. Como se
puede apreciar nos toca crear dos funciones totalmente diferentes para poder iniciali%ar las
variables y por tanto la e0iste repeticin de cdigo. )a P.E. no permite la reutili%acin de
cdigo.
void PuntoG,#int 0M, int yM, int %M$ =
0 J 0M.
y J yM.
% J %M.
?
void Punto #int 0M, int yM$ =
0 J 0M.
y J yM.
?
void main#void$
=
int aJG, bJL, cJD.
PuntoG,#a,b,c$.
Punto#a,b$.
?
*un"ue aparentemente el programa reali%ado con P.O.O. tiene m+s lneas de cdigo,
imaginmonos "ue tocara repetir en un proceso una mil lneas, es a empe%aran los
problemas en serio.
REFERENCIAS BIBLIOGRAFICAS
*N64)*H, 8oyanes )uis. 7undamentos de Programacin, Ed. @c. Nraw Bill, Espa-a,
MOOL
,E49E), y ,eitel. Cmo Programar en 8ava, Ed. Prentice Ball, @e0ico, MOOD
@4CHO5O79, Corporation. @anual del Programador /isual 7o0pro, @icrosoft
Corporation, EE.66. , MOOD
PE;,*)), Pendall. *n+lisis y ,ise-o de sistemas, Ed. Prentice Ball, @0ico, MOOD