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 tareasencilla. Es una de esas cruzadas casi imposibles que desata las discusiones msapasionadas dentro del mbito profesional del desarrollo de sistemas y que llega a tocar lossentimientos ms ntimos de sus profesionales. No basta con dar ejemplos de proyectosexitosos desarrollados con esta tecnologa porque tambin soporta sobre su espaldaproyectos fracasados.

Podramos enumerar los motivos por los cules desarrollar software con objetos esla mejor opcin tomando un libro del tema en cuestin y copiando su ndice, puesto quetodos conocemos hasta el cansancio las palabras que nos vendieron con esta tecnologa.Por qu no reflotar esos tecnicismos que como, caballitos de batalla, se utilizanconstantemente? Por qu no decir que con los objetos tenemos reuso de cdigo, quepodemos 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 estatecnologa, que an despus de tantos aos de vida no es conocida ni utilizadacorrectamente1.

Les proponemos en este artculo tratar de entender qu significa desarrollar conobjetos, bajar un poco a tierra esta tecnologa viendo algunos errores que se cometencomnmente con ella, desterrar algunos mitos creados alrededor de los objetos y por ltimoresponder 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. Yel principio en este caso es entender que trabajar con objetos es trabajar en un paradigmacompletamente distinto al que estamos acostumbrados la mayora de nosotros y que casitodas las universidades ensean (salvo contadas excepciones).

Un paradigma es un marco de referencia que impone reglas sobre cmo se debenhacer 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 depensar, implica un cambio, y todo cambio es difcil.

Definamos entonces como primer axioma que trabajar con objetos es trabajar conun paradigma nuevo. Esto implica que debemos definir cules son las reglas de este nuevoparadigma.

Muchos de ustedes, seguramente conocedores de C++, Java o el joven C#,pensarn rpidamente las reglas son utilizar clases y herencia. Permtannos disentirdrsticamente con esto.

Objetos no tiene nada que ver con clases y herencia. Clases y herencia sonherramientas que nos dan ciertas implementaciones del paradigma (lenguajes) que malutilizadas pueden llegar a producir grandes desastres en el desarrollo de un sistema y queluego se utilizan para justificar que los objetos no sirven, mejor seguir con COBOL o C1 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 importantesenseanzas)

La primera regla del paradigma trata sobre qu se intenta obtener como resultadodel desarrollo de sistemas utilizando objetos. Esta es: Un sistema hecho con objetos es unmodelo computacional de una porcin de la realidad (la porcin que queremossistematizar, donominada dominio).

Las dos palabras estrella de esta definicin son modelo y realidad. Hay unasituacin de la realidad (por ejemplo facturar una venta) que debe ser modelada de talmanera que pueda ser ejecutada por una computadora, obteniendo como mnimo el mismoresultado que el proceso reemplazado por este nuevo sistema produca.

Durante el proceso de crear un modelo surgen las ventajas y desventajas de tenerbuenas herramientas de modelizacin. En el paradigma de objetos la herramienta principalde este proceso de modelizacin es justamente el objeto. Un objeto no es ms que unarepresentacin conceptual de algn elemento de la realidad.

En nuestro ejemplo del proceso de facturacin, un elemento de la realidad es lafactura, otro es la persona que realiza la factura y no menos importante el motivo por elcual se est facturando: la venta.

En nuestro modelo por lo tanto, debemos representar estos elementos de larealidad con objetos. Hay elementos fciles de reconocer puesto que son elementos fsicoscomo la factura o la persona que factura (una persona que durante este proceso asume elrol de facturador) y hay elementos ms difciles de ver puesto que son elementosabstractos, ideas o acciones, como la venta en s misma, que tambin debe ser modeladapuesto que una factura es el resultado de haber realizado una venta.

Durante este proceso de modelizacin de la realidad que hacemos, no debemospreocuparnos por cuestiones que no pertenecen a ella como la performance, la persistencia2u otros problemas o cuestiones de otra realidad, como la computacional.

Debe quedar claro que la performance, la persistencia y otros problemascomputacionales son ortogonales (no se colisionan) con la realidad que se est modelando yque si se los incluye dentro del modelo original lo ensuciarn con problemas ajenos, queharn 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, despustendremos tiempo para preocuparnos por hacer que este modelo adems ejecute bajo losrequerimientos no funcionales especificados.

Entonces, si no debemos ocuparnos de la performance ni la persistencia, de qudebemos ocuparnos cuando modelamos con objetos?. Debemos ocuparnos de lasresponsabilidades de estos objetos, de qu hacen.

