Orientacin a objetos: Conceptos y terminologa

ORIENTACIN A OBJETOS: CONCEPTOS Y TERMINOLOGA (PARTE 1)

Miguel ngel Abin Copyright (c) 2003, Miguel ngel Abin. Este documento puede ser distribuido solo bajo los trminos y condiciones de la licencia de Documentacin de javaHispano v1.0 o posterior (la ltima versin se encuentra en http://www.javahispano.org/licencias/).
Abstract: This paper, divided in two parts, provides an introduction to Object-Oriented (OO) terminology and its concepts. It introduces terms and core concepts to ObjectOrientation from a conceptual point of view, giving formal, intuitive and manageable definitions. There is also a comparison with the structured paradigm. Keywords: Object Oriented Terminology, Object Oriented Programming, Object Orientation, Classes, Objects, Software Analysis, Software Design, Learning Object Orientation, Object Orientation Paradigm, Structured Paradigm

Los objetos en el sentido de la OO han estado presentes entre nosotros desde que se desarroll la conciencia en la especie humana, pero se han tardado miles de aos en aprovecharlos como tcnica. Cunto tiempo ms se necesitar para extraer el mximo rendimiento de la OO? [...] Quiz necesitemos un cambio conceptual antes que una sucesin frentica de cambios tcnicos. Howard Humphrey, 2002 Cualquier programador lo suficientemente persistente y empecinado conseguir escribir cdigo al estilo Fortran Cobol en cualquier lenguaje de programacin que utilice. Annimo. Odo en la Universidad de Valencia

1. Introduccin. El porqu de este artculo. El propsito de este artculo, que se presenta dividido en dos partes, es realizar una introduccin a la orientacin a objetos (OO), incluyendo sus conceptos y terminologa. No se pretende dar nicamente definiciones formales de los conceptos, sino tambin presentarlos de una forma fcilmente inteligible e intuitiva, pero no exenta de precisin. El lector juzgar si se ha conseguido. En la primera parte se exponen, de manera introductoria, los fundamentos de la OO, su comparacin con la metodologa estructurada, los motivos de su xito y en la segunda se expondrn en detalle los conceptos bsicos de la misma (objetos, clases, etc.). Deliberadamente, el artculo est centrado en conceptos y definiciones de la OO, y no en su aplicacin a lenguajes de programacin concretos, por los siguientes motivos:

http://www.javahispano.org - El anlisis y diseo orientado a objetos no tiene por qu estar ligado necesariamente a sistemas de software o de informacin. - En sistemas de software la orientacin a objetos no est exclusivamente asociada a lenguajes de programacin concretos (aunque se presenten como lenguajes OO): es una metodologa independiente del lenguaje utilizado, aunque hay lenguajes que cuentan con mejores mecanismos que otros para poder aplicar eficientemente esta metodologa. Utilizar la OO es ms que programar en uno o varios lenguajes de programacin, es usar la OO como filosofa de desarrollo. - En el desarrollo de software, los lenguajes OO por s mismos, sin la compresin de lo que hay tras ellos y sin haber conseguido la reorientacin filosfica en la prctica del diseo y uso de software que requiere la OO, no son ms que coches sin motores. - Por experiencia propia, s que existe una gran diferencia entre comprender los fundamentos de la orientacin a objetos y aplicarlos con xito: es el eterno salto en el vaco entre la teora y la prctica. Ahora bien, no comprender previamente los fundamentos de la OO y sus sutilezas, y utilizar lenguajes OO es encaminarse hacia un desastre casi seguro cuando el problema que se aborda es de cierta envergadura. A lo largo de diez aos he visto, en programas de compaeros y clientes, clases con miles de lneas y decenas de mtodos estticos, clases compuestas slo por mtodos, clases con cohesin tan fuerte que volvan el cdigo completamente irreutilizable, usos de la herencia que derivaban en cdigo confuso e inestable... Me consta que no son hechos aislados, cualquier programador o analista que tenga cierta experiencia puede referir hechos similares, si no calcados. El motivo de estos fallos conceptuales suele ser ste: el programador ha pasado de utilizar un lenguaje estructurado a uno presuntamente orientado a objetos sin tener claros o haber madurado los conceptos de la OO. Aparentemente son conceptos muy sencillos... pero solo aparentemente. Intentar continuar, consciente o inconscientemente, con un enfoque estructurado de programacin en lenguajes OO puede hacerse, al igual que puede escribirse con una pluma de ave y tinta china, pero no es lo ms adecuado. Suscribo por completo las palabras de Wolfgang Strigel cuando escribe ... Los conceptos bsicos de la OO se conocen desde hace dos dcadas, pero su aceptacin todava no est tan extendida como los beneficios que esta tecnologa puede sugerir y ...La mayora de los usuarios de la OO no utilizan los conceptos de la OO de forma purista, como inicialmente se pretenda. Esta prctica ha sido promovida por muchas herramientas y lenguajes que intentan utilizar los conceptos en diversos grados (la negrita es ma).

2. Definiciones previas. A continuacin se presentan las definiciones de trminos de uso frecuente en lo que sigue, y que vale la pena definir al menos una vez para evitar confusiones o ambigedades. [Las definiciones de Clase y Objeto son temporales y se concretarn ms detalladamente en la segunda parte del artculo]

Orientacin a objetos: Conceptos y terminologa Anlisis: Proceso que permite pasar del sistema real a un modelo conceptual. Clase: Conjunto de objetos que tienen en comn la misma estructura y comportamiento. Diseo: Proceso que especifica la implementacin de un sistema a partir de un modelo conceptual de ste. Ingeniera de software: Disciplina cuyo propsito es la produccin de software libre de fallos, dentro del plazo previsto, cumpliendo el presupuesto inicial, y que satisfaga las necesidades del usuario o cliente. Ingeniero/a de software: Persona que aplica las tcnicas de la ingeniera de software y que, a menudo, tiene que afrontar con tranquilidad de espritu, mirada resignada y autocontrol Zen las reducciones de los plazos de entrega, los recortes en el presupuesto original y las modificaciones sustanciales y sin previo aviso de los requisitos iniciales. Mensaje: Estmulo enviado a un objeto con un nombre y los parmetros adecuados que provoca que el objeto comience cierto comportamiento al ejecutar una operacin. Metodologa: Sinnimo de paradigma. Modelo: Abstraccin que describe el sistema bajo estudio. (Un modelo puede consistir en diagramas ms los textos, notaciones o aclaraciones necesarias para entenderlos) Objeto: Entidad con identidad propia y capaz de exhibir un comportamiento. Estructura de datos encapsulada con un conjunto de operaciones que operan sobre los datos. Operacin: Descripcin de la habilidad de un objeto para responder a un mensaje y de los requisitos para ese mensaje. (Su imple mentacin se denomina mtodo) Paradigma: Estrategia o punto de vista para realizar tareas. Coleccin de tcnicas para resolver problemas. Marco conceptual. Matriz disciplinaria. [Su significado profundo, segn Kuhn, se ver en el Apdo. 6] Sistema: Parte del mundo real bajo estudio. Conjunto de cosas (reales o abstractas) que forman un todo de acuerdo con cierto plan o propsito.

3. Races de los conceptos de la OO. La orientacin a objetos como filosofa de desarrollo de sistemas. Comparacin con el paradigma estructurado. Pese a que el trmino orientacin a objetos ejerce una innegable fascinacin para muchos ingenieros de software, gran parte de sus conceptos distan mucho de ser nuevos. Algunos, incluso, forman parte de la tradicin cultural occidental casi desde sus inicios: Platn y Aristteles usaron ya en sus escritos trminos como objetos, clases, subclases, clasificaciones, etc. (Posiblemente Aristteles llevara demasiado lejos el concepto de clase: clasific dentro del mismo grupo a la cotorra y la lechuga, pues ambas son verdes) Ya a principios del siglo XX, matemticos lgicos eminentes como Whitehead y Lord Russell, formalizaron y ampliaron los anteriores conceptos, tratando de dar (infructuosamente) una base lgica auto-consistente a la matemtica. Las definiciones lgicas y filosficas de estos conceptos han influido mucho en la terminologa OO. Por ejemplo, en Principia Mathematica [Whitehead & R, 1910] se define clase como una coleccin de objetos a los que se aplica un concepto, y esta misma definicin fue la que inspir el trmino clase en la OO e influy en el desarrollo de los lenguajes de programacin SIMULA I (1962-65) y Simula 67 (1967), cuya influencia conceptual subyace en todos los modernos lenguajes OO. Lo anterior no tiene un inters nicamente anecdtico o histrico: los conceptos matemticos, lgicos y filosficos permiten expresar con exactitud y sin ambigedades lo que hoy en da se considera orientacin a objetos. Adems, la OO (y, por tanto, el software OO) evo lucionar con el tiempo hacia caminos an inciertos y son los

http://www.javahispano.org conceptos lgico- matemticos y filosficos los que podrn seguir usndose para elaborar lo que llamar orientacin a objetos no estndar e incluso para elaborar nuevos mtodos de anlisis y diseo de parentesco remoto con la orientacin de objetos. Si existe algo parecido a la inmortalidad, las ideas matemticas lo tienen: las ideas de Pitgoras pervivirn ms que las obras de Shakespeare y seguirn vigentes cuando los actuales lenguajes de programacin no sean ms que notas a pie de pgina. Aunque, todava hoy, suele asociarse la orientacin a objetos a determinados lenguajes de programacin (Java, C++, Eiffel, etc.) es mayoritaria la opinin de que la OO es una filosofa general o metodologa de desarrollo de sistemas (informticos o no). La orientacin a objetos puede aplicarse a la ingeniera de procesos, de redes, de productos, a la gestin empresarial, etc. El enfoque o la perspectiva OO considera los sistemas como colecciones de objetos capaces de interactuar entre s, que trabajan conjuntamente para realizar tareas. El anlisis OO define todos los tipos de objetos que modelan el sistema (es decir, que realizan las funciones de inters del sistema) y muestra cmo interaccionan. El diseo OO define todos los tipos de objetos adicionales que se necesitan para comunicarse con el exterior del sistema y se encarga de perfilar o de refinar los tipos de objetos de cara a una posterior implementacin.

ORIENTACIN A OBJETOS

La orientacin a objetos permite ver y modelar el mundo como un conjunto de objetos que intercambian mensajes entre s
Miguel ngel Abin, Nov. 2002

Figura 1. La orientacin a objetos como metodologa de uso general en nuestro mundo Cuando se consideran especficamente sistemas de software, el paradigma orientado a objetos consiste en el anlisis OO, el diseo OO y la programacin OO; es una metodologa de la ingeniera del software que considera los sistemas de software desde la perspectiva OO descrita en el primer prrafo de este apartado. La programacin OO es cualquier tcnica de desarrollo de software que incluya el diseo OO obtenido, por lo general, a partir de un anlisis OO- y que permita producir programas OO (programas que consisten en un conjunto de objetos capaces de comunicarse entre s).

Orientacin a objetos: Conceptos y terminologa El paradigma OO fue el paradigma emergente en la dcada de los 90 (en el sentido que expone Kuhn en La estructura de las revoluciones cientficas [Kuhn, 1971] y que se detallar en el apartado 6) y es ahora el paradigma aceptado por la industria y la investigacin. Dado que estamos en un contexto ms aplicado que el de la ciencia pura, su permanencia como paradigma depender de que resuelva con xito problemas reales, sin plantear ms problemas (y gastos) de los que efectivamente resuelva (y ahorre).

PROGRAMACIN ORIENTADA A OBJETOS

La programacin orientada a objetos permite construir modelos de objetos en el mundo real usando objetos de software
Miguel ngel Abin, Nov. 2002

Figura 2. La programacin orientada a objetos como tcnica de desarrollo de software Antes de comenzar con los fundamentos de la orientacin a objetos, conviene mencionar a su oponente (el paradigma anterior a la OO y que se encuentra en proceso de cambio): El anlisis y diseo estructurado (o funcional) construye modelos basados en el procesamiento de datos. Una persona que utilice este enfoque intentar dividir el problema bajo estudio identificando una serie de procesos, manipulaciones o tratamientos de datos (llamados funciones o procedimientos en las fases de diseo e implementacin) que, organizados de modo que puedan llamarse unos a otros, proporcionen la solucin. Siempre existe una separacin entre datos y procesos: los procesos manipulan y usan datos, pero no se integran con ellos. El paradigma estructurado (anlisis estructurado + diseo estructurado + programacin estructurada) en la ingeniera de software se basa en la abstraccin por descomposicin funcional o por procedimientos: el problema estudiado se descompone en una serie de capas sucesivas de procesos, hasta que finalmente se descompone en procesos relativamente fciles de implementar y codificar (desarrollo top-down). Un programa estructurado se divide en unidades lgicas (mdulos) mediante el uso de funciones y procedimientos; los detalles ms internos del programa residen en los mdulos de ms bajo nivel y los mdulos de ms alto nivel se encargan del control lgico del programa. El paradigma estructurado mantendr su vigencia, posiblemente, por cierto tiempo en la ingeniera del software pues muchas aplicaciones informticas de gestin utilizan mayoritariamente pseudoobjetos u objetos que no pueden considerarse objetos de pleno

http://www.javahispano.org derecho (por ejemplo, objetos sin atributos u objetos sin mtodos), generalmente asociados a las estructuras tradicionales de datos. A la vista de la Tabla 1 se aprecia uno de los defectos m s comnmente sealados por los crticos del paradigma estructurado: la separacin clara e insalvable entre el anlisis y el diseo, es decir, entre lo que se quiere que haga el sistema y cmo lo hace. En el paradigma OO la frontera entre el anlisis y el diseo es difusa, y los objetos se introducen desde el principio. Es ms natural pasar del anlisis a la implementacin en el paradigma OO que en el estructurado: el salto conceptual es menor en aqul.

Paradigma estructurado

Paradigma orientado a objetos

Etapa de anlisis: se determina qu Etapa de anlisis OO: se determina debe hacer el sistema a construir. qu debe hacer el sistema a construir y se extraen los objetos. Se modela el espacio del problema mediante notacin OO. Etapa de diseo: se extraen funciones o Etapa de diseo OO: se perfecciona el procedimientos (muy vinculados con los diseo, afinndose las caractersticas de datos con los que se va a trabajar y poco los objetos. naturales para el modo de pensar huma- Muchas veces esta fase puede ser omitino: no pensamos mediante algoritmos). da conociendo las especificaciones del Esta fase no puede omitirse. anlisis OO. Etapa de implementacin: se imple- Etapa de implementacin OO: se mentan las funciones en un lenguaje de implementan los objetos en un lenguaje programacin adecuado. de programacin orientado a objetos. Tabla 1. Comparacin entre el anlisis, el diseo y la implementacin en los dos paradigmas. La conversin de los trminos del anlisis OO hacia construcciones en lenguajes de programacin OO es bastante directa, lo que constituye una importante ventaja sobre el paradigma estructurado.

Orientacin a objetos: Conceptos y terminologa

Sistema real
El poder saltarse en ocasiones la etapa de diseo, favorece la creacin de prototipos rpidos OO sobre los cuales hacer pruebas

Modelo conceptual OO Modelo de diseo OO Implementacin OO

Miguel ngel Abin, Nov. 2002

Figura 3. Muchas veces se pueden hacer prototipos rpidos en el paradigma OO, sin tener que pasar por la etapa de diseo. En el paradigma estruc turado no puede evitarse la etapa de diseo. Algunos autores consideran que el enfoque OO ha evolucionado a partir del enfoque estructurado y otros que es un salto revolucionario, cualitativo ms que cuantitativo. Desde luego, los partidarios del salto revolucionario suelen ser firmes partidarios de la OO, cuando no creadores de metodologas OO. As, en la obra ObjectOriented Modeling and Design [Rumbaugh et al, 1991] se considera que el diseo orientado a objetos es una nueva forma de pensar en los problemas usando modelos sobre conceptos del mundo real y, en Ingeniera del Software. Un Enfoque prctico [Pressman, 1992], Pressman refiere que diferencia de otros mtodos de diseo, el a diseo orientado a objetos da como resultado un diseo que interconecta los objetos de datos y las operaciones, de forma que modulariza la informacin y el procesamiento en vez de slo la informacin. La naturaleza del diseo orientado a objetos est ligada a tres conceptos bsicos: abstraccin, modularidad y ocultacin de la informacin. Mi opinin, dado que no hay un acuerdo unnime, es que realmente el enfoque OO utiliza abstracciones no presentes en el enfoque estructurado y que no admiten equivalencia. Ntese que estoy hablando en trminos conceptuales, no de lenguajes de programacin. Tericamente todo lo que podra hacer un lenguaje OO podra hacerlo un lenguaje estructurado. De hecho, las primeras versiones de C++ utilizaban una traduccin previa a C mediante un preprocesador antes de la compilacin, de ah su lentitud. Incluso un lenguaje puro OO como Eiffel permite la traduccin del cdigo Eiffel a cdigo C.

4. Fundamentos de la orientacin a objetos El paradigma orientado a objetos se fundamenta en los siguientes principios:

http://www.javahispano.org

- Abstraccin - Modularidad - Encapsulacin o encapsulamiento - Jerarqua

4.1. Abstraccin.

La abstraccin es una aproximacin o abordaje del diseo que hace hincapi en los aspectos ms importantes de algo, sin preocuparse por los detalles menos importantes. De acuerdo con el Dictionary of Object Technology: The Definitive Desk Reference [Firesmith & E, 1995], la abstraccin es Cualquier modelo que incluye los aspectos ms importantes, esenciales o distinguibles de algo mientras suprime o ignora los detalles menos importantes, inmateriales o que pueden distraer. La abstraccin es especfica del dominio (rea seleccionada de inters). La abstraccin Persona es distinta en el dominio Censo electoral que en el dominio Hospital. Quiz el ejemplo ms grfico de lo que es una abstraccin lo d el cuadro La trahison des images del pintor surrealista belga Ren Magritte (1898-1967). En l aparece dibujada una pipa y bajo ella aparece la frase Ceci nest pas une pipe (Esto no es una pipa) escrita con caligrafa escolar. Efectivamente, el dibujo es una abstraccin o representacin conceptual de una pipa, no una pipa (cun sutiles solan ser los surrealistas). En el cuadro se ha perdido la tridimensionalidad de la pipa real, sus pequeas imperfecciones, pero se han mantenido la mayor parte de sus caractersticas fundamentales (forma, etc.). En ese sentido, el dibujo de la pipa es una buena abstraccin o un buen modelo de una pipa real. En la ingeniera del software y en la OO es fundamental comenzar desde el principio con buenas abstracciones o modelos del problema que vaya a ser abordado.

Figura 4. La traicin de las imgenes de Ren Magritte (1926) Cuando la abstraccin se confunde con la realidad: Es esto una pipa? Si fuera de verdad una pipa, no debera poder encenderse y echar humo?

Orientacin a objetos: Conceptos y terminologa

4.2. Modularidad

Informalmente, es la descomposicin de un proceso complejo en subprocesos ms sencillos y manejables. Segn el Dictionary of OT la modularidad es La descomposicin lgica de las cosas (por ejemplo, responsabilidades y software) en agrupaciones simples, pequeas (por ejemplo, requisitos y clases, respectivamente), que aumentan las posibilidades de lograr las metas de la ingeniera de software. Cuando nos restringimos a software, un mdulo es un conjunto de sentencias bajo el paraguas de un nombre por el cual puede ser llamado o invocado. Los mdulos seran la unidad de programacin. En Java, una clase sera un mdulo. Las caractersticas deseables de un mdulo, aunque no detalladas en la definicin del Dictionary of OT, seran las siguientes: - Alta cohesin; entendiendo la cohesin como una medida del grado de relacin funcional interna de los componentes de un mdulo. - Bajo acoplamiento; entendiendo el acoplamiento como una medida de la interconexin entre mdulos. Ambos conceptos (cohesin y acoplamiento) no son absolutamente rgidos y no admiten una cuantificacin milimtrica. Adems, no son totalmente independientes: generalmente aunque no siempre- una alta cohesin de un mdulo implica bajo acoplamiento del mismo con respecto a otros.

http://www.javahispano.org

4.3. Encapsulacin o encapsulamiento

Llanamente, la encapsulacin es el ocultamiento de la informacin. Segn el Dictionary of OT es localizacin fsica de las propiedades dentro de una sola La abstraccin de caja negra que oculta su implementacin (y las decisiones asociadas de diseo) tras un interfaz pblico. La abstraccin de caja negra es utilizada ampliamente en fsica, electrnica e informtica y consiste en esconder todos los detalles internos del sistema que se estudia bajo una caja negra imaginaria, cuando sea ms importante comprender qu hace el sistema que cmo lo hace. El encapsulamiento es como introducir el sistema dentro de una caja negra con dos ranuras llamadas Entrada y Salida. Por ejemplo, en metrologa, cuando quiere calibrarse un dinammetro, no se estudia la incertidumbre que proporciona cada circuito, cada muelle, cada parte mvil, etc. (entre otras cosas porque el problema se tornara casi inabordable) y luego se combinan para obtener la incertidumbre del aparato. En la prctica, lo que se hace es considerar el dinammetro como una caja negra y se calibra viendo las lecturas (Salida) que da frente a fuerzas patrn (Entrada), olvidndose de sus componentes internos. As, por poner otro ejemplo lejano al campo de la informtica, un complejo circuito electrnico que forme parte de un sistema mayor puede ser substituido imaginariamente, para facilitar el estudio del sistema completo, por una caja negra que recibe una seal elctrica y devuelve otra. Es ms, el circuito podra caracterizarse por su funcin de transferencia (lo que hace) sin que fuera necesario conocer la forma en que modifica la seal de entrada (cmo lo hace) ni sus componentes. Del mismo modo, cuando en Java se utiliza la clase Vector, no es necesario saber qu operaciones internas realiza para aadir o eliminar elementos; es ms, si se necesitara conocerlas se estara violando el principio de encapsulamiento.

Seal entrada

La caja negra oculta los componentes internos (la implementacin)

Seal salida
Miguel ngel Abin, Nov. 2002

Figura 5. La encapsulacin es una herramienta poderosa en muchos campos

10

Orientacin a objetos: Conceptos y terminologa

Los conceptos de abstraccin y encapsulacin no son conceptos independientes, sino complementarios: la abstraccin hace referencia al comportamiento observable de un objeto, mientras la encapsulacin hace referencia a la implementacin que le permite alcanzar este comportamiento. Desde el punto de vista de la ingeniera de software, la propiedad de la encapsulacin se traduce en que los objetos de software son inaccesibles directamente para otros objetos. Esta inaccesibilidad directa hace que un objeto deba comunicarse con otros (o, lo que es lo mismo, intercambiar informacin) a travs de mensajes con los nombres y parmetros adecuados. La encapsulacin ser correcta cuando la interfaz que se muestra al pblico cumpla las tareas que desea el cliente y no muestre ms de lo que ste precisa. Un encapsulamiento correcto siempre separa las vistas que del sistema tienen el constructor y el usuario. Resulta llamativo que el trmino encapsulacin provenga, precisamente, de la ingeniera electrnica. Pero esta coincidencia de terminologa, al igual que el ejemplo del circuito electrnico de la pgina anterior, no es ni mucho menos casual. La ingeniera electrnica aplicada a la construccin de ordenadores siempre ha trabajado, una vez pasada la poca de tubos de vaco, con componentes (cpsulas) en los que se integran otros muchos componentes. Sus principales avances han sido tecnolgicos: cada vez caben ms componentes por unidad de superficie, pero siempre ha estado presente implcitamente un concepto primordial: la reutilizacin. Resultara inaceptable que se estropeara un componente electrnico y que hubiera que construir otro idntico desde la nada o que nuevos componentes tuvieran que desarrollarse necesariamente combinando resistencias, condensadores y bobinas, sin poder aprovechar nada de todos los componentes ya fabricados, o que fuera imprescindible conocer todos los elementos de un componente antes de poder saber para qu podra ser til. El considerar los objetos como cpsulas facilita enormemente que un objeto ya implementado pueda ser transportado a otras partes del sistema del que forma parte o a otros sistemas. En principio, un objeto correctamente diseado y construido debera seguir realizando sus tareas (mediante los mtodos) en cualquier otro sistema. Antes de que los conceptos de modularidad y encapsulacin tuvieran la importancia capital que tienen hoy en la ingeniera de software (hasta mediados de la dcada de los 70, aproximadamente, no se empez a hacer un uso intensivo de la encapsulacin) suceda algo similar en la programacin: empezar un nuevo programa era, a menudo, comenzar desde cero y la reutilizacin de componentes de programacin era mnima. En los pocos casos en que se podan reutilizar estos componentes de programacin era necesario conocer cmo funcionaban por dentro, lo que tornaba imposible la encapsulacin.
4.4. Jerarqua

Segn el Dictionary of OT es Cualquier clasificacin u ordenacin de abstracciones en una estructura de rbol. Tipos: Jerarqua de agregacin, jerarqua de clases, jerarqua de herencia, jerarqua de particin, jerarqua de especializacin, jerarqua de tipo. La jerarqua se ha utilizado ampliamente desde hace muchsimo tiempo en las ciencias naturales para clasificar a los seres vivos. Con ello no quiero decir que los

11

http://www.javahispano.org primeros botnicos o zologos pudieran ser, de haber vivido en esta poca, unos extraordinarios programadores, sino que entendieron desde el principio la importancia de dividir los problemas en una jerarqua de ideas. Quiz Aristteles fuera un poco desencaminado en cuanto a los detalles (vase apdo. 3), pero andaba bastante acertado en cuanto a las ideas generales.
Programador Trabajador Persona Mamfero Animal Ser vivo
Miguel ngel Abin, Nov. 2002

Figura 6. Un ejemplo de jerarqua De modo general, la herencia es el principio de que las propiedades de una categora general se transmiten para todas las categoras que especializan la categora general. En sistemas de software el trmino herencia designa la facultad de los objetos de compartir propiedades y operaciones entre ellos. Un subobjeto u objeto derivado es una extensin de un objeto base que hereda parte o todas las caractersticas del objeto base o padre. El objeto derivado u objeto hijo aporta especializacin al objeto base, pudiendo redefinir determinados mtodos y/o aadir nuevos mtodos y atributos que slo estarn disponibles para sus objetos derivados. Existe una tensin esencial entre los conceptos de encapsulamiento de la informacin y jerarqua de herencia, que requiere como solucin una apertura en el acceso a la informacin pues necesariamente un objeto derivado debe conocer al menos parte de la informacin contenida en el objeto base. Muy relacionado con la herencia, se encuentra el polimorfismo. Aunque se tratar con detalle en la 2 parte del artculo, puede adelantarse que el polimorfismo permite redefinir mtodos en objetos derivados que sobrescriban a los del objeto base. Como se vio en el apartado 3, el paradigma estructurado se basa en la abstraccin por descomposicin. El paradigma orientado a objetos incluye tambin la descomposicin como un mecanismo de abstraccin, pero la complementa con la herencia, que se basa en la abstraccin por clasificacin. En mi opinin la abstraccin por clasificacin no tiene equivalente en el paradigma estructurado y constituye, por tanto, una caracterstica novedosa de la OO. A fecha de hoy el debate de la evolucinrevolucin de la OO frente al paradigma estructurado contina abierto. La herencia es responsable, combinada con el encapsulamiento, en gran medida del xito de la programacin OO al permitir la reutilizacin del cdigo OO. La correcta utilizacin de la herencia y el encapsulamiento permite concebir los programas OO 12

Orientacin a objetos: Conceptos y terminologa como una unin de cpsulas (objetos) intercambiables con otros programas y que pueden transmitir sus propiedades (atributos y mtodos) a nuevas cpsulas sin tener que desarrollarlas desde cero. Por otro lado, el cambio de implementacin de una cpsula no implicar cambios en la implementacin de otras con las que se relacione, siempre que se mantengan intactos los mtodos por los que se comunican. En los sistemas de software el mantenimiento ha supuesto siempre el coste ms importante de los sistemas. La herencia y el encapsulamiento permiten reducir el coste de las modificaciones, casi siempre inevitables, que deben ir sufriendo los programas al contacto con la realidad.

5. Lenguajes de programacin orientados a objetos. Puede utilizarse la OO en lenguajes no orientados a objetos? Al considerar sistemas de software, la programacin OO implica habitualmente (pero no necesariamente) el uso de lenguajes de programacin orientados a objetos. Como metodologa, la OO es independiente de cualquier lenguaje, sea orientado a objetos o no. El anlisis y diseo OO puede aplicarse en teora- a cualquier lenguaje de programacin. No existe un acuerdo comn e inapelable en la bibliografa sobre los requisitos que debe cumplir un lenguaje para considerarse OO, pero generalmente se admite que un lenguaje OO debe tener como mnimo: a) Encapsulacin b) Herencia c) Polimorfismo [Este trmino se estudiar en la segunda parte del artculo] Adicionalmente, en un lenguaje OO puede suceder que: d) Todos los tipos de datos predefinidos en el lenguaje sean objetos e) Todos los tipos de datos que puedan ser definidos por los programadores sean objetos f) Todas las posibles operaciones se realicen enviando mensajes entre objetos Se consideran lenguajes OO puros aquellos que tienen las 6 caractersticas a)- f) y se consideran hbridos aquellos que carecen de alguna de las 3 ltimas: d), e) f). Caracterstica Fortran 77 C++ C# Java Smalltalk Eiffel a) NO SI SI SI SI SI b) NO SI SI SI SI SI c) NO SI SI SI SI SI d) NO NO NO NO SI SI e) NO NO NO SI SI SI f) NO NO NO NO SI SI Tabla 2. Ejemplos de lenguajes no OO, OO hbridos y OO puros. Es importante resaltar que cualquier programa que se realice con un lenguaje orientado a objetos (hbrido o puro) podra realizarse con un lenguaje estructurado o no orientado a objetos. Es ms, se podran escribir programas verdaderamente orientados a objetos (es d ecir, en los que se usara abstraccin, encapsulacin, etc.) usando un

