Por qu objetos?

Lic. Hernn A. Wilkinson

hwilkins@dc.uba.ar
Explicar por qu la tecnologa de objetos es la mejor para desarrollar software no es tarea
sencilla. Es una de esas cruzadas casi imposibles que desata las discusiones ms
apasionadas dentro del mbito profesional del desarrollo de sistemas y que llega a tocar los
sentimientos ms ntimos de sus profesionales. No basta con dar ejemplos de proyectos
exitosos desarrollados con esta tecnologa porque tambin soporta sobre su espalda
proyectos fracasados.
Podramos enumerar los motivos por los cules desarrollar software con objetos es
la mejor opcin tomando un libro del tema en cuestin y copiando su ndice, puesto que
todos conocemos hasta el cansancio las palabras que nos vendieron con esta tecnologa.
Por qu no reflotar esos tecnicismos que como, caballitos de batalla, se utilizan
constantemente? Por qu no decir que con los objetos tenemos reuso de cdigo, que
podemos utilizar herencia fcilmente, o que podemos crear mdulos por medio de clases?
Por qu no?
Porque hacerlo sera contribuir a la confusin general que existe en torno a esta
tecnologa, que an despus de tantos aos de vida no es conocida ni utilizada
correctamente1.
Les proponemos en este artculo tratar de entender qu significa desarrollar con
objetos, bajar un poco a tierra esta tecnologa viendo algunos errores que se cometen
comnmente con ella, desterrar algunos mitos creados alrededor de los objetos y por ltimo
responder la pregunta por qu objetos? y por qu no objetos?

1- Qu significa desarrollar con Objetos?

Para entender la tecnologa de objetos no queda otra opcin que empezar por el principio. Y
el principio en este caso es entender que trabajar con objetos es trabajar en un paradigma
completamente distinto al que estamos acostumbrados la mayora de nosotros y que casi
todas las universidades ensean (salvo contadas excepciones).
Un paradigma es un marco de referencia que impone reglas sobre cmo se deben
hacer las cosas, indica qu es vlido dentro del paradigma y qu est fuera de sus lmites.
Un paradigma distinto implica nuevas reglas, nuevos elementos, lmites y maneras de
pensar, implica un cambio, y todo cambio es difcil.
Definamos entonces como primer axioma que trabajar con objetos es trabajar con
un paradigma nuevo. Esto implica que debemos definir cules son las reglas de este nuevo
paradigma.
Muchos de ustedes, seguramente conocedores de C++, Java o el joven C#,
pensarn rpidamente las reglas son utilizar clases y herencia. Permtannos disentir
drsticamente con esto.
Objetos no tiene nada que ver con clases y herencia. Clases y herencia son
herramientas que nos dan ciertas implementaciones del paradigma (lenguajes) que mal
utilizadas pueden llegar a producir grandes desastres en el desarrollo de un sistema y que
luego se utilizan para justificar que los objetos no sirven, mejor seguir con COBOL o C
1

Grady Booch en su libro Object-Oriented Analysis and Design with Applications dice
estamos por 1994 y todava no conocemos bien que significa desarrollar con objetos

