INFORMATICOS: Para que shishi sirve la PROGRAMACION ORIENTADA A OBJETOS???

POO te permite normalizar un montón de patrones de buena practica que están mas que probados, y que cuanto mas grande se hace el edificio, mas necesarios se hacen para no perder el control.

Ademas te ayuda a entrar en modelos de abstracción mas complejos como programación concurrente, event-based o usar inyección de dependencias.

Recuerdo hace casi 20 años tener que migrar un enorme proyecto web en asp clásico, un mostrenco que no lo entendia ni el que lo pario.

En una época en que aun no existían aun los frameworks en PHP ni el AJAX, conseguimos plasmar todo en una librería coherente de clases con la que podíamos hacer que un programador nuevo en la empresa pasara a ser productivo en una semana.

Las 100 clases base se fueron ampliando con diferentes objetos de negocio para un ERP y terminaron siendo 5000, pero en todo momento el sistema cargaba solo el código que necesitaba y todo se comportaba como se esperaba que se comportase, porque todo descansaba sobre esas 100 clases basicas y en cuanto un programador metia la garra en una capa superior, el core le recordaba su metedura con una excepcion.

Yo tambien tuve la misma sensación que el OP cuando empece con C++ en el 93, y me costo un par de años de practica activa el entender todas las implicaciones y posibilidades de la POO.
 
Que puedes expandir y profundizar hasta el infinito sin perder el control de lo que estás haciendo.
 
Hablas de la OOP y la comparas con la programación clásica, como si la OOP fuera la última moda de este año.

Ya puestos podías preguntarte qué leches aporta un lenguaje de alto nivel respecto al ensamblador.

Tu pregunta tendría sentido si estuviéramos en 1999...
 
Hablas de la OOP y la comparas con la programación clásica, como si la OOP fuera la última moda de este año.

Ya puestos podías preguntarte qué leches aporta un lenguaje de alto nivel respecto al ensamblador.

Tu pregunta tendría sentido si estuviéramos en 1999...
Hay algo más allá de la POO?
 
Sigo sin ver las ventajas.

A ver, entonces lo de los objetos va referido a conjuntos de variables que definen "algo" dentro del programa?

Los objetos son conjuntos de variables y también de funciones. Cada objeto de un tipo contiene los datos que necesita para funcionar y también los procesos, las funciones, que definen su funcionamiento.

Típicamente, la programación con objetos suele estar relacionada con los programas 'dirigidos por eventos' (event driven programming)

La programación lineal clásica, si se usa de manera natural, da lugar a un programa que depende de unos datos fijos existentes y de un proceso que hay que aplicar a esos datos. El programa toma como entrada unos datos de partida, de una pila de fichas perforadas o los registros de una base de datos, los procesa a su velocidad natural, y genera una salida. El programa trabaja a su ritmo y no hay influencias externas que le molesten.

En los sistemas más modernos, el usuario está constantemente interactuando con el código y el código está esperando acciones (eventos) del usuario a las que responder. Los sistemas en tiempo real, el control de un dron, por ejemplo, o los sistemas de redes, un servido web a la espera clientes que soliciten páginas web, son también sistemas de tipo 'event driven'

Este tipo de cosas son las que se resuelven mejor, en principio, con objetos. Los objetos tienen además otras ventajas en cuanto a coste de producción: el código creado para un programa, es más fácil de heredar y reutilizar en otros programas porque es un 'código empaquetado'. Cada clase de objetos contiene todo lo necesario: datos y funciones que trabajan con esos datos y las clases son heredables: se puede crear una variante de una clase tomando la clase general, más universal, y añadiendo los detalles de la aplicación particular (Digamos que las clases Camión y Autobus derivarían de la clase Vehículo_sobre_ruedas, solo añadiendo los detalles concretos sin reescribir los aspectos generales de la clase Vehículo_sobre_ruedas)

Cuando en Windows o Androide (Java) el usuario clica un botón de una ventana, por ejemplo, Windows o Java capturan ese click y el programa de usuario no tiene que ocuparse de esos detalles, como que la ventana se haya movido de sitio o esté parcialmente oculta por otra ventana.

En ese momento, Windows o Java envían un mensaje (un evento) al botón que ha sido clicado.

El código que define ese botón, que es un objeto de cierta clase, permanece dormido hasta que recibe eventos de ese tipo. En la programación del código de ese botón, se ha configurado el tipo de eventos que recibirá y un comportamiento ante cada tipo de evento, por ejemplo guardar el fichero actual si es el botón 'Save'

Hacer esto con programación lineal es mucho más complicado y a partir de cierto tamaño, resulta imposible porque el 'código central' tiene que atender a cientos de comportamientos no relacionados.

Los programas en código orientado a objetos funcionan como una serie de objetos que se intercambian mensajes entre ellos, muchos de esos mensajes pueden venir del exterior: un usuario que clica con su ratón, un mensaje que llega por la red a un servidor o el sensor de una máquina que controla el programa.