13

http://www.javahispano.org lenguaje de desarrollo no OO. El programador debera implementar las principales caractersticas de la OO en el lenguaje seleccionado (convertir en objetos las estructuras de datos propia del lenguaje no OO, almacenarlos en memoria, elegir cuidadosamente los nombres de los mtodos para asociarlos inmediatamente a los objetos correspondientes, implementar la herencia y el polimorfismo, ...), proceso innecesario en un lenguaje OO pues ya posee de partida esas implementaciones. En la prctica siempre ser ms rpido y eficiente trabajar directamente con lenguajes OO que implementar las caractersticas OO en lenguajes no orientados a objetos. Como ejemplo de lo dicho se va a implementar en Fortran 77 y C una clase Rectngulo y se implementar tambin la herencia para dos clases Circulo y Elipse que derivan de una clase Punto. Implementacin de la clase Rectngulo en Fortran 77 implicit none common /rectangulo/ x1, x2, y1, y2, num_rectangulo real x1(100), x2(100), y1(100), y2(100) integer num_rectangulo Este cdigo definira una clase Rectngulo, quedando cada rectngulo caracterizado por las coordenadas de sus vrtices. Se guardaran en memoria simultneamente 100 objetos de tipo rectngulo (en Fortran 77 no existe la asignacin dinmica de memoria) y el ndice entero num_rectangulo permitira identificar en todo momento cualquier objeto rectngulo. El bloque common permite que ciertas variables se comportan entre varias subrutinas. En Fortran 77 un objeto solo puede representarse por una coleccin de cadenas de variables, representando cada variable un atributo del objeto. No existen tipos de datos definidos por el usuario.