(desastres que tuve la triste experiencia de vivir pero que me dejaron importantes
enseanzas)
La primera regla del paradigma trata sobre qu se intenta obtener como resultado
del desarrollo de sistemas utilizando objetos. Esta es: Un sistema hecho con objetos es un
modelo computacional de una porcin de la realidad (la porcin que queremos
sistematizar, donominada dominio).
Las dos palabras estrella de esta definicin son modelo y realidad. Hay una
situacin de la realidad (por ejemplo facturar una venta) que debe ser modelada de tal
manera que pueda ser ejecutada por una computadora, obteniendo como mnimo el mismo
resultado que el proceso reemplazado por este nuevo sistema produca.
Durante el proceso de crear un modelo surgen las ventajas y desventajas de tener
buenas herramientas de modelizacin. En el paradigma de objetos la herramienta principal
de este proceso de modelizacin es justamente el objeto. Un objeto no es ms que una
representacin conceptual de algn elemento de la realidad.
En nuestro ejemplo del proceso de facturacin, un elemento de la realidad es la
factura, otro es la persona que realiza la factura y no menos importante el motivo por el
cual se est facturando: la venta.
En nuestro modelo por lo tanto, debemos representar estos elementos de la
realidad con objetos. Hay elementos fciles de reconocer puesto que son elementos fsicos
como la factura o la persona que factura (una persona que durante este proceso asume el
rol de facturador) y hay elementos ms difciles de ver puesto que son elementos
abstractos, ideas o acciones, como la venta en s misma, que tambin debe ser modelada
puesto que una factura es el resultado de haber realizado una venta.
Durante este proceso de modelizacin de la realidad que hacemos, no debemos
preocuparnos por cuestiones que no pertenecen a ella como la performance, la persistencia 2
u otros problemas o cuestiones de otra realidad, como la computacional.
Debe quedar claro que la performance, la persistencia y otros problemas
computacionales son ortogonales (no se colisionan) con la realidad que se est modelando y
que si se los incluye dentro del modelo original lo ensuciarn con problemas ajenos, que
harn de este modelo cualquier cosa, menos un modelo de la realidad.
Tenemos que ocuparnos de modelar bien la realidad de nuestro problema.
Tenemos que hacer un modelo en situaciones normales de presin y temperatura, despus
tendremos tiempo para preocuparnos por hacer que este modelo adems ejecute bajo los
requerimientos no funcionales especificados.
Entonces, si no debemos ocuparnos de la performance ni la persistencia, de qu
debemos ocuparnos cuando modelamos con objetos?. Debemos ocuparnos de las
responsabilidades de estos objetos, de qu hacen.
Pensemos en la responsabilidad de un facturador. Qu hace un facturador? Su
responsabilidad es facturar. La responsabilidad de una factura no ser ms que permitir
saber cul es su nmero, qu dicen las lneas que la componen o el total de la misma
(recuerden que una factura es simplemente un papel con datos impresos). La
responsabilidad de la venta ser indicar qu se vendi, a qu precio y a quin.
Cada vez que se agrega una responsabilidad a un objeto debemos estar seguros que
realmente corresponda a ese objeto. Por ejemplo, debe la factura tener cmo
responsabilidad imprimirse?. Pensemos en la realidad. Una factura no se imprime a s
misma, alguien se encarga de imprimirla, por lo tanto la factura no tiene la
2

Se denomina persistencia al proceso por el cual se graban y obtienen objetos de medios

persistentes (discos, cintas, etc. )

responsabilidad de imprimirse. Menos an de guardarse o de leerse de un archivo.

Estn son responsabilidades que le corresponden a otros objetos que tambin deben ser
modelados.
Podramos decir por ahora que desarrollar con objetos es modelar el problema que
tenemos que resolver utilizando objetos.
Sin embargo, esto no alcanza. La realidad tiene ciertas caractersticas interesantes
que debemos poder simular si queremos tener un buen modelo. Una de esas caractersticas
es la interaccin entre los elementos de la realidad. Por ejemplo, el gerente de contabilidad
le pide al facturador que facture y el facturador le indica a la factura a quin est dirigida.
Estos elementos colaboran entre s para llevar adelante el proceso de facturacin.
Esta interaccin se modela en el paradigma de objetos por medio de mensajes.
Los objetos se comunican entre s utilizando mensajes (que nada tienen que ver con
mails, mensajes de red, etc.) que representan la comunicacin o interaccin de elementos de
la realidad.
Como todo proceso de comunicacin hay un emisor y un receptor. Por lo tanto el
objeto emisor le indica por medio de un mensaje al objeto receptor qu debe hacer.
Definimos entonces que un programa en el paradigma de objetos es un conjunto de objetos
que colaboran entre s envindose mensajes
Otra caracterstica de la realidad consta en definir las responsabilidades ms all
de cmo se llevan a cabo. Al gerente de contabilidad no le interesa si Juan (el facturador)
factura escribiendo primero a quin va dirigida la factura y luego el detalle de la misma. La
manera en que Juan factura no le importa, siempre y cuando realice correctamente su
trabajo. Esta caracterstica permite al gerente de contabilidad despreocuparse sobre cmo se
est realizando la facturacin y ocuparse de sus propias tareas.
Esta caracterstica en el paradigma de objetos se llama encapsulamiento y es la
que permite separar qu hacen los objetos (responsabilidad) de cmo lo hacen
(implementacin).
Por ltimo, otra caracterstica que debemos poder simular en nuestro modelo es
delegar las responsabilidades a alguien sin preocuparnos quin sea ese alguien. Al gerente
de contabilidad no le importa si el facturador es Juan o Pedro, le importa poder pedirles que
facturen y que la facturacin se realice. Esa es la responsabilidad del facturador.
Esta caracterstica es muy importante, permite despreocuparse sobre quin hace el
trabajo y solamente asegurarse de tener buenos colaboradores en quienes delegar tareas.
Debemos estar acompaados de colaboradores si queremos llevar adelante ciertas tareas, y
lo que nos interesa de esos colaboradores es que cumplan con sus responsabilidades
correctamente, ms all de cmo lo hagan.
Esta caracterstica de la realidad no puede escapar de un paradigma que se jacta de
modelarla, y por supuesto no se escap. Esta caracterstica en objetos se denomina
polimorfismo3 y justamente permite al objeto emisor del mensaje despreocuparse de
quin es exactamente su colaborador, slo le interesa que sea responsable de llevar adelante
la tarea que le encomienda a travs del mensaje.
Resumiendo, desarrollar con objetos es modelar la realidad utilizando objetos que
deben colaborar entre s envindose mensajes. Estos objetos slo se preocupan de que sus
colaboradores sepan qu hacer (responsabilidad), no cmo lo hacen, y no tienen problemas
sobre quines son sus colaboradores (polimorfismo) siempre y cuando respondan sus
mensajes.
3

