¿Qué es Programación Orientada a Objetos?
Programación orientada a Objetos (en adelante POO) , es un paradigma que define un conjunto de reglas y técnicas para el desarollo de piezas de software . Como su nombre lo indica en esta forma de crear software la idea es ver todo como un objeto... bastante obvio pero para poder entender esto es necesario saber algo muy importante...
¿Qué es un Objeto?
Un objeto es cualquier cosa. Si, en serio un objeto es cualquier cosa de la cual podamos emitir un concepto, descripción.
Profesora: Juanito, dime el nombre de uno de los objetos de aula de la clase!
Juanito: El tablero Sra. profesora!
Profesora: Juanito dime las características del tablero
Juanito: El tablero es cuadrado, de color blanco, liso, grande, en forma de rectangulo
Profesora: Y que cosas puedes hacer con el tablero?
Juanito: Escribir, borrar, limpiar, dibujar
Podemos ver que Juanito resulto ser un experto en POO... no es broma esa descripción que él acaba de hacer es suficiente para definir un objeto en POO. Juanito ha definido un objeto tablero, el cual tiene como atributos: forma, color, tamaño, textura y con el cual se puede: borrar, escribir, limpiar y dibujar. Sabemos que un objeto existe gracias a que podemos hacer una abstracción del mismo definiéndolo como un conjunto de elementos y funcionalidades que lo componen... hagamos la prueba, pensemos en un varios objetos y veamos algúnos de sus atributos y funcionalidades.
Objeto: Bombillo
Atributos: forma, color, brillantez, luminiscencia, material, tipo (incandescente, alógeno)
Funcionalidades: brillar, no brillar
Objeto: Personaje de un juego
Atributos: comportamiento, tamaño, numero de cuadros, sonidos, personalidad , vidas, poderes
Funcionalidades: saltar, correr, caminar, morir, herir, hablar
Objeto: Cuaderno
Atributos: material, tipo de encuadernación, color, carátula, tipo de hoja, marca
Funcionalidades: abrir, cerrar, arrancar hoja
Objeto: Esfero
Atributos: forma, tamaño, color, tipo de tinta, marca, duración
Funcionalidades: escribir, esconder punta, mostrar punta, recargar
Objeto: Automóvil
Atributos: marca, modelo, kilometraje, consumo de gasolina, color, numero de ruedas
Funcionalidades: acelerar, frenar, abrir puerta, cerrar puerta, arrancar, apagar
Bien si habláramos en términos de POO lo que Juanito hizo fue definir un objeto con sus atributos y sus métodos, un atributo es una característica, propiedad o elemento de un objeto y un método es una acción que se puede realizar con el objeto, veremos este asunto con más detalle en los capítulos siguientes.
¿Porqué surge la POO? (Historia)
El comienzo...( spaghetti )
En sus comienzos la programación de computadores era una tarea relegada prácticamente a los 'genios' de la computación de aquel entonces; hacer un programa para computador demandaba miles de horas de tiempo invertido y desde luego miles de miles o millones de líneas de código para llevar a cabo una tarea determinada. Bien la programación de ese entonces tenia un estilo particular llamado hoy día programación en spaghetti , se llama así porque todo el código generalmente sigue una línea secuencial desde la primera instrucción hasta la última, ocasionalmente hay saltos entre instrucciones , pero generalmente se regresa al punto donde se originó el salto... los lenguajes más populares en ese entonces eran desde luego el ASM, el FORTRAN y el COBOL, tal vez no suene muy claro para usted, así que veámoslo en un ejemplo.
Imagen Rota/Perdida
así se programa usando esos lenguajes, espero que haya sido suficiente...
Luego los programas se fueron haciendo más grandes y complejos, así que las cosas se comenzaron a hacer dificiles de manejar (es decir aún más dificiles de manejar) , allí nacio una nueva forma de programación... una nueva metodología, la programación estructurada.
Programación Estructurada
La solución a tantos problemas fue básicamente sencilla, agrupar el código por funcionalidad de tal forma que cada funcionalidad pueda ser invocada tantas veces como se necesite, esto permitió reducir las líneas de código necesarias para crear un programa ya que si existe una rutina compleja que podía ser en algún grado repetitiva, esta se coloca en una función que sea aplicable en uno o más casos diferentes... veamos un ejemplo.
Supongamos que tenemos un programa que controla las cuentas de un banco (imaginemos un banco pequeño), así que se ha creado un conjunto de programas para tal fin. Dentro de esos programas tenemos una sección de programa que lo que hace es manejar los retiros que ha hecho el dueño de la cuenta, lo cual implica descontar un valor determinado de una cuenta y elaborar el registo contable correspondiente... imaginemos otra parte del código de ese programa, un cliente paga su tarjeta de crédito así que otra vez el programa descuenta el valor de la cuenta del cliente, también elabora el registro contable correspondiente y adicionalmente hace otros registros y abonos a la cuenta de la tarjeta de crédito... Este tipo de cosas las tendría que hacer el programa miles de veces, una vez cada que se presente una transacción en el banco.
En programación spaguetti eso tomaría miles de líneas como lo vimos anteriormente, ya que por cada transacción se requiere volver a repetir las instrucciones para hacer lo correspondiente; en programación estructurada esto ya no es necesario ya que habríamos creado algúnas funcionalidades que nos permiten invocarlas cuando las necesitemos, así solamente crearíamos el código para registrar el abono o el descuento de dinero de una cuenta, y otro código para hacer registros contables, así que cada vez que los necesitemos simplemente colocamos una línea de código haciendo el llamado a la funcionalidad, y no repitiendo nuevamente todo el código que hace parte de la misma.
Imagen Rota/Perdida Imagen Rota/Perdida
Como se puede ver en el ejemplo el ahorro es significativo... imaginen en el caso del banco, miles de veces usando la funcionalidad... o que la funcionalidad fuera muy compleja y por si sola tuviese miles de líneas...serían miles de miles de líneas de código ahorradas.
Pero los días de la programación estructurada estaban contados, los programas siguieron creciendo, tener un código altamente estructurado ya no ayudaba lo suficiente, pues la complejidad y magnitud de las cosas que se se deben hacer aumentaba exponencialmente...
Y Llegó la POO...
Cuando las cosas se hicieron demasiado complejas, fue necesario tomar decisiones radicales... cuando nació la programación estructurada la solución fue sencilla... demasiado sencilla, agrupar las cosas en funcionalidades... funcionó y de hecho funciona tanto que si se hubiese deseado disminuir nuevamente la complejidad de los problemas de la programación a gran escala simplemente se hubiesen creado niveles de agrupamiento de funcionalidades... algo como funcionalidades de funcionalidades... pero el problema se volvería a repetir entre más grande fuera el software... así que hubo necesidad de cambiar las cosas de una manera más profunda.
La forma en que se hacían los programas era siempre orientada a la funcionalidad, es decir que haga lo que debe y que lo haga de la manera más rápida, ocasionalmente y si era posible reutilizar el código ya creado... los incidentes comenzaron a aparecer veamos una ejemplo, sigamos con el banco...
Bien el banco ha crecido un poco más razón por la cual necesitan modernizar su sistema ( hardware, programas etc..) se ponen en la labor de crear nuevos programas, como los requieren en el menor tiempo imposible dividieron su área de desarrollo en varios grupos: uno que hará toda la parte con cuentas corrientes , otro que funciona con cuentas de ahorro, y otro con tarjetas debito, otro con CDT etc. Para evitar algúnos problemas definen una serie de estándares de nomenclatura y ese tipo de cosas. Tiempo después los módulos del programa ya están casi listos así que se disponen a integrar todos esos programas en un programa único, pero cuando iniciaron con eso paso algo inesperado.
Los señores del grupo de cuentas de ahorros crearon unas funciones, se llaman debito y crédito, mientras tanto los señores del grupo de CDT´s , los de tarjetas, los de cuenta corriente etc. crearon también todos funciones llamadas débito y crédito ... pero todas hacen cosas diferentes cada una para su caso puntual... resultado de la operación: hay que renombrar todas las funciones débito crédito para que todas se llamen diferentes, cosa que todos los grupos... con desagrado decidieron acatar, todos excepto dos.
El grupo de cuentas de ahorro y el de tarjeta de crédito no pueden hacer el cambio de una manera tan sencilla ya que han utilizado unas librerías provistas por terceros y que ya desde hace tiempo interactúan con u sistema de transacciones a nivel internacional que requiere que el software cumpla con una serie de líneamientos e interfaces de programación, y para completar el problema parte de esas interfaces implican no solo es usar el nombre que ya usan en sus funciones sino que el nombre que se ha propuesto utilizar ya es usado para otros fines en dichas librerías integradas... etc.
Así las cosas les tardara un poconon de tiempo a los señores hacer los cambios que necesitan porque definitivamente el programa integrador no se puede crear si hay dos funciones con el mismo nombre dentro del paquete... imaginemos todas las variables que habrán quedado con nombres parecidos, sino es que iguales... en un programa tan enorme evitar esa situación es algo muy complicado.
Pero en POO las cosas habrían sido diferentes, puesto que desde que se han creado los módulos cada uno es un componente por separado y las funciones de los Sre del CDT serian accedidas algo así como:
CDT.debito
CDT.crédito
Las de ahorros serian:
Ahorros.debito
Ahorros.crédito
Y así sucesivamente con cada uno de los módulos, de hecho todos podrían tener las mismas variables: a, b, c, d, e, f y no pasaría absolutamente nada.
Otro problema con el sistema estructurado es que si los señores de CDT tienen una función para encripción única que no debe ser usada por nadie más... no hay garantía de que más adelante los señores de tarjeta de crédito la usen, y pueden hacerlo por que hace parte del mismo programa enlazado, eso seria muy difíicil sino imposible de evitar en programación estructurada, pero en POO seria muy sencillo ya que le diríamos a nuestra función que fuera de uso privado, es decir solo utilizable dentro del grupo de CDT, ya más adelante profundizaremos en esta parte.
Información compartida por
JuanK
Programación orientada a Objetos (en adelante POO) , es un paradigma que define un conjunto de reglas y técnicas para el desarollo de piezas de software . Como su nombre lo indica en esta forma de crear software la idea es ver todo como un objeto... bastante obvio pero para poder entender esto es necesario saber algo muy importante...
¿Qué es un Objeto?
Un objeto es cualquier cosa. Si, en serio un objeto es cualquier cosa de la cual podamos emitir un concepto, descripción.
Profesora: Juanito, dime el nombre de uno de los objetos de aula de la clase!
Juanito: El tablero Sra. profesora!
Profesora: Juanito dime las características del tablero
Juanito: El tablero es cuadrado, de color blanco, liso, grande, en forma de rectangulo
Profesora: Y que cosas puedes hacer con el tablero?
Juanito: Escribir, borrar, limpiar, dibujar
Podemos ver que Juanito resulto ser un experto en POO... no es broma esa descripción que él acaba de hacer es suficiente para definir un objeto en POO. Juanito ha definido un objeto tablero, el cual tiene como atributos: forma, color, tamaño, textura y con el cual se puede: borrar, escribir, limpiar y dibujar. Sabemos que un objeto existe gracias a que podemos hacer una abstracción del mismo definiéndolo como un conjunto de elementos y funcionalidades que lo componen... hagamos la prueba, pensemos en un varios objetos y veamos algúnos de sus atributos y funcionalidades.
Objeto: Bombillo
Atributos: forma, color, brillantez, luminiscencia, material, tipo (incandescente, alógeno)
Funcionalidades: brillar, no brillar
Objeto: Personaje de un juego
Atributos: comportamiento, tamaño, numero de cuadros, sonidos, personalidad , vidas, poderes
Funcionalidades: saltar, correr, caminar, morir, herir, hablar
Objeto: Cuaderno
Atributos: material, tipo de encuadernación, color, carátula, tipo de hoja, marca
Funcionalidades: abrir, cerrar, arrancar hoja
Objeto: Esfero
Atributos: forma, tamaño, color, tipo de tinta, marca, duración
Funcionalidades: escribir, esconder punta, mostrar punta, recargar
Objeto: Automóvil
Atributos: marca, modelo, kilometraje, consumo de gasolina, color, numero de ruedas
Funcionalidades: acelerar, frenar, abrir puerta, cerrar puerta, arrancar, apagar
Bien si habláramos en términos de POO lo que Juanito hizo fue definir un objeto con sus atributos y sus métodos, un atributo es una característica, propiedad o elemento de un objeto y un método es una acción que se puede realizar con el objeto, veremos este asunto con más detalle en los capítulos siguientes.
¿Porqué surge la POO? (Historia)
El comienzo...( spaghetti )
En sus comienzos la programación de computadores era una tarea relegada prácticamente a los 'genios' de la computación de aquel entonces; hacer un programa para computador demandaba miles de horas de tiempo invertido y desde luego miles de miles o millones de líneas de código para llevar a cabo una tarea determinada. Bien la programación de ese entonces tenia un estilo particular llamado hoy día programación en spaghetti , se llama así porque todo el código generalmente sigue una línea secuencial desde la primera instrucción hasta la última, ocasionalmente hay saltos entre instrucciones , pero generalmente se regresa al punto donde se originó el salto... los lenguajes más populares en ese entonces eran desde luego el ASM, el FORTRAN y el COBOL, tal vez no suene muy claro para usted, así que veámoslo en un ejemplo.
Imagen Rota/Perdida
así se programa usando esos lenguajes, espero que haya sido suficiente...
Luego los programas se fueron haciendo más grandes y complejos, así que las cosas se comenzaron a hacer dificiles de manejar (es decir aún más dificiles de manejar) , allí nacio una nueva forma de programación... una nueva metodología, la programación estructurada.
Programación Estructurada
La solución a tantos problemas fue básicamente sencilla, agrupar el código por funcionalidad de tal forma que cada funcionalidad pueda ser invocada tantas veces como se necesite, esto permitió reducir las líneas de código necesarias para crear un programa ya que si existe una rutina compleja que podía ser en algún grado repetitiva, esta se coloca en una función que sea aplicable en uno o más casos diferentes... veamos un ejemplo.
Supongamos que tenemos un programa que controla las cuentas de un banco (imaginemos un banco pequeño), así que se ha creado un conjunto de programas para tal fin. Dentro de esos programas tenemos una sección de programa que lo que hace es manejar los retiros que ha hecho el dueño de la cuenta, lo cual implica descontar un valor determinado de una cuenta y elaborar el registo contable correspondiente... imaginemos otra parte del código de ese programa, un cliente paga su tarjeta de crédito así que otra vez el programa descuenta el valor de la cuenta del cliente, también elabora el registro contable correspondiente y adicionalmente hace otros registros y abonos a la cuenta de la tarjeta de crédito... Este tipo de cosas las tendría que hacer el programa miles de veces, una vez cada que se presente una transacción en el banco.
En programación spaguetti eso tomaría miles de líneas como lo vimos anteriormente, ya que por cada transacción se requiere volver a repetir las instrucciones para hacer lo correspondiente; en programación estructurada esto ya no es necesario ya que habríamos creado algúnas funcionalidades que nos permiten invocarlas cuando las necesitemos, así solamente crearíamos el código para registrar el abono o el descuento de dinero de una cuenta, y otro código para hacer registros contables, así que cada vez que los necesitemos simplemente colocamos una línea de código haciendo el llamado a la funcionalidad, y no repitiendo nuevamente todo el código que hace parte de la misma.
Imagen Rota/Perdida Imagen Rota/Perdida
Como se puede ver en el ejemplo el ahorro es significativo... imaginen en el caso del banco, miles de veces usando la funcionalidad... o que la funcionalidad fuera muy compleja y por si sola tuviese miles de líneas...serían miles de miles de líneas de código ahorradas.
Pero los días de la programación estructurada estaban contados, los programas siguieron creciendo, tener un código altamente estructurado ya no ayudaba lo suficiente, pues la complejidad y magnitud de las cosas que se se deben hacer aumentaba exponencialmente...
Y Llegó la POO...
Cuando las cosas se hicieron demasiado complejas, fue necesario tomar decisiones radicales... cuando nació la programación estructurada la solución fue sencilla... demasiado sencilla, agrupar las cosas en funcionalidades... funcionó y de hecho funciona tanto que si se hubiese deseado disminuir nuevamente la complejidad de los problemas de la programación a gran escala simplemente se hubiesen creado niveles de agrupamiento de funcionalidades... algo como funcionalidades de funcionalidades... pero el problema se volvería a repetir entre más grande fuera el software... así que hubo necesidad de cambiar las cosas de una manera más profunda.
La forma en que se hacían los programas era siempre orientada a la funcionalidad, es decir que haga lo que debe y que lo haga de la manera más rápida, ocasionalmente y si era posible reutilizar el código ya creado... los incidentes comenzaron a aparecer veamos una ejemplo, sigamos con el banco...
Bien el banco ha crecido un poco más razón por la cual necesitan modernizar su sistema ( hardware, programas etc..) se ponen en la labor de crear nuevos programas, como los requieren en el menor tiempo imposible dividieron su área de desarrollo en varios grupos: uno que hará toda la parte con cuentas corrientes , otro que funciona con cuentas de ahorro, y otro con tarjetas debito, otro con CDT etc. Para evitar algúnos problemas definen una serie de estándares de nomenclatura y ese tipo de cosas. Tiempo después los módulos del programa ya están casi listos así que se disponen a integrar todos esos programas en un programa único, pero cuando iniciaron con eso paso algo inesperado.
Los señores del grupo de cuentas de ahorros crearon unas funciones, se llaman debito y crédito, mientras tanto los señores del grupo de CDT´s , los de tarjetas, los de cuenta corriente etc. crearon también todos funciones llamadas débito y crédito ... pero todas hacen cosas diferentes cada una para su caso puntual... resultado de la operación: hay que renombrar todas las funciones débito crédito para que todas se llamen diferentes, cosa que todos los grupos... con desagrado decidieron acatar, todos excepto dos.
El grupo de cuentas de ahorro y el de tarjeta de crédito no pueden hacer el cambio de una manera tan sencilla ya que han utilizado unas librerías provistas por terceros y que ya desde hace tiempo interactúan con u sistema de transacciones a nivel internacional que requiere que el software cumpla con una serie de líneamientos e interfaces de programación, y para completar el problema parte de esas interfaces implican no solo es usar el nombre que ya usan en sus funciones sino que el nombre que se ha propuesto utilizar ya es usado para otros fines en dichas librerías integradas... etc.
Así las cosas les tardara un poconon de tiempo a los señores hacer los cambios que necesitan porque definitivamente el programa integrador no se puede crear si hay dos funciones con el mismo nombre dentro del paquete... imaginemos todas las variables que habrán quedado con nombres parecidos, sino es que iguales... en un programa tan enorme evitar esa situación es algo muy complicado.
Pero en POO las cosas habrían sido diferentes, puesto que desde que se han creado los módulos cada uno es un componente por separado y las funciones de los Sre del CDT serian accedidas algo así como:
CDT.debito
CDT.crédito
Las de ahorros serian:
Ahorros.debito
Ahorros.crédito
Y así sucesivamente con cada uno de los módulos, de hecho todos podrían tener las mismas variables: a, b, c, d, e, f y no pasaría absolutamente nada.
Otro problema con el sistema estructurado es que si los señores de CDT tienen una función para encripción única que no debe ser usada por nadie más... no hay garantía de que más adelante los señores de tarjeta de crédito la usen, y pueden hacerlo por que hace parte del mismo programa enlazado, eso seria muy difíicil sino imposible de evitar en programación estructurada, pero en POO seria muy sencillo ya que le diríamos a nuestra función que fuera de uso privado, es decir solo utilizable dentro del grupo de CDT, ya más adelante profundizaremos en esta parte.
Información compartida por
JuanK