Pensemos en la responsabilidad de un facturador. Qu hace un facturador? Suresponsabilidad es facturar. La responsabilidad de una factura no ser ms que permitirsaber 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). Laresponsabilidad 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 querealmente corresponda a ese objeto. Por ejemplo, debe la factura tener cmoresponsabilidad imprimirse?. Pensemos en la realidad. Una factura no se imprime a smisma, alguien se encarga de imprimirla, por lo tanto la factura no tiene la2 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 sermodelados.

Podramos decir por ahora que desarrollar con objetos es modelar el problema quetenemos que resolver utilizando objetos.

Sin embargo, esto no alcanza. La realidad tiene ciertas caractersticas interesantesque debemos poder simular si queremos tener un buen modelo. Una de esas caractersticases la interaccin entre los elementos de la realidad. Por ejemplo, el gerente de contabilidadle 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 conmails, mensajes de red, etc.) que representan la comunicacin o interaccin de elementos dela realidad.

Como todo proceso de comunicacin hay un emisor y un receptor. Por lo tanto elobjeto 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 objetosque colaboran entre s envindose mensajes

Otra caracterstica de la realidad consta en definir las responsabilidades ms allde 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. Lamanera en que Juan factura no le importa, siempre y cuando realice correctamente sutrabajo. Esta caracterstica permite al gerente de contabilidad despreocuparse sobre cmo seest realizando la facturacin y ocuparse de sus propias tareas.

Esta caracterstica en el paradigma de objetos se llama encapsulamiento y es laque permite separar qu hacen los objetos (responsabilidad) de cmo lo hacen(implementacin).

Por ltimo, otra caracterstica que debemos poder simular en nuestro modelo esdelegar las responsabilidades a alguien sin preocuparnos quin sea ese alguien. Al gerentede contabilidad no le importa si el facturador es Juan o Pedro, le importa poder pedirles quefacturen y que la facturacin se realice. Esa es la responsabilidad del facturador.

Esta caracterstica es muy importante, permite despreocuparse sobre quin hace eltrabajo y solamente asegurarse de tener buenos colaboradores en quienes delegar tareas.Debemos estar acompaados de colaboradores si queremos llevar adelante ciertas tareas, ylo que nos interesa de esos colaboradores es que cumplan con sus responsabilidadescorrectamente, ms all de cmo lo hagan.

Esta caracterstica de la realidad no puede escapar de un paradigma que se jacta demodelarla, y por supuesto no se escap. Esta caracterstica en objetos se denominapolimorfismo3 y justamente permite al objeto emisor del mensaje despreocuparse dequin es exactamente su colaborador, slo le interesa que sea responsable de llevar adelantela tarea que le encomienda a travs del mensaje.

Resumiendo, desarrollar con objetos es modelar la realidad utilizando objetos quedeben colaborar entre s envindose mensajes. Estos objetos slo se preocupan de que suscolaboradores sepan qu hacer (responsabilidad), no cmo lo hacen, y no tienen problemassobre quines son sus colaboradores (polimorfismo) siempre y cuando respondan susmensajes.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 deeste paradigma. No hay clases, no hay herencia, slo un modelo con objetos polimrficosque 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 estarnargumentando con razn muchos de ustedes. Exacto, no negamos que existan, decimos queno forman parte de la definicin del paradigma.

Entonces, si no forman parte de la definicin del paradigma, qu son, para queestn, de dnde salen?. Las clases son herramientas que ofrecen ciertos lenguajes queimplementan el paradigma, que permiten agrupar en un solo lugar la mismaimplementacin de una responsabilidad compartida por distintos objetos.

En el ejemplo del facturador, Juan y Pedro pueden implementar su proceso defacturar de la misma manera. Lo lgico es que este proceso est escrito (implementado) enun solo lugar. Ese lugar es la clase Facturador.

Es la clase la que define cmo se comportan los objetos en los lenguajes queutilizan clases. Hay otras implementaciones del paradigma que no utilizan clases y cadaobjeto define su propio comportamiento[Smith 95] 4.

La clase no es un fin en el paradigma de objetos, la clase es un medio. Unmedio que permite implementar fcilmente una responsabilidad compartida entre objetos.Esto tiene que quedar bien claro puesto que no entender esta diferencia conceptual lleva aerrores gravsimos de diseo que terminan en sistemas fracasados como nombraremos msadelante.