Polimorfismo viene del griego Poli que significa muchas, morph que significa forma,
muchas formas

Ac se termin, thats all folks. Esas son las reglas y los elementos de juego de
este paradigma. No hay clases, no hay herencia, slo un modelo con objetos polimrficos
que colaboran a travs de mensajes.

2- La otra verdad de las clases y la herencia

"Okay, okay, pero yo uso clases en Java, C++, C#, no pueden negar que existen estarn
argumentando con razn muchos de ustedes. Exacto, no negamos que existan, decimos que
no forman parte de la definicin del paradigma.
Entonces, si no forman parte de la definicin del paradigma, qu son, para que
estn, de dnde salen?. Las clases son herramientas que ofrecen ciertos lenguajes que
implementan el paradigma, que permiten agrupar en un solo lugar la misma
implementacin de una responsabilidad compartida por distintos objetos.
En el ejemplo del facturador, Juan y Pedro pueden implementar su proceso de
facturar de la misma manera. Lo lgico es que este proceso est escrito (implementado) en
un solo lugar. Ese lugar es la clase Facturador.
Es la clase la que define cmo se comportan los objetos en los lenguajes que
utilizan clases. Hay otras implementaciones del paradigma que no utilizan clases y cada
objeto define su propio comportamiento[Smith 95] 4.
La clase no es un fin en el paradigma de objetos, la clase es un medio. Un
medio que permite implementar fcilmente una responsabilidad compartida entre objetos.
Esto tiene que quedar bien claro puesto que no entender esta diferencia conceptual lleva a
errores gravsimos de diseo que terminan en sistemas fracasados como nombraremos ms
adelante.
La clase tambin tiene otra responsabilidad y es la de representar una idea, una
abstraccin. En el ejemplo del facturador, los objetos que facturan son Juan y Pedro
(espero que no se ofendan por tratarlos de objetos!) y la idea del facturador est modelada
por la clase Facturador.
Es bueno que la clase cumpla estas dos responsabilidades? Es bueno que
represente la idea y tambin la implemente? En realidad esta doble responsabilidad trae
problemas y confusiones en el momento de disear e implementar, pero este es un tema
digno de otro artculo.
Y la herencia?, qu explicacin tienen para la herencia... ?. Si fuimos un
poco radicales hasta este momento, esperamos que no se sorprendan si somos ms radicales
con la herencia.
La herencia es la causa de muchos fracasos de sistemas que se hacen con objetos.
La herencia es la herramienta peor utilizada entre todas las herramientas que existen en la
implementacin de este paradigma.
Puede suceder que existan clases mal modeladas, clases esquizofrnicas que hagan
diez mil cosas a la vez (imprimirse, guardarse, mostrarse, dormirse, levantarse, maquillarse,
etc.) pero no hay peor cosa que tener un modelo donde se utiliza incorrectamente la
herencia, porque la herencia es una relacin esttica entre clases.
La herencia cumple, al igual que las clases, dos roles. Uno conceptual y otro
implementativo. Conceptualmente la herencia modela relaciones es un entre
abstracciones. Desde el punto de vista implementativo, la herencia permite reutilizar
cdigo.
4