Implementacin de la clase Rectngulo en C struct rectangulo{ float x1; float x2; float y1; float y2; } Para iniciar un objeto rectngulo struct rectangulo miRectangulo={0, 2, 3, 5}

14

Orientacin a objetos: Conceptos y terminologa

Implementacin de la herencia en Fortran 77 con dos clases: Elipse y Crculo que derivan de una clase Punto

Implementacin de las clases Elipse y Crculo. implicit none common /figura/ x, y, semiejea, semiejeb, radio, num_figura, clase_figura real x(100), y(100), semiejea(100), semiejeb(100), radio(100) integer num_figura integer clase_figura(100) common /clases/ ELIPSE, CIRCULO integer ELIPSE /1/, CIRCULO /2/ Este modo sera muy ineficiente, pues reservara espacio en memoria tanto para los atributos de la clase base Punto (coordenadas x e y) como para los atributos adicionales de las clases derivadas Crculo (radio) y Elipse (semiejes), pero sirve como ejemplo del modo de trabajar en Fortran 77. Para crear objetos derivados o hijos, el cdigo sera similar a este: function crear_elipse(x0, y0, semiejea0, semiejeb0) integer crear_elipse common /figura/ x, y, semiejea, semiejeb, radio, num_figura, clase_figura real x(100), y(100), semiejea(100), semiejeb(100), radio(100) integer num_figura integer clase_figura(100) common /clases/ ELIPSE, CIRCULO integer ELIPSE /1/, CIRCULO /2/ num_figura=num_figura + 1 x(num_figura)=x0 y(num_figura)=y0 semiejea(num_figura)=semiejea0 semiejeb(num_figura)=semiejeb0 radio(num_figura)=0 clase_figura(num_figura)=ELIPSE crear_elipse=num_figura end