La clase tambin tiene otra responsabilidad y es la de representar una idea, unaabstraccin. 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 modeladapor la clase Facturador.

Es bueno que la clase cumpla estas dos responsabilidades? Es bueno querepresente la idea y tambin la implemente? En realidad esta doble responsabilidad traeproblemas y confusiones en el momento de disear e implementar, pero este es un temadigno de otro artculo.

Y la herencia?, qu explicacin tienen para la herencia... ?. Si fuimos unpoco radicales hasta este momento, esperamos que no se sorprendan si somos ms radicalescon 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 laimplementacin de este paradigma.

Puede suceder que existan clases mal modeladas, clases esquizofrnicas que hagandiez 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 laherencia, porque la herencia es una relacin esttica entre clases.

La herencia cumple, al igual que las clases, dos roles. Uno conceptual y otroimplementativo. Conceptualmente la herencia modela relaciones es un entreabstracciones. Desde el punto de vista implementativo, la herencia permite reutilizarcdigo.

4

Es cuando se la utiliza nicamente desde el punto de vista implementativo que secometen las peores aberraciones que se puedan ver. Pero no se ofendan ni se sientan mal, atodos nos pas y an podemos ver ejemplos de mal uso de herencia en libreras delenguajes que se jactan de ser de objetos.

Lamentablemente el tema herencia es tambin bastante largo como paradesarrollarlo en este artculo en profundidad, pero igual que Don Martn Fierro pido aDios me aclare el pensamiento para contarles una experiencia personal que espero ilustresu peligro.

Recuerdo haber utilizado herencia en mis aos mozos de tal manera que ahora meda vergenza. Por ejemplo, un sistema que desarrollamos tena campos visuales que debanguardarse 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 lalibrera 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 claseBaseField, 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 queconoces es un martillo, todos los problemas se ven como si fuesen clavos5 y a este clavolo resolvimos con nuestro martillo, la herencia mltiple.

En el primer da apareci la luz cuando creamos la clase InputBaseField queheredaba de InputField y BaseField a la vez (herencia multiple, lo recuerdan...?). Altercero 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, elprograma era un relojito. Pero en el sptimo da no pudimos descansar porque nos dimoscuenta que ahora tenamos campos que eran claves forneas de otras tablas y no podamosponer ese comportamiento en una sola clase. O crebamos una subclase deNumericInputBaseField, de DateInputBaseField, etc., repitiendo el cdigo delcomportamiento de clave fornea o crebamos una subclase de InputBaseField que tuvieseeste comportamiento (ForeignKeyInputBaseField) y sus correspondientes subclases segnel 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 sonbuenos. Algo haba pasado, algo andaba mal y realmente tardamos mucho tiempo endescubrir qu era, porque la respuesta era tan sencilla, tan obvia, tenamos a la vista y no laconsiderbamos. El problema era que habamos usado mal la herencia. Habamos heredadopara reutilizar cdigo (acaso desarrollar con objetos no se trata de reusar cdigo?) y nosquedaron 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 eranclases cohesivas y estaban completamente acopladas (si slo fuese sencillo seguir laregla de mxima cohesin y mnimo acoplamiento).

Qu podamos hacer para solucionar este problema?, lo nico que podemos hacercuando desarrollamos con objetos: crear ms objetos. InputField y BaseField estaban biencomo clases, no haba que heredar de ellas, la solucin era crear algn objeto que seencargara de conectar estos otros dos y listo.

Moraleja, para usar herencia hay que entender qu significa y les aseguro que usarherencia 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 quedebera asumir la responsabilidad que le quieren dar a esta nueva subclase.

Si a usted le vendieron que hay que utilizar lenguajes de objetos para desarrollarporque tienen Clases y Herencia, reclmele a su vendedor porque lamentamos decirle quele vendieron gato por liebre.

3- Rompiendo mitosVeremos ahora a partir de entender qu significa desarrollar con objetos, como ciertos mitosde 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 venderesta tecnologa.

El problema de esta frase es asociar reutilizacin de cdigo con herencia, y comoya vimos, utilizar herencia para reutilizar cdigo se asemeja a clavar un clavo con undestornillador.

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 herenciamltiple, motivo por el cul terminamos cayndonos por completo.

El reuso de cdigo con objetos no viene de la mano de la herencia sino que vienede la mano de cumplir la regla nmero uno del paradigma: modelar la realidad.

