Tarea 3 Mito: OOP aumenta el reuso de código 1.− Resumen explicativo del mito propuesto El mito elegido fue OOP increases reuse (recycling of code), en español, OOP incrementa la reutilización (reciclaje de código). La posibilidad de reutilizar código de programas debido a la capacidad de abstracción de la OOP, es uno de las principales argumentos a favor de la OOP. El autor de la página http://www.geocities.com/tablizer/myths.htm señala que a medida que ha pasado el tiempo y la OOP es usada, este argumento ha perdido fuerza e incluso ha dejado de ser una de las premisas de los fanáticos de la OOP. Algunas propuestas han sugerido que la mayor área de reutilización de código son las componentes. De todas formas, el porqué las componentes OOP son más reutilizables que las componentes no creadas usando OOP nunca ha sido claramente explicado. Una razón podría ser el intercambio de implementaciones, es decir, intercambiar clases que contienen una colección de objetos. Pero al autor de la página da como ejemplo su experiencia personal: jamás a tenido la necesidad de intercambiar clases que tengan las mismas interfaces. Incluso señala que no tiene sentido tener dos implementaciones de lo mismo. La mayoría de los ejemplo dados por los defensores de la OOP son considerados como irreales o imprácticos por el autor. Referencias Wiki Reuse Discussion and Notes http://www.geocities.com/tablizer/reustalk.htm Components http://www.geocities.com/tablizer/miscoop.htm#components The Driver Pattern http://www.geocities.com/tablizer/driver.htm Dr. Dobb's Article − 'Such Much OO, So Little Reuse' http://www.ddj.com/documents/s=909/ddj9875g/9875g.htm 2. Discusión sobre la validez de los argumentos del autor Para comenzar, hay que notar cierta animadversión del autor hacia OOP, lo que no invalida sus argumentos, al estar bastante bien explicados y contar con referencias, aunque estas no son completamente imparciales. Su principal prueba acerca de que la reutilización de código no es factible es acerca de su propia experiencia, calificando a las pruebas y ejemplo de reutilización de irreales. Lamentablemente, no considero un ejemplo claro de reutilización de código, o al menos de ahorro del mismo gracias a OOP: la herencia. Por otra parte menciona la imposibilidad de hacer intercambio de implementaciones, nuevamente basado en su experiencia personal, pero ese es un argumento debatible en cuanto a la cantidad de programas que el autor enfrente como ingeniero de software, ya que si solo trabaja él por simple orden de trabajos que puede tomar un ser humano no es una cantidad representativa de la cantidad 1

de aplicaciones que se desarrollan a nivel mundial. En cuanto a sus referencias, en particular la que se refiere a extractos de un foro de ingenieros de software, se puede apreciar un fanatismo, una defensa cerrada hacia la programación procedural. Peor aún, no analiza la verdad o falsedad de la reutilización de código gracias a OOP en función de distintos escenarios ni en un marco de manejo de proyectos informáticos que incentiven a la reutilización, como es el caso de las compañías de software en India. 3. Contra argumentar y/o apoyar la crítica A favor de la reutilización de código Típicamente se encuentran tres categorías de reutilización de código dentro de la OOP, las que son: • Objetos que son muy reutilizables a través de diferentes aplicaciones (como la clase string o clases de entrada−salida). • Objetos que son reutilizables dentro de un espectro particular de programas (como una clase estudiante y sus relaciones para aplicaciones de instituciones académicas). • Objetos que simplemente son tan especificas que no serán reutilizadas de nuevo jamás, en ningún lugar. Para conocer de una fuente más cercana la apreciación de un programador, el alumno se contacto con compañeros de él mientras cursó ramos en el Departamento de Ciencias de la Computación, para complementar su propia experiencia en esa carrera. Ambos compañeros, ya trabajando como Ingenieros en Computación, tienden a preferir la programación procedural, a excepción de aplicaciones basadas en Internet, la cual se presta de especial manera para la reutilización (GUI, sockets, formularios, etc). Pero reconocen que la programación orientada a objetos puede ser útil para reutilizar código siempre cuando se decida desde un principio buscar la reutilización de las componentes, lo cual también se puede obtener de la programación procedural, pero en menor medida debido a las limitaciones para hacer reutilización por referencia (RR). Más adelante se explicará en mayor medida este punto. Por ello, mientras la idea de reutilización de código para la programación procedural se basa mayoritariamente en reutilización por copia, que es donde se copian partes de otra aplicación o código y es modificado para adaptarse a las necesidades locales, la programación orientada a objetos permite la RR haciendo que los clientes compartan el mismo código de una componente, con las ventajas y desventajas que eso implica. En síntesis, la experiencia personal de estos ingenieros es que la OOP es mejor para la reutilización de código bajo ciertas condiciones, como es una arquitectura de la relación con los objetos (o entidades) similar a cliente / servidor o con una política de desarrollo que privilegie la OOP y fomente la reutilización. Un ejemplo de esto son las empresas de software indias, que pagan una bonificación a sus programadores por objeto reutilizable, y otro más por objetos reutilizados, lo cual derriba la supuesta extraordinaria complejidad de la reutilización expuesta por el autor. Otro argumento que pierde fuerza gracias a una adecuada gestión de un proyecto de software es: A medida que es más genérico el componente, tendrá más características (features). Teniendo más features es al mismo tiempo una solución y un problema. A pesar de que puede ayudar a no tener que escribir más código a medida que más clientes o aplicaciones usan la componente, se agrega complejidad para aprender, comprender y manejar las interfaces. Una solución es ser rigurosos durante el desarrollo en cuanto a la documentación respectiva de la aplicación y del mismo código. Esto le resta más fuerza aun al argumento esgrimido por el autor si consideramos que la documentación es deseable tanto en los programas creados por OOP o programación procedural. Esto demuestra que si no se ha hecho masiva la tendencia de buscar la reutilización, es por una falta de interés organizacional o incluso problemas de los programadores más que de la OOP en sí. 2

