personalmente, esta fue mi primera reaccion cuando me enfrenté a la POO; es, en mi opinion, el paradigma más complicado de entender y a la vez, el más util; voy a intentar explicarlo tomando como base la programacion clasica, la tradicional, la de toda la vida ( el paradigma de la programacion imperativa);
para empezar, en la programacion clasica, tenemos una serie de instrucciones ordenadas consecutivamente, que se ejecutan en estricto orden descendente ( salvo que exista una sentencia de salto, aunque gracias a dijstra, est´an en desuso); puede que creemos por separado, trozos de codigo que sabemos que van a repetirse muchas veces en nuestro programa, y los agrupemos en forma de procedimientos (que pueden no devolver nada o no tener ningun parametro de entrada ) o funciones ( que por definicion, devuelven algo con unos datos de entrada); esto, unido a una serie de variables definidas dentro de la estructura principal, el programa en si, nos da una idea más o menos clara de lo que es un codigo estandar de programacion clásica.
pues bien, la POO podemos plantearnosla así: imaginad un monton de mini programas todos enlazados; y ya está?, eso es todo?. menuda tonteria, ¿verdad? no os preocupeis, voy a explicarme mejor:
un programa escrito en POO se compone de clases; y las clases pueden poseer dentro atributos y metodos. que son los atributos? pues las variables que definen la clase. y los metodos? las sentencias que transforman dichas variables o que generan algun tipo de salida dada algun tipo de entrada…hum…no os suena? claro, es un programa de programacion clásica!
entonces, no viene a ser lo msimo que la programacion clásica? pues no exactamente, ahora explicaré la diferencia.
cuando ejecutamos un codigo de programacion clásica, digamos que lo ejecutamos todo de un golpe, a cascoporro, es decir, TODO se carga en memoria y se almacena en memoria hasta que el progrma termina. cuando estamos hablando de un programa con miles de millones de sentencias ( que los hay), creedme que puede significar el colapso de vuestro ordenador.
pero la POO es distinta, por que en ella hablamos de objetos…y eso que es lo que es? es la pregunta que todos los que hemos empezado en el paradigma de la programacion clasica nos hacemos. pues bien, un objeto es la expresion en memoria de una clase. en palabras poco tecnicas y probablemente muy inexactas, es un miniprograma en ejecucion, o listo para ejecutarse.
lo bueno es que en todo momento, al estar hablando de clases, podemos elegir que clase “instanciar” ( cargar en memoria); a diferencia de la programacion clásica, en la que todo se carga en memoria ( las llamadas a funciones a la hora de la ejecucion, se sustituyen por el mismo numero de sentencias ejecutadas, es decir si llamamos a una funcion que tiene 8 sentencias 3 veces, realmente tendremos cargadas en memoria 24 sentencias que se repiten…no es más que comodidad para el programador) en la POO nosotros decimos a que parte del codigo llamar, y, en algunos lenguajes, que parte del codigo ya no nos interesa llamar más.
en un post anterior hablé del recolector de basura, bien, este es el momento perfecto para explicarlo: hasta ahora solo estamos cargando el codigo que nos interesa en memoria, pero… esto no nos vale para nada si no podemos hacer “borron y cuenta nueva” cuando el codigo ya no nos interesa. esa es precisamente la funcion del recolector de basura: analizar cuando no se va a necesitar más un cierto objeto y destruirlo, o lo que es lo mismo, liberar la memoria que estaba utilizando ( recordemos que en java esto se hace automaticamente, no hace falta explicitarlo, a diferencia de C++);
en conclusion: la POO es una version optimizada de la programaicon clasica, ya que requiere muchos menos recursos que la programacion normal. imaginad hacer una aplicacion grafica grande con programacion imperativa…seria un suicidio para la RAM, pues todo se basaria en cargar en memoria bucles enormes de lso que se saldría cuando un evento ocurriera ( como escribir algo o cerrar una ventana).
además de esto, existen muchisimas otras cosas que hacen a la POO un paradigma muy interesante, como la herencia y la multiherencia, por citar un ejemplo, además del hecho de que podemos comprobar la funcionalidad de cada clase por separado ( recuerda que son miniprogramas), y depurar errores de una forma mucho más rapida
sin embargo, como todo, no es perfecto, y tenemos que tener en cuenta una serie de desventajas importantes: la primera es el mayor tiempo de preparacion de un programa: hace falta mucho más esfuerzo para abstraer todas las clases que vamos a necesitar y como van a interactuar entre si. tambien hay que tener en cuenta que puede resultar un poco caotico tener el programa “a trozos”, con una parte del codigo en un archivo distinto a otra. y por ultimo, destacar que desaparecen muchos conceptos y otros son sustituidos por versiones mucho más abstractas de ellos, lo que dificulta su comprension enormemente, por ejemplo, ya no existen las bibliotecas de funciones como tales, ahora son paquetes de clases instanciables. es lo mismo, pero distinto xD
mi consejo, plantearos cada clase como un programa pequeño, y luego pensad en como interactua con el resto de programas pequeños para ahcer un programa grande. así es como yo conseguí entenderlo mejor.
espero que este post os sea util en vuestro viaje a través de la POO. un saludo a todos!
) y así sucesivamente. y ¿cómo soluciona esto java? facil, cuando compilamos en java lo hacemos a un lenguaje más o menos unificado ( siguiendo con la metafora de los idiomas, que sea el esperanto), que se traduce en tiempo real por una maquina virtual, que no es más que un interprete, desde el bitecode de java a las sentencias maquina de cada ordenador ( traductor en tiempo real de esperanto-chino, por ejemplo). ¿la ventaja? como dije anteriormente, un mismo codigo YA COMPILADO ( esto es muy importante) puede utilizarse en GNU/linux, en Windows, en MacOS… parece que no, pero para usuarios multiplataforma ( vease mi caso, que tengo que usar windows aunque no me guste mucho) es una enorme ventaja.