Veamos un ejemplo. Los sistemas bancarios o financieros tienen por finalidadadministrar dinero. El dinero es el fin. Pero, cuntos de estos sistemas tienen un objetoque 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 lasmismas. Los programadores dicen por qu usar un objeto que consume memoria pararepresentar 10 pesos si me alcanza con el nmero 10?. El diseo de las bases de datosrelacionales ayuda a confundirnos con el diseo de los programas puesto que en la base dedatos tenemos un campo para la cantidad y otro para la moneda, entonces tenemos el 10en una variable de tipo integer y otra de tipo string para la moneda. Por ltimo est elusuario que no entiende por qu el sistema no puede valuar carteras que tienen valores enpesos y en dlares, o que para hacerlo hay que pagar un desarrollo de 6 meses que impactaen todo el sistema. Por qu?

Porque el nmero 10 no es 10 pesos, porque un entero 10 y un string pesos noson 10 pesos. La realidad es clara, si tengo 10 pesos debo tener un objeto en el sistemaque lo represente, un objeto que sea 10 pesos y si tengo 20 dlares necesito un objetoen 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 endlares.

Pensemos un poco ms sobre este ltimo comportamiento. De quin ser laresponsabilidad de cotizar dinero? Nos vemos tentados a poner dicha responsabilidad en elDinero, sin embargo analizando la realidad veremos que si le pido a 10 pesos que meindique 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 ennuestro modelo.

La reutilizacin del cdigo se obtiene modelando correctamente la realidad. Seobtiene 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 laresponsabilidad de cotizarse entonces slo podra utilizase en un sistema financiero y porno haber modelado correctamente la realidad el reuso se vera restringido.

Modelar la realidad y asignarle a los objetos nicamente la responsabilidad quetienen es el primer paso para reutilizar cdigo. Y decimos primer paso puesto que parapoder reutilizar cdigo tiene que existir la cultura y los procesos de desarrollo dentro de laempresa 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 ladcada del 70. En esta dcada se realiz una investigacin exhaustiva en los laboratoriosde Xerox en la localidad Palo Alto, California, cuyo resultado fue el producto denominadoSmalltalk-80 [Kay 93]. Esta implementacin del paradigma es la ms pura que se conocecomercialmente hasta la actualidad.

Ya en el ao 80, Smalltalk usaba tcnicas que recin ahora empiezan a serpopulares, como la recoleccin de basura automtica (garbage collection) y el soporte deuna mquina virtual para poder correr en cualquier plataforma. Con Smalltalk se crearonproductos que luego se popularizaron con otras tecnologas como el mouse y la interface deusuario grfica utilizando ventanas.

Pero a este mito debemos concederle cierta parte de verdad, puesto que lo nuevo oinmaduro son algunas implementaciones del paradigma, como ser Java o .Net.

Java en este momento es una implementacin ms madura que .Net, sin embargoambas tienen varias deficiencias desde el punto de vista paradigmtico. Por empezar,rompen la regla nmero uno del paradigma, no estn pensados para modelar, estnpensados para implementar algoritmos. Segundo, no todos los elementos de estoslenguajes son objetos, empezando por las clases (y los nmeros en Java). Tercero, sonlenguajes fuertemente tipados lo cual atenta contra la flexibilidad de la modelizacin y elpolimorfismo (tema para otro artculo ms!!).

Pero no perdamos las esperanzas, cabe destacar que estas implementaciones seacercan ms a un ambiente de objetos como aquel creado por Xerox Parc en la dcada del70. Ambos utilizan recoleccin de basura (garbage collection), poseen la mismaarquitectura (una virtual machine, por ms que Microsoft se esfuerce por llamar a su VM deotra manera) y no permiten escribir cdigo fuera de las clases. Podramos decir que son unpaso hacia delante respecto de C++, sin embargo por las desventajas nombradasanteriormente no pueden ser denominados lenguajes de objetos, sino simplementelenguajes 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 deimplemetacin 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 esdifcil. El lenguaje C++ es una muy mala implementacin del paradigma. Miles deproyectos han fracasado por el simple hecho de utilizar C++ (y otros miles habrnfracasado por una mala administracin, no siempre la tecnologa es la responsable).