Es cuando se la utiliza nicamente desde el punto de vista implementativo que se

cometen las peores aberraciones que se puedan ver. Pero no se ofendan ni se sientan mal, a
todos nos pas y an podemos ver ejemplos de mal uso de herencia en libreras de
lenguajes que se jactan de ser de objetos.
Lamentablemente el tema herencia es tambin bastante largo como para
desarrollarlo en este artculo en profundidad, pero igual que Don Martn Fierro pido a
Dios me aclare el pensamiento para contarles una experiencia personal que espero ilustre
su peligro.
Recuerdo haber utilizado herencia en mis aos mozos de tal manera que ahora me
da vergenza. Por ejemplo, un sistema que desarrollamos tena campos visuales que deban
guardarse en campos de una tabla. Por un lado exista una librera de clases visuales
(TurboVision, de Borland C++... algunos se pondrn melanclicos) y por otro lado la
librera de acceso a archivos estilo Dbase (la librera se denominaba CodeBase).
En una esquina del ring estaba la clase InputField y en la esquina opuesta la clase
BaseField, y en el medio de esta pelea estaba la herencia, pero no cualquier herencia,
tenamos herencia mltiple!!, qu gran ventaja!! Y s, cuando la nica herramienta que
conoces es un martillo, todos los problemas se ven como si fuesen clavos 5 y a este clavo
lo resolvimos con nuestro martillo, la herencia mltiple.
En el primer da apareci la luz cuando creamos la clase InputBaseField que
heredaba de InputField y BaseField a la vez (herencia multiple, lo recuerdan...?). Al
tercero estbamos muy aburridos y nos dimos cuenta que algunos campos eran numricos,
otros de fecha, etc., entonces subclasificamos InputBaseField con NumericInputBaseField,
DateInputBaseField, etc., una clase por cada tipo de dato. Nos sentamos muy contentos, el
programa era un relojito. Pero en el sptimo da no pudimos descansar porque nos dimos
cuenta que ahora tenamos campos que eran claves forneas de otras tablas y no podamos
poner ese comportamiento en una sola clase. O crebamos una subclase de
NumericInputBaseField, de DateInputBaseField, etc., repitiendo el cdigo del
comportamiento de clave fornea o crebamos una subclase de InputBaseField que tuviese
este comportamiento (ForeignKeyInputBaseField) y sus correspondientes subclases segn
el tipo de dato que representaba cada campo (NumericForeignKeyInputBaseField,
DateForeignKeyInputBaseField, etc. ), qu asco!!
Claro, despus de ver esto no es difcil convencer a alguien que los objetos no son
buenos. Algo haba pasado, algo andaba mal y realmente tardamos mucho tiempo en
descubrir qu era, porque la respuesta era tan sencilla, tan obvia, tenamos a la vista y no la
considerbamos. El problema era que habamos usado mal la herencia. Habamos heredado
para reutilizar cdigo (acaso desarrollar con objetos no se trata de reusar cdigo?) y nos
quedaron estas clases que poco tenan que ver con ideas claras y simples de la realidad.
Eran clases multifacticas, representaban todo y hacan de todo. En definitiva no eran
clases cohesivas y estaban completamente acopladas (si slo fuese sencillo seguir la
regla de mxima cohesin y mnimo acoplamiento).
Qu podamos hacer para solucionar este problema?, lo nico que podemos hacer
cuando desarrollamos con objetos: crear ms objetos. InputField y BaseField estaban bien
como clases, no haba que heredar de ellas, la solucin era crear algn objeto que se
encargara de conectar estos otros dos y listo.
Moraleja, para usar herencia hay que entender qu significa y les aseguro que usar
herencia para reusar cdigo es la peor manera de utilizarla. Cada vez que estn tentados a
5

Frase de Abraham Maslow

heredar de una clase, piensen primero si no se estn olvidando de algn otro objeto que
debera asumir la responsabilidad que le quieren dar a esta nueva subclase.
Si a usted le vendieron que hay que utilizar lenguajes de objetos para desarrollar
porque tienen Clases y Herencia, reclmele a su vendedor porque lamentamos decirle que
le vendieron gato por liebre.

3- Rompiendo mitos
Veremos ahora a partir de entender qu significa desarrollar con objetos, como ciertos mitos
de nuestra profesin se caen inexorablemente.

3.1 - Mito 1: Utilizando Objetos se ahorra un 30% del costo de