15

http://www.javahispano.org

function crear_circulo(x0, y0, radio0) integer crear_circulo common /figura/ x, y, semiejea, semiejeb, radio, num_figura, clase_figura real x(100), y(100), semiejea(100), semiejeb(100), radio(100) integer num_figura integer clase_figura(100) common /clases/ ELIPSE, CIRCULO integer ELIPSE /1/, CIRCULO /2/ num_figura=num_figura + 1 x(num_figura)=x0 y(num_figura)=y0 semiejea(num_figura)=radio0 semiejeb(num_figura)=radio0 radio(num_figura)=radio0 clase_figura(num_figura)=CIRCULO crear_circulo=num_figura end

Para implementar el polimorfismo bastara comprobar, dado un objeto (caracterizado por su num_figura), cul es el valor de clase_figura(num_figura) y, dependiendo de si es CIRCULO ELIPSE, asignarle un mtodo u otro.

Implementacin de la herencia en C con dos clases: Elipse y Crculo que derivan de una clase Punto struct punto{ float x; float y; }; struct circulo{ struct punto origen_figura; float radio; }; struct elipse{ struct punto origen_figura; float semiejea; float semiejeb; };

16

Orientacin a objetos: Conceptos y terminologa

Se ha escogido deliberadamente Fortran 77 para los ejemplos por ser un lenguaje primitivo -aunque extremadamente potente para aplicaciones que requieran clculos numricos intensivos- en comparacin con los lenguajes de programacin actuales. Sera el equivalente informtico a un mamut lanudo que hubiera escapado de una glaciacin y perviviera en nuestros das. Para ser justos, hay que aadir que la versin anterior (Fortran 66) se utilizaba con tarjetas perforadas y que las versiones actuales (Fortran 90 y 95) s incorporan asignacin dinmica de la memoria y punteros, tipos de datos definidos por el usuario, mdulos en el sentido de la OO- y otras caractersticas. Al ser un lenguaje que tiene un nico tipo de estructuras de datos (matrices) resulta posible, pero muy complicado e ineficaz, implementar los principios de la OO. En C resulta mucho ms fcil, porque permite al programador definir sus propias estructuras de datos y el uso de la asignacin dinmica de la memoria hace que se aproveche mucho ms eficientemente la memoria que en Fortran 77. En resumen, aunque la manera ms cmoda, rpida y eficiente de realizar programas orientados a objetos es utilizar lenguajes OO, ya sean puros o hbridos, resulta posible aprovechar el anlisis y diseo OO en implementaciones con lenguajes no orientados a objetos.