La herencia es otra forma de reutilización de código no considerada por el autor en toda la dimensión de utilidad que puede brindar. En programación procedural hay reutilización hasta cierto punto− se puede ocupar un método cuantas veces se necesite. Sin embargo, la OOP permite agrupar objetos (o entidades) con características comunes. La herencia permite a una clase heredar los atributos y métodos de otra clase, Este permite crear clases totalmente nuevas mediante la abstracción de atributos y comportamientos comunes. Y la herencia no se limita a solo clases padre−hijo, también permite combinar distintas clases para formar un hijo u otras relaciones de herencia:

3

Claramente, la utilidad de la herencia depende del diseño del sistema, y es aceptable decir que no siempre será posible encontrar herencias, ya que dependerá de la realidad que se este modelando. Pero es una utilidad de la OOP demasiado fuerte como para no considerarla. En contra de la reutilización de código 4

Hay que aceptar que el diseño OOP es más caro y complicado que el procedural, para la mayoría de los programadores que se acostumbraron al enfoque tradicional. Incluso, la etapa de diseño puede tomar mucho más tiempo y recursos. Y esto se hace más costoso aún si se fuerza a buscar la reutilización y tenerla como objetivo colateral. Por otro lado, es muy difícil encontrar sistemas que requieran componentes similares si se desarrollan pocos sistemas, lo cual es la realidad de muchos programadores, lo que no justificaría el mayor uso de recursos. La reutilización no es tan sencilla como se puede pensar: Para cada proyecto se va a necesitar un análisis que comprenda a toda el sistema a desarrollar y conocer muy bien los componentes que posee la empresa desarrolladora del software, para poder sentar las bases de cualquier posible reutilización. Esto se hace inútil si la aplicación es una sola y pequeña, no parte de una familia o de un sistema más complejo. El mundo real cambia, por lo que no es irreal suponer que el mundo que retrata una abstracción cambie, eliminando componentes y relaciones, lo que hace más difícil aun encontrar piezas de software parecidas. Una gran dificultad de la reutilización de código, más específicamente de la reutilización por referencia (RR) son sus ventajas. Una de ella es el parentesco. Si accidentalmente falla o se destruye la componente compartida, todos los clientes heredan la falla o problema. Otro problema es mantener la compatibilidad hacia atrás. Tenemos que seguir soportando a todos los clientes, independiente de que nueva funcionalidad se agrega. La reutilización por copia no tiene este problema, ya que se modifica para adaptarse a las nuevas necesidades, pero es necesario hacerlo para cada componente. Pero el amor problema es la interferencia, las funcionalidades usadas por un cliente pueden no coincidir con las de otro cliente. Para satisfacer más clientes, se deben agregar más funcionalidades, haciendo a la componente más complicada al poseer tantas funcionalidades. Finalmente, si el costo desarrollo de aplicaciones y / o componentes es bajo, no tiene sentido aumentar los costos finales en pos de un ahorro que puede ser marginal. 4. Conclusiones La conclusión que salta a la vista es que la OOP no es la solución a todos los problemas por si sola, los ingenieros de software, tanto en la gestión como en la programación deben estar comprometidos y entrenados para usar la OOP, y es más, deben tener la voluntad de hacerlo, ya que se puede llegar a tener problemas organizacionales si dentro de los equipos de programadores hay fanáticos de la programación procedural. Las mismas empresas y/o equipos de trabajo deben estar concientes de que una orientación hacia la reutilización es más cara y notoriamente difícil, pero que puede verse compensada a largo plazo. Un ejemplo de esto son las empresas de software indias, nombradas anteriormente, pero con una razón muy clara: son empresas CMM 5. 5. Referencias • OOP Demystified: A Self−Teaching Guide by Jim Keogh and Mario Giannini, ISBN:0072253630, McGraw−Hill/Osborne © 2004 • Wiki Reuse Discussion and Notes http://www.geocities.com/tablizer/reustalk.htm • G. Arango and R. Prieto−Diaz. Domain analysis: Concepts and research directions. In R. Prieto−Diaz and G. Arango, editors, Domain Analysis: Acquisition of Reusable Information for Software Construction. IEEE Computer Society Press, May 1989. • Object−Oriented Thought Process, The, Second Edition By Matt Weisfeld.

5