un proyecto debido a la reutilizacin de cdigo
Este mito fue uno de los grandes caballitos de batalla que se utiliz para vender
esta tecnologa.
El problema de esta frase es asociar reutilizacin de cdigo con herencia, y como
ya vimos, utilizar herencia para reutilizar cdigo se asemeja a clavar un clavo con un
destornillador.
Cuando se dan los primero pasos con objetos se utiliza herencia como un andador.
Cmo la herencia simple no alcanza a satisfacer nuestros pasos en falso, se crea la herencia
mltiple, motivo por el cul terminamos cayndonos por completo.
El reuso de cdigo con objetos no viene de la mano de la herencia sino que viene
de la mano de cumplir la regla nmero uno del paradigma: modelar la realidad.
Veamos un ejemplo. Los sistemas bancarios o financieros tienen por finalidad
administrar dinero. El dinero es el fin. Pero, cuntos de estos sistemas tienen un objeto
que modele el dinero? Haga memoria...
Lamentablemente conozco un slo sistema que modela el dinero correctamente.
Las justificaciones y explicaciones que dan los dueos de los otros sistemas son siempre las
mismas. Los programadores dicen por qu usar un objeto que consume memoria para
representar 10 pesos si me alcanza con el nmero 10?. El diseo de las bases de datos
relacionales ayuda a confundirnos con el diseo de los programas puesto que en la base de
datos tenemos un campo para la cantidad y otro para la moneda, entonces tenemos el 10
en una variable de tipo integer y otra de tipo string para la moneda. Por ltimo est el
usuario que no entiende por qu el sistema no puede valuar carteras que tienen valores en
pesos y en dlares, o que para hacerlo hay que pagar un desarrollo de 6 meses que impacta
en todo el sistema. Por qu?
Porque el nmero 10 no es 10 pesos, porque un entero 10 y un string pesos no
son 10 pesos. La realidad es clara, si tengo 10 pesos debo tener un objeto en el sistema
que lo represente, un objeto que sea 10 pesos y si tengo 20 dlares necesito un objeto
en el sistema que lo represente, el objeto 20 dlares.
Si tuvisemos clases que representen estos conceptos (la podramos llamar Dinero)
entonces podramos sumar 10 pesos con 30 pesos o podramos cotizar 10 pesos en
dlares.
Pensemos un poco ms sobre este ltimo comportamiento. De quin ser la
responsabilidad de cotizar dinero? Nos vemos tentados a poner dicha responsabilidad en el
Dinero, sin embargo analizando la realidad veremos que si le pido a 10 pesos que me
indique cuantos dlares vale no obtendremos respuesta. A quin debemos pedirle que cotice

los 10 pesos en dlares es a un AgenteDeCambio, otro objeto que deber estar en

nuestro modelo.
La reutilizacin del cdigo se obtiene modelando correctamente la realidad. Se
obtiene al crear la clase Dinero y asignarle nicamente la responsabilidad que se merece.
Tener ese concepto modelado en una clase implica poder usarlo para un sistema bancario,
en un sistema financiero o en un sistema contable. Pero si la clase Dinero tuviese la
responsabilidad de cotizarse entonces slo podra utilizase en un sistema financiero y por
no haber modelado correctamente la realidad el reuso se vera restringido.
Modelar la realidad y asignarle a los objetos nicamente la responsabilidad que
tienen es el primer paso para reutilizar cdigo. Y decimos primer paso puesto que para
poder reutilizar cdigo tiene que existir la cultura y los procesos de desarrollo dentro de la
empresa que lo permitan.

3.2 - Mito 2: La tecnologa de objetos es nueva, hay que esperar