6. l xito del paradigma orientado a objetos: basado nicamente en criterios objetivos? Factores extracurriculares. Lo que la OO no puede hacer Una vez expuestos los fundamentos de la OO y antes de definir detenidamente los conceptos de la misma es interesante reflexionar sobre el xito de la OO desde una perspectiva poco ortodoxa y un tanto hertica. En su clebre libro La estructura de la revoluciones cientficas Thomas S. Kuhn defini paradigma en el sentido de matriz disciplinaria: elementos ordenados de diversas maneras, cuyo orden hay que especificar, que son posesin comn de los profesionales de una disciplina. Kuhn propona que cuando los cientficos observan determinados fenmenos no los miran objetivamente en realidad, sino a travs del filtro de un conjunto de ideas y conceptos (procedentes de la tradicin cultural, social y cientfica en la que han sido educados) que han formado/deformado su percepcin. Los ven a travs de un paradigma firmemente establecido. Solo as poda entenderse, segn Kuhn, que ideas como que la velocidad de cada de los cuerpos era proporcional a su masa hubieran pervivido desde la Grecia antigua hasta Galileo, cuando unos sencillos experimentos hubieran demostrado su falsedad. Segn sus ideas, los cientficos de todos esos siglos intermedios aceptaron la idea de que los cuerpos caan con una velocidad proporcional a su masa como parte de su paradigma, y por ello no se plantearon hacer experimentos ni vieron los hechos que iban en su contra. Por eso mismo, la idea de que la tierra era plana pervivi durante mucho tiempo, aunque numerosos hechos de la experiencia comn la invalidaban; la gente era educada en un sistema de creencias compartidas (paradigma) donde esa idea era aceptada. Generalmente siempre segn Kuhn- cuando un cientfico, o un grupo de cientficos, se coloca las gafas de un nuevo paradigma, el resto de la comunidad cientfica reniega y manifiesta su desacuerdo inicialmente hasta que el paradigma emergente demuestra su validez (mediante hechos empricos, permitiendo explorar nuevos programas de investigacin, solucionando con ms sencillez problemas ya conocidos o abordando nuevos problemas) y/o los viejos cientficos, educados en el