El programador puede concentrarse en cada tipo (clase) de objeto y definir exactamente qué tipos de mensajes recibirá el objeto y cómo será el comportamiento de reacción a cada uno de los tipos de mensajes. La reacción ante los mensajes recibidos suele incluir el envío de mensajes a otros objetos, cosas como file = diskSys.open(filename), en el que un objeto que necesita acceder a un fichero, solicita, mediante ese mensaje, al sistema de ficheros que abra un fichero y se lo envíe.
 
a ver, un programa son variables, lineas de codigo, direccionamientos a la memoria, etc....a que viene todo eso de las clases, instancias, etc?
Vaya soplapollez. Una clase es un tipo de datos y un objeto (o instancia) es una puñetera variable. Nada nuevo bajo el sol.

Lo importante es la herencia y el enlazado dinámico (que se puede conseguir en algunos lenguajes del paradigma estructurado, por ejemplo en C, pero es un ******).

Ponerme un ejemplo sencillito.
No los hay, o al menos no son fáciles de encontrar. Permite solucionar de forma adecuada problemas complejos en proyectos grandes, mediante lo que se ha dado en llamar patrones de diseño. Pero en general no son soluciones ni mucho menos triviales.

Aparte de la herencia también puedes "sobrecargar" los operadores; por ejemplo, si tienes una clase de tipo imagen, vector o matriz, puedes "definir" el operator + para sumar imagenes, sumar vectores, matrices, vectores con matrices, etc.

Esto no tiene nada que ver con la POO, muchos lenguajes funcionales lo permiten de forma más natural que, por ejemplo, C++, java o C#.
 
Un objeto viene a ser mas o menos una libreria en lenguajes imperativos para no tener que repetir el mismo codigo, no tiene el mismo potencial que la programacion orientada a objetos, pero los que nos toca programar en c nos las tenemos que ingeniera para intentar orientarlo a objetos y hacerlo mas legible y mantenible....

Pero vamos, que dependiendo de la envergadura del proyecto, te interesa tirar unas lineas de espaggeti code y hacerlo rapido, u orientarlo a objetos para no estar reescribiendo el mismo codigo en varios sitios.
 
Tu pregunta tendría sentido si estuviéramos en 1999...
En 1999 tendría el mismo sentido que hoy. La POO viene de los 70.

Hay algo más allá de la POO?
No. Me parece a mí que no hay mucho más que rascar. Está el paragima funcional, que es aún más antiguo (LISP, años 50) pero tuvo un resurgimiento a principios de siglo, pero creo que está de capa caída otra vez. Haskell es muy interesante.

Y ahora se tiende sobre todo al paradigma mixto.

C# por ejemplo es orientado a objetos pero con LINQ tienes tienes una librería de estilo funcional potentísima para manejar colecciones.

Luego está el minimalismo extremo del big data y su map-reduce. Pero eso es otra vuelta de tuerca a la funcional.

Y para terminar tenemos el paradigma lógico que siempre me ha parecido una tontería. Supongo que tendrá sus usos pero no he sabido encontrarlos. También es antiquísimo.
 
Ya que mencionas lo de hacer un videojuego, la POO es ideal.

En el "mundo" del juego, cada cosa que ves es un "actor", una clase. Corren todas a la vez, y puedes leer variables de una a otra de una forma simple teniendo sus referencias. Un juego no es un proceso lineal, sino que tiene muchos "actores" a la vez ejecutando su propio código.

Por ejemplo puedes hacer una clase progenitora para un NPC, y luego crear nuevas clases para NPCs diferentes, "heredando" todo el código previo de esa clase progenitora, añadiendo cosas o cambiándolas (polimorfismo), de modo que modificando algo en la clase progenitora, se modifican automáticamente en todas las demás.

Un NPC es el mejor ejemplo de un objeto, que hereda las carácterísticas de la clase padre pero gestiona sus propias variables internas, desde la posición en la que se encuentra ubicado a que le hayas pegado un tiro previamente y te espere cabreado para aniquilarte (tiene un estado interno propio que depende de lo que le pasa solo a él). Multiplícalo por los NPCs de un juego de mundo abierto y ahí tienes la utilidad.

Si tu programa consiste en un listado de productos con su precio, su tonalidad y numero de unidades en stock, la POO no es para ti. Cuando tu programa se complique más y más te darás cuenta que tienes que tener controladas todas las variables de tu "NPC" que fuera del objeto en sí no valen para nada menos para dar ruido e interferir con el exterior del objeto.

PD: yo tampoco veía clara la utilidad de la POO hasta que me hizo falta.
 
Un NPC es el mejor ejemplo de un objeto, que hereda las carácterísticas de la clase padre pero gestiona sus propias variables internas, desde la posición en la que se encuentra ubicado a que le hayas pegado un tiro previamente y te espere cabreado para aniquilarte (tiene un estado interno propio que depende de lo que le pasa solo a él). Multiplícalo por los NPCs de un juego de mundo abierto y ahí tienes la utilidad.

Pero eso no aporta nada. Composition over inheritance - Wikipedia
 
Volver