que madure.
En realidad la tecnologa de objetos naci all por 1967 y se desarroll en la
dcada del 70. En esta dcada se realiz una investigacin exhaustiva en los laboratorios
de Xerox en la localidad Palo Alto, California, cuyo resultado fue el producto denominado
Smalltalk-80 [Kay 93]. Esta implementacin del paradigma es la ms pura que se conoce
comercialmente hasta la actualidad.
Ya en el ao 80, Smalltalk usaba tcnicas que recin ahora empiezan a ser
populares, como la recoleccin de basura automtica (garbage collection) y el soporte de
una mquina virtual para poder correr en cualquier plataforma. Con Smalltalk se crearon
productos que luego se popularizaron con otras tecnologas como el mouse y la interface de
usuario grfica utilizando ventanas.
Pero a este mito debemos concederle cierta parte de verdad, puesto que lo nuevo o
inmaduro son algunas implementaciones del paradigma, como ser Java o .Net.
Java en este momento es una implementacin ms madura que .Net, sin embargo
ambas tienen varias deficiencias desde el punto de vista paradigmtico. Por empezar,
rompen la regla nmero uno del paradigma, no estn pensados para modelar, estn
pensados para implementar algoritmos. Segundo, no todos los elementos de estos
lenguajes son objetos, empezando por las clases (y los nmeros en Java). Tercero, son
lenguajes fuertemente tipados lo cual atenta contra la flexibilidad de la modelizacin y el
polimorfismo (tema para otro artculo ms!!).
Pero no perdamos las esperanzas, cabe destacar que estas implementaciones se
acercan ms a un ambiente de objetos como aquel creado por Xerox Parc en la dcada del
70. Ambos utilizan recoleccin de basura (garbage collection), poseen la misma
arquitectura (una virtual machine, por ms que Microsoft se esfuerce por llamar a su VM de
otra manera) y no permiten escribir cdigo fuera de las clases. Podramos decir que son un
paso hacia delante respecto de C++, sin embargo por las desventajas nombradas
anteriormente no pueden ser denominados lenguajes de objetos, sino simplemente
lenguajes orientados a objetos.

3.3 -Mito 3: Programar en C++ es difcil, por lo tanto la

tecnologa de objetos es complicada y no sirve
Aquellos que hayan programado o administrado proyectos donde el lenguaje de
implemetacin era C++ pueden llegar a pensar as, y tiene todo el derecho. Lo correcto de

este mito es la parte de la frase que dice programar en C++ es difcil. Realmente es
difcil. El lenguaje C++ es una muy mala implementacin del paradigma. Miles de
proyectos han fracasado por el simple hecho de utilizar C++ (y otros miles habrn
fracasado por una mala administracin, no siempre la tecnologa es la responsable).
C++ rompe principios bsicos del paradigma como el encapsulamiento, dificulta el
polimorfismo permitiendo definir mtodos que no son virtuales, no posee recoleccin de
basura automtica, hay tres maneras distintas de conocer a los objetos (por valor, por
referencia y por medio de punteros) y para colmo de males permite utilizar herencia
mltiple. La dificultad que provoca trabajar con variables tipadas hizo que los creadores de
este lenguaje implementen los famosos templates, que no son ms que macro
expansiones de cdigo (aquellos viejos y experimentados programadores de assembler
entienden a que me refiero). He visto un proyecto crecer en la dimensin de sus archivos
ejecutables de manera exponencial por el simple hecho de utilizar templates. Todo era un
template. Una ventana era un template, un campo de una ventana era un template,
absolutamente todo era un template. Como era de esperarse el proyecto fracas y la culpa
quin la tuvo, la inmadurez de los objetos y no la falta de conocimiento sobre cmo
desarrollar con ellos.
Me imagino a aquellas personas que vienen del COBOL o el VisualBasic y se
encuentran con todas estas dificultades. Por qu no van a tener derecho de pensar que los
objetos no sirven?
Hay que saber separar la paja del trigo. C++ es una implementacin (muy mala
por cierto) del paradigma y lo difcil de usar no es el paradigma, es C++, que poco tiene que
ver con los objetos ms all de cmo se lo vendi.

3.4 -Mito 4: Conozco de objetos por qu se UML