17

http://www.javahispano.org paradigma anterior, fallecen de viejos. En ocasiones un paradigma puede no ser intrnsecamente mejor que otro, pero la comunidad cientfica lo puede adoptar por encajar con una ideologa, una cultura o una preconcepcin del mundo. Al cabo de pocas generaciones todos los cientficos se educan ya en el nuevo paradigma y los conflictos conceptuales entre el paradigma antiguo y el nuevo son solamente recordados por filsofos o historiadores de la ciencia que mantienen hasta su defuncin apasionadas y encarnizadas batallas dialcticasbatallas que probablemente proseguirn, si es posible, en el lugar adonde vayan los filsofos al morir- sobre la respectiva superioridad o inferioridad de cada paradigma. Y as una y otra vez. Kuhn vena a decir que hay un componente sociolgico y cultural, ajeno a la pretendida ciega y asptica objetividad cientfica, en el modo en que los cientficos de una poca observan el mundo y en las razones por las que un paradigma se convierte en dominante sobre sus contrincantes, y que los paradigmas son consensos tcitos dentro de una comunidad (cientfica, tcnica, etc.). Sin lugar a dudas, la OO es un paradigma dentro de la comunidad de la ingeniera de software en el sentido de Kuhn expuesto arriba. La orientacin a objetos es el paradigma aceptado actualmente (aunque existen otros) en los sistemas de software y ha relevado al antiguo paradigma estructurado. Los estudiantes de ingeniera de software se forman ya en la OO, est incluida en los planes acadmicos, y sus trminos son de uso comn. Incluso el uso de lenguajes OO est desplazando a los lenguajes estructurados tradicionales que se utilizaban en las asignaturas de introduccin a la programacin. Por qu se ha impuesto como paradigma la orientacin a objetos? En gran parte por su efectividad, el desarrollo de proyectos software de gran envergadura volvi ineficiente al paradigma estructurado y la OO permite abordar viejos problemas de nuevas maneras y con costes menores (gracias a su hincapi en la reutilizacin mediante la herencia y el encapsulamiento, como se describe en el apartado 4). Sin la OO, muchos proyectos modernos no hubieran podido ejecutarse. Tambin por su sencillez conceptual (quin no sabe lo que es un objeto?), est mucho ms cerca del pensamiento humano que el paradigma estructurado (cuntas personas piensan en los problemas de su vida cotidiana en trminos de algortmica?). Pero tampoco cabe cegarse ante la evidencia: hay un cierto elemento de profeca autocumplida en el xito de la OO y de consenso socio-cultural mayoritario (paradigma) acerca de sus ventajas poco crtico y objetivo en la comunidad de investigadores y desarrolladores de software. Supngase que los investigadores de prestigiosas universidades comenzasen a desarrollar lenguajes MM, crearan revistas y publicaciones con las siglas MM engordando de paso sus currculos y aumentando sus posibilidades de acceder a mejores remuneraciones y a puestos ms elevados- y abrieran nuevas parcelas de investigacin con nuevas promesas de sencillez, productividad, ahorro de costes, etc. Las empresas se haran eco de estas promesas (aunque solo sea por miedo a que otras empresas usen las nuevas tcnicas antes que ellas) y la industria apoyara el nuevo paradigma; apareceran libros como Aprenda MM en 21 das y Thinking in MM, comits de normalizacin, becas para investigar la MM, se venderan camisetas con el lema I love MM, y las empresas anunciaran orgullosas sus inversiones en MM, presentndose probablemente como empresas que caminan por el filo de la tecnologa. Acaso no sera difcil que el nuevo paradigma, avalado y apoyado por la industria y la comunidad investigadora, fracasara? Es probable que a partir de esfuerzos e inversiones se consiguieran xitos totales o parciales- que reafirmaran las promesas iniciales de sencillez, productividad,