C++ rompe principios bsicos del paradigma como el encapsulamiento, dificulta elpolimorfismo permitiendo definir mtodos que no son virtuales, no posee recoleccin debasura automtica, hay tres maneras distintas de conocer a los objetos (por valor, porreferencia y por medio de punteros) y para colmo de males permite utilizar herenciamltiple. La dificultad que provoca trabajar con variables tipadas hizo que los creadores deeste lenguaje implementen los famosos templates, que no son ms que macroexpansiones de cdigo (aquellos viejos y experimentados programadores de assemblerentienden a que me refiero). He visto un proyecto crecer en la dimensin de sus archivosejecutables de manera exponencial por el simple hecho de utilizar templates. Todo era untemplate. 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 culpaquin la tuvo, la inmadurez de los objetos y no la falta de conocimiento sobre cmodesarrollar con ellos.

Me imagino a aquellas personas que vienen del COBOL o el VisualBasic y seencuentran con todas estas dificultades. Por qu no van a tener derecho de pensar que losobjetos no sirven?

Hay que saber separar la paja del trigo. C++ es una implementacin (muy malapor cierto) del paradigma y lo difcil de usar no es el paradigma, es C++, que poco tiene quever con los objetos ms all de cmo se lo vendi.

3.4 -Mito 4: Conozco de objetos por qu se UMLOtras 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 decajitas 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 difcildemostrar que el modelo hecho con UML sea correcto o incorrecto.

UML no ensea a modelar, utilizar UML no implica crear buenos diseos, conocerUML no significa conocer objetos y para colmo de males, disear con UML nos obliga anosotros (mortales humanos) a hacer las veces de computadoras, ejecutando en nuestracabeza el modelo que estamos creando, lo cual produce como es de esperar, un modeloplagado de errores y difcil de implementar. (Olvidemos por ahora el problema que implicamantener el cdigo sincronizado con los diagramas)

En muchas oportunidades me encuentro con esta confusin cuando estoy tomandoentrevistas de trabajo. Muchas veces a la pregunta si han trabajo con objetos he recibidocomo respuesta si, conozco UML, lo cual desacredita por completo al entrevistado.

No es mi intencin crear otra polmica, pero hasta en ciertas ocasiones trabajarcon UML perjudica la obtencin de buenos modelos. Principalmente porque la tcnica dediseo que se aconseja utilizar con UML hace hincapi en el modelo esttico (diagrama declases) del problema y no en el ms importante, el dinmico (diagrama de secuencia ocolaboraciones). En objetos es ms importante saber cmo colaboran los objetos que lasclases que componen el modelo. Recuerden la definicin de programa.

Si usted cree que alcanza con un diagrama de clases hecho en UML paraimplementar 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 deentidad-relacin del paradigma relacional, que nada tienen en comn (por empezar son deparadigmas distintos).

En objetos la modelizacin del problema se debe hacer de manera incremental y lamejor tcnica que conozco para este tipo de modelizacin es la denominada TestDevelopment Driven (TDD) [Beck 02] que como es de esperar, rechaza la idea de sentarsea realizar grandes e improductivas sesiones de diseo que terminan en diagramas UMLalejados de la realidad.

Segn mi opinin, UML es una buena herramienta para comunicar un modeloterminado, no para crearlo.

3.5 -Mito 5: Los objetos no tienen buena performanceOtra disyuntiva que se presenta constantemente sobre los objetos es el tema de la

performance. Varias veces aparece la performance como problema de esta tecnologa, perodebemos nuevamente separar correctamente la paja del trigo.

Es verdad que utilizar objetos consume ms recursos que utilizar lenguajesprocedurales como C, pero C consume tambin ms recursos que Assembler, y una base dedatos relacional consume ms recursos y es ms lenta que archivos VSAM. Todos sabemosesto. Es el precio que hay que pagar cuando utilizamos tecnologa que nos alivia de ciertastareas dandol mayor responsabilidad a la computadora.

No debemos asustarnos de esta realidad la cual en definitiva nos conviene comoseres humanos, porque cuanto ms trabajo realice la computadora mejor. La computadoranunca se cansa, nunca se equivoca, mientras que nosotros s. No tengamos miedo en pedirlems esfuerzo a la computadora, para eso estn! Es slo cuestin de meses para quedupliquen su velocidad de procesamiento. La mantenibilidad y ampliacin de un sistema noes 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 nosignifica que sea ms lenta. La performance de una solucin es afectada por distintoselementos y uno muy importante de ellos es el diseo. La mayora de los sistemas quetienen problemas de performance se debe a problemas endmicos en su diseo, por ello lafamosa frase tiremos todo y empecemos de nuevo. Una solucin mal diseadadificilmente performee bien cuando quiera ser utilizada en situaciones no previstas.