Otras de las grandes confusiones. UML (Unified Modeling Language) [UML xx]
no es objetos, es un lenguaje visual que nos permite (entre otras cosas) crear por medio de
cajitas y flechitas un modelo que puede ser implementado con algn lenguaje de objetos.
Lo interesante del modelo que se obtiene utilizando UML (u otro lenguaje visual de diseo)
es que nunca se cuelga, puesto que nunca se ejecuta, por lo tanto es muy difcil
demostrar que el modelo hecho con UML sea correcto o incorrecto.
UML no ensea a modelar, utilizar UML no implica crear buenos diseos, conocer
UML no significa conocer objetos y para colmo de males, disear con UML nos obliga a
nosotros (mortales humanos) a hacer las veces de computadoras, ejecutando en nuestra
cabeza el modelo que estamos creando, lo cual produce como es de esperar, un modelo
plagado de errores y difcil de implementar. (Olvidemos por ahora el problema que implica
mantener el cdigo sincronizado con los diagramas)
En muchas oportunidades me encuentro con esta confusin cuando estoy tomando
entrevistas de trabajo. Muchas veces a la pregunta si han trabajo con objetos he recibido
como respuesta si, conozco UML, lo cual desacredita por completo al entrevistado.
No es mi intencin crear otra polmica, pero hasta en ciertas ocasiones trabajar
con UML perjudica la obtencin de buenos modelos. Principalmente porque la tcnica de
diseo que se aconseja utilizar con UML hace hincapi en el modelo esttico (diagrama de
clases) del problema y no en el ms importante, el dinmico (diagrama de secuencia o
colaboraciones). En objetos es ms importante saber cmo colaboran los objetos que las
clases que componen el modelo. Recuerden la definicin de programa.
Si usted cree que alcanza con un diagrama de clases hecho en UML para
implementar un sistema, va por mal camino. Este error es muy comn y su principal raz

est dada por la analoga que se hace entre los diagramas de clases y los diagrama de
entidad-relacin del paradigma relacional, que nada tienen en comn (por empezar son de
paradigmas distintos).
En objetos la modelizacin del problema se debe hacer de manera incremental y la
mejor tcnica que conozco para este tipo de modelizacin es la denominada Test
Development Driven (TDD) [Beck 02] que como es de esperar, rechaza la idea de sentarse
a realizar grandes e improductivas sesiones de diseo que terminan en diagramas UML
alejados de la realidad.
Segn mi opinin, UML es una buena herramienta para comunicar un modelo
terminado, no para crearlo.

3.5 -Mito 5: Los objetos no tienen buena performance

Otra disyuntiva que se presenta constantemente sobre los objetos es el tema de la
performance. Varias veces aparece la performance como problema de esta tecnologa, pero
debemos nuevamente separar correctamente la paja del trigo.
Es verdad que utilizar objetos consume ms recursos que utilizar lenguajes
procedurales como C, pero C consume tambin ms recursos que Assembler, y una base de
datos relacional consume ms recursos y es ms lenta que archivos VSAM. Todos sabemos
esto. Es el precio que hay que pagar cuando utilizamos tecnologa que nos alivia de ciertas
tareas dandol mayor responsabilidad a la computadora.
No debemos asustarnos de esta realidad la cual en definitiva nos conviene como
seres humanos, porque cuanto ms trabajo realice la computadora mejor. La computadora
nunca se cansa, nunca se equivoca, mientras que nosotros s. No tengamos miedo en pedirle
ms esfuerzo a la computadora, para eso estn! Es slo cuestin de meses para que
dupliquen su velocidad de procesamiento. La mantenibilidad y ampliacin de un sistema no
es cuestin de meses, es en algunos casos cuestin de aos y dcadas.
En rigor de verdad la tecnologa de objetos consume ms recursos, pero esto no
significa que sea ms lenta. La performance de una solucin es afectada por distintos
elementos y uno muy importante de ellos es el diseo. La mayora de los sistemas que
tienen problemas de performance se debe a problemas endmicos en su diseo, por ello la
famosa frase tiremos todo y empecemos de nuevo. Una solucin mal diseada
dificilmente performee bien cuando quiera ser utilizada en situaciones no previstas.
Debemos tambin hacer nuevamente la salvedad entre paradigma e
implementaciones del paradigma. El paradigma nunca podra tener problemas de
perfomance puesto que es conceptual. Pueden tener problemas de performance o recursos
sus implementaciones.
Actualmente estamos sufriendo estos problemas con Java y .Net, puesto que para
desarrollar en estos lenguajes con un IDE digno debemos tener como mnimo 256 MB de
memoria. El problema entonces es del paradigma? No!, el problema es de estos
lenguajes. Un contraejemplo valida mi aseveracin. Cualquiera de los Smalltalk
comerciales funciona correctamente en mquinas de 64 MB, y algunos hasta en mquinas
de 16 MB. El problema no es el paradigma, nuevamente vemos que el problema est en los
lenguajes que lo implementan.

4- Entonces, Por qu objetos? y Por qu no objetos?

Por qu objetos?, porque objetos es el mejor paradigma que permite crear un
modelo computacional de un dominio de la realidad.