18

Orientacin a objetos: Conceptos y terminologa etc. Se reconoceran abiertamente sus fracasos o se justificaran como xitos parciales? Cuesta mucho sustituir MM por OO? El xito de la OO, como el xito de muchas teoras cientficas, tiene aunque en un grado muy pequeo, pero no despreciable- un ingrediente sociolgico en el sentido de Kuhn y otro ingrediente autojustificativo: se prometen nuevos avances, se realizan inversiones muy importantes, se dedican muchos recursos y, efectivamente, se obtienen avances, pero no habran podido conseguirse esos mismos avances u otros mayores con cualquier otro paradigma razonable si se hubieran dedicado los mismos recursos e inversiones? Hoy difcilmente un especialista se embarcara en un importante proyecto de software sin seguir la metodologa OO, porque es el paradigma dominante y la mayora de recursos e investigacin van a parar a l y resulta muy difcil conseguir financiacin para ideas o proyectos fuera del paradigma dominante. La orientacin a objetos, aun siendo el paradigma dominante, no aporta capacidades o mtodos de resolucin de problemas irresolubles en sentido terico- por otros medios o tcnicas. Una mquina de Turing podra ser simulada por cualquier lenguaje de programacin que permitiera sentencias condicionales y saltos. De acuerdo con la conjetura de Church, cualquier computacin para la que exista un algoritmo funcional (ya fuera el tiempo necesario de computo finito o no) puede ser realizada por una mquina de Turing. Por lo tanto, cualquier computacin con un algoritmo funcional podra ser realizada en sentido terico, en la prctica habra limitaciones de tiempo, memoria, capacidad, etc.- en cualquier lenguaje de programacin que permitiera sentencias condicionales y saltos, sea o no un lenguaje OO. La OO suministra unos nuevos anteojos conceptuales con los que ver el mundo y con los que comprender y solucionar los problemas de un modo ms rpido, eficiente, econmico y natural que con el paradigma estructurado (y ms cercano al pensamiento humano: es mucho ms natural para nosotros pensar en trminos de objetos que de algoritmos), pero no proporciona soluciones a problemas no solubles con otros medios o tcnicas.