Debemos tambin hacer nuevamente la salvedad entre paradigma eimplementaciones del paradigma. El paradigma nunca podra tener problemas deperfomance puesto que es conceptual. Pueden tener problemas de performance o recursossus implementaciones.

Actualmente estamos sufriendo estos problemas con Java y .Net, puesto que paradesarrollar en estos lenguajes con un IDE digno debemos tener como mnimo 256 MB dememoria. El problema entonces es del paradigma? No!, el problema es de estoslenguajes. Un contraejemplo valida mi aseveracin. Cualquiera de los Smalltalkcomerciales funciona correctamente en mquinas de 64 MB, y algunos hasta en mquinasde 16 MB. El problema no es el paradigma, nuevamente vemos que el problema est en loslenguajes 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 paradisear (objetos y mensajes) nos permiten obtener un modelo cuyo gap semntico con larealidad es mnimo.

Por qu es bueno tener un modelo fiel de la realidad?, porque aplicar los cambiosque se produzcan en la realidad en un modelo fiel a esta ser ms sencillo y menostraumtico que un modelo peleado con la realidad.

Cuando el paradigma de objetos es utilizado correctamente, se pueden atacarproblemas esenciales del software6 con buenos resultados. Si se modela bien la realidad, elmodelo ser sencillo y se habr atacado la complejidad del software. Si se modela bien larealidad, los cambios que se produzcan en esta impactarn de manera proporcional ennuestro modelo. A cambios sencillos de la realidad podremos ofrecer soluciones sencillasen nuestro sistema, y por ende de bajo costo.

Pero generalmente este tipo de explicaciones no alcanzan o no se terminan deapreciar hasta que no se viven, por eso ciertas veces cuando me preguntan por quobjetos?, no encuentro mejor respuesta que otra pregunta, por qu no objetos? Todas lasveces que discut sobre este tema llegu a la conclusin que no hay razones tcnicas vlidaspara no trabajar con objetos. Puede haber razones que corresponden ms al sector humanoo administrativo de todo proyecto de software por el cual no sea conveniente trabajar conobjetos, como la falta de experiencia en la tecnologa o recursos escasos.

Trabajemos con objetos o no, estamos usando la misma herramienta para ejecutarnuestros sistemas: computadoras que se comportan como mquinas de Turing. El nivel deexpresividad de los lenguajes que existen para desarrollar cdigo que luego es ejecutadopor estas mquinas es exactamente el mismo, sea Assembler, C++ o Smalltalk. Ladiferencia est en cuanto cuesta resolver el mismo problema con cada uno de estoslenguajes.

Si concordamos que un programa no es ms que un modelo computacional de larealidad entonces debemos concluir que ser ms sencillo hacer programas con aquelloslenguajes que permitan modelar la realidad fcilmente, con aquellos lenguajes con los quepueda crear mejores abstracciones. Estos lenguajes son los que implementan el paradigmade objetos y entre ellos el ms productivo segn mi experiencia, es Smalltalk (que es msque un lenguaje, es un ambiente de objetos).

Entonces, por qu no objetos? Creo que el nico motivo vlido sera el no quererpagar 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 lospuentes 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 tengaque hacer su primer sistema, concntrese en la realidad que tiene que resolver, es assolamente como podr tener xito utilizando objetos.

AgradecimientosQuera agradecer fundamentalmente a mi gran maestro del desarrollo con objetos,

Lic. Mximo Prieto, que sin su ayuda y conocimiento hubiese sido imposible tener estosconceptos 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 pocoms sobre los problemas del desarrollo de software.

Tambin un agradecimiento especial al grupo de objetos de la UBA, con quienesdiscutimos constantemente sobre objetos y cuyas ideas estn volcadas a lo largo de esteartculo.

Referencias[Beck 02] K. Beck. Test Driven Development: By Example, Addison-Wesley,

ISBN: 0321146530, 2002.[Kay 93] A. Kay. The Early History of Smalltalk. In proceeding of ACM

SIGPLAN VOL. 28 No. 3 Marzo 93 pp.69 75.[Smith 95] R. B. Smith, D. Ungar. Programming as an Experience: The Inspiration

for Self. In proceeding of ECOOP '95 Conference, Aarhus, Denmark, August, 1995.

[UML xx] www.uml.org

Sobre el autorEl 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 DiseoAvanzado con Objetos de la Facultad de Ciencias Exactas de la U.B.A.