Por qu es el mejor paradigma?, porque las herramientas que nos provee para
disear (objetos y mensajes) nos permiten obtener un modelo cuyo gap semntico con la
realidad es mnimo.
Por qu es bueno tener un modelo fiel de la realidad?, porque aplicar los cambios
que se produzcan en la realidad en un modelo fiel a esta ser ms sencillo y menos
traumtico que un modelo peleado con la realidad.
Cuando el paradigma de objetos es utilizado correctamente, se pueden atacar
problemas esenciales del software6 con buenos resultados. Si se modela bien la realidad, el
modelo ser sencillo y se habr atacado la complejidad del software. Si se modela bien la
realidad, los cambios que se produzcan en esta impactarn de manera proporcional en
nuestro modelo. A cambios sencillos de la realidad podremos ofrecer soluciones sencillas
en nuestro sistema, y por ende de bajo costo.
Pero generalmente este tipo de explicaciones no alcanzan o no se terminan de
apreciar hasta que no se viven, por eso ciertas veces cuando me preguntan por qu
objetos?, no encuentro mejor respuesta que otra pregunta, por qu no objetos? Todas las
veces que discut sobre este tema llegu a la conclusin que no hay razones tcnicas vlidas
para no trabajar con objetos. Puede haber razones que corresponden ms al sector humano
o administrativo de todo proyecto de software por el cual no sea conveniente trabajar con
objetos, como la falta de experiencia en la tecnologa o recursos escasos.
Trabajemos con objetos o no, estamos usando la misma herramienta para ejecutar
nuestros sistemas: computadoras que se comportan como mquinas de Turing. El nivel de
expresividad de los lenguajes que existen para desarrollar cdigo que luego es ejecutado
por estas mquinas es exactamente el mismo, sea Assembler, C++ o Smalltalk. La
diferencia est en cuanto cuesta resolver el mismo problema con cada uno de estos
lenguajes.
Si concordamos que un programa no es ms que un modelo computacional de la
realidad entonces debemos concluir que ser ms sencillo hacer programas con aquellos
lenguajes que permitan modelar la realidad fcilmente, con aquellos lenguajes con los que
pueda crear mejores abstracciones. Estos lenguajes son los que implementan el paradigma
de objetos y entre ellos el ms productivo segn mi experiencia, es Smalltalk (que es ms
que un lenguaje, es un ambiente de objetos).
Entonces, por qu no objetos? Creo que el nico motivo vlido sera el no querer
pagar la inversin del cambio que se necesita hacer por tratarse de un nuevo paradigma.
Sin embargo no debemos olvidar que en esta profesin el cambio y la innovacin son los
puentes hacia la supervivencia y el crecimiento.
Si usted est pensando en cambiar, no se tire a la pileta sin un baero cerca,
planifique el cambio, instryase, capactese, hgalo gradualmente. Y luego cuando tenga
que hacer su primer sistema, concntrese en la realidad que tiene que resolver, es as
solamente como podr tener xito utilizando objetos.

Agradecimientos
Quera agradecer fundamentalmente a mi gran maestro del desarrollo con objetos,
Lic. Mximo Prieto, que sin su ayuda y conocimiento hubiese sido imposible tener estos
conceptos sobre el paradigma.
6

Un buen artculo sobre este tema es el famoso No Silver Bullet de Frederick Brooks,
muy recomendable a todos aquellos profesionales de sistemas que quieran entender un poco
ms sobre los problemas del desarrollo de software.

Tambin un agradecimiento especial al grupo de objetos de la UBA, con quienes

discutimos constantemente sobre objetos y cuyas ideas estn volcadas a lo largo de este
artculo.

Referencias
[Beck 02]
[Kay 93]
[Smith 95]
[UML xx]

K. Beck. Test Driven Development: By Example, Addison-Wesley,

ISBN: 0321146530, 2002.
A. Kay. The Early History of Smalltalk. In proceeding of ACM
SIGPLAN VOL. 28 No. 3 Marzo 93 pp.69 75.
R. B. Smith, D. Ungar. Programming as an Experience: The Inspiration
for Self. In proceeding of ECOOP '95 Conference, Aarhus, Denmark,
August, 1995.
www.uml.org

Sobre el autor
El Lic. Hernn A. Wilkinson es Gerente de Desarrollo de Mercap S.R.L. y se
desempea como Profesor de las materias Programacin Orientada a Objetos y Diseo
Avanzado con Objetos de la Facultad de Ciencias Exactas de la U.B.A.