Vista previa del material en texto
OOP (Object Oriented Programming) 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 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í. 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: 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 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 aplicacionesy / o componentes es bajo, no tiene sentido aumentar los costos finales en pos de un ahorro que puede ser marginal. image1.png image2.png image3.png