Nota del autor: La reproduccin del cuadro La traicin de las imgenes de Ren Magritte se realiza con carcter ilustrativo y pedaggico. Los derechos de reproduccin pertenecen a los herederos de Ren Magritte y/o a cualquier empresa, entidad o fundacin que los representara o los hubiera adquirido. El autor no persigue en modo alguno lucrarse u obtener beneficio econmico alguno de la reproduccin del cuadro.

Nota biogrfica del Autor: Miguel ngel Abin naci en Soria (1972). Se licenci en Ciencias Fsicas en 1995 por la U. de Valencia y consigui la suficiencia investigadora en 1997 dentro del Dpto. Fsica Aplicada de la U.V. Adems ha realizado diversos cursos de Postgrado sobre bases de datos, lenguajes de programacin Web, sistemas Unix y Java. Ha participado en diversos programas de investigacin TIC relacionados con el estudio de fibras pticas y cristales fotnicos, y ha publicado diversos artculos en el IEEE Transactions on Microwave Theory and Techniques relacionados con el anlisis de guas de onda inhomogeneas y guas de onda elpticas. En el mbito laboral ha trabajado como gestor de carteras y asesor fiscal para una agencia de bolsa y actualmente trabaja en el Laboratorio del Mueble Acabado de AIDIMA (Instituto Tecnolgico del Mueble y Afines), ubicado en Paterna (Valencia), en tareas de normalizacin y certificacin. En dicho centro se estn desarrollando

19

http://www.javahispano.org proyectos europeos de comercio electrnico B2B para la industria del mueble basados en Java y XML (ms informacin en www.aidima.es). Sus intereses actuales son: el diseo asistido por ordenador de guas de ondas y cristales fotnicos, la evolucin de la programacin orientada a objetos, Java, el surrealismo y Pars, siempre Pars.

Copyright (c) 2003, Miguel ngel Abin. Este documento puede ser distribuido solo bajo los trminos y condiciones de la licencia de Documentacin de javaHispano v1.0 o posterior (la ltima versin se encuentra en http://www.javahispano.org/licencias/).

20