Desde mi punto de vista, la programación dirigida a objetos es una evolución clara de la programación estructurada, al añadir nuevos niveles de abstracción y agrupamiento en el código (estructura de clases, polimorfismo, etc.) El salto mental desde la programación estructurada es mucho menor que si nos pasamos a otros tipos lenguajes (funcionales, etc), aun cuando la curva de aprendizaje de dichos lenguajes para principiantes parece ser menor.
En mi trabajo la programación orientada a objetos me proporciona la capacidad de no reescribir 40000 veces el mismo codigo y aun asi mantener la eficiencia dentro de unos margenes utiles. También simplifica el reparto de trabajo entre un grupo de personas una vez se han identificado los objetos de un proyecto.
Tambien es verdad que estoy empezando a considerar otro tipo de lenguajes (en este caso funcionales, como es Haskell). Pero por ahora me quedo con la PDO.
Nos vemos.
-- -- Obstáculos es lo que ves cuando apartas la vista del objetivo.
Supongo que con PDO te refieres a la POO, no? Nunca habia oido ese nombre, aunque vamos, por lo que leo en el enlace es lo mismo ;)
Bien... aunque la gente se empeñe en decir lo contrario, la POO es el lenguaje ideal para solucionar la gran mayoria de problemas de programación. Si bien es cierto que la programacion por procedimientos (véase C) se puede usar aún para hacer cualquier cosa, también es cierto que el código homólogo en POO (véase C++) acostumbra a ser muchísimo más claro y bien estructurado. Eso sí, todo depende del diseño que implemente el programador: si es malo, un programa en POO será imposible de mantener, talvez incluso más difícil que uno en C.
Algunas de las técnicas de la POO se pueden aplicar en otros lenguajes. Retomando el ejemplo de C, puedes usar estructuras para mantener los datos y luego obligar a cada función relacionada recibir un puntero a una estructura de éstas para recibir toda la información. En POO es tan simple como declarar una clase que engloba el funcionamiento de este tipo de datos.
De hecho, hace un tiempo empecé un proyecto en C, creando una librería (ver el thread de "Diferentes Makes" ;) basada en gran parte en tipos de datos y objetos. Total, que no tardé mucho en decidir reempezar el poco código que llevaba en C++, y ahora es mucho más legible que antes.
O sino toma el ejemplo de Gnome, y que los de Gnome no se ofendan. Éstos defienden el uso de C; pero ¿que estan haciendo? Estan implementando las técnicas típicas de POO en este lenguaje (herencia, polimorfismo y encapsulación), para conseguir algo similar a C++.
Yo creo que las ventajas que tiene la Programación Orientada a Objetos frente a la procedural, es principalmente que obliga al programador a programar de una manera determinada, y sobre todo, estructurada y modular (y más). Digamos que "fuerza" al programador a pensar.
Eso también se puede hacer con lenguajes procedurales como C, pero requiere que el programador ponga más de su parte.
También creo que cabe reseñar que en general me parece que los programas escritos con orientación a objetos (da igual si en un lenguaje pensado para ello como C++, o no, como el C) son más difíciles de entender para las personas que no lo han escrito, en comparación con algo escrito de forma estructurada/modular sin meter objetos y en especial jerarquías.
Se nota sobre todo a la hora de seguir el código y ver qué hace cada rutina (sobre todo por el tema de herencias, ...)
Pienso que hay que tener en cuenta que a pesar que la POO se inventó hace años (más de 20 si no me equivoco) todavía se sigue escribiendo mucho código en lenguajes procedurales, por lo que es bastante claro que los lenguajes procedurales no traen tanta "ventaja". Lo mismo ocurre con la POO, para algunas cosas esta muy bien (mirar el GTK, es una maravilla de la POO y está en C) pero creo que para otras cosas no es lo más adecuado.
Me ha sorprendido ver en los anteriores comentarios como los anteriores en los que enfrentan la programacion orientada a objetos con el lenguaje C.
Para mí ese es una forma de ver la cuestión muy a la ligera. Y más teniendo en cuenta de que gtk esta orientado a objetos y esta escrito en C.
Si queréis ver cómo se puede hacer algo así, y no tenéis ganas de leerlo en inglés, pues aquí hay un pequeño manualito que está escribiendo Deepe aquí.
Por cierto, si os lo leéis y veis alguna falta o fallo, pues nada, rogaría un mail con información sobre ello... :], gracias,
Las ventajas de un lenguaje POO no estan tanto en la POO (aunque evidentemente derivan de ello), sino en el framework que uses. Los lenguajes POO serian inusables sin un buen framework con una jerarquia bien estructurada. ¿Por que? Porque toda la estructura jerarquica deriva de una estructura de clases base clara y concisa (generica). Todos los objetos subsiguientes deben tener la misma estructura con pocas o nulas modificaciones en la estructura misma. De ahi que conociendo las clases base puedes conocer las derivadas sin mucho problema.
En la programacion estructurada tradicional te encuentras muchas veces con que las diferentes bibliotecas no siguen estructuras "predecibles" a priori, con lo que te las tienes que aprender en mayor medida, con todo lo que supone en esfuerzo y tiempo. Cierto es que con cosas tipo GTK la cosa se flexibiliza mucho. La interfaz coherente tambien es posible en C, pero cuesta mucho mas de hacer y es bastante menos consistente... Lo cual no significa que no sea una opcion valida.
En definitiva, es algo que depende del proyecto. Es mucho mejor programar un sistema operativo en C ya que sus bibliotecas son accesibles facilmente por cualquier lenguaje, cosa no tan simple con un lenguaje POO como C++. Al mismo tiempo, hacer una utilidad como "cp" en C++ es bastante absurdo, pero diseñar un videojuego 3D es C es bastante mas complejo que en C++ (al menos su logica, las interioridades son otra cosa).
-- "Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
Un sistema operativo se puede hacer con cualquier lenguaje que sea capaz de generar binarios, no nos rayemos... Pero no resulta practico hacerlo en C++, puesto que no todos los lenguajes son orientados a objetos y resultaria extremadamente complicado llegar a un acuerdo de funcionamiento y compatibilidad...
Lo que realmente hace que un sistema operativo sea usable es precisamente la biblioteca del sistema... Es esta biblioteca (a no ser que programas a bajo nivel, claro) la que permite el desarrollo de aplicaciones. Sin ella (y sin otras muchas), un SO no sirve para nada... Por eso me he referido a ellas y no al SO en si.
-- "Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
A eso tienes que sumarle el tiempo de carga que sera mayor ya que C++ hace uso de muchas mas librerias que en programa C normal.
A ver si nos aclaramos. El tiempo de carga aumenta con el aumento de símbolos a enlazar... En C++ ese número de símbolos crece explosivamente al trabajar con métodos virtuales, pero además en Linux es un problema crónico del 'ld'.
Luego tienes la RTTI, que no la has nombrado para nada, lo que me hace pensar que ni la conoces, y el asunto es que (oh, sorpresa), si no la usas (cosa harto frecuente), la puedes desactivar.
Más allá tenemos todo el asunto de encapsulación, herencia, etc... y perdona que te diga, en su inmensa mayoría es trabajo de compilación, y no de ejecución, como ya te dijeron, con lo cual tampoco resta tiempo (bueno, sí, tarda más en compilar, pero eso nada más).
Uséase que búscate una excusa mejor.
Pero en el fondo que mas da, para ver la mierda de programas que hace un españolito medio da igual el lenguaje.
Jojojo. Ahora resulta que la calidad del código va con la nacionalidad. ¡No te jode!
Me sorprendre que proyectos como GNU apoyen el uso del lenguaje C frente a otros a mi parecer más avanzados y/o cómodos de utilizar.
Pero lo que me sorprende más es el hecho de argumentar esta decisión basándose en que C es el 'lenguaje universal' (el que la mayoría de gente conoce). Acaso Windows no es el OS universal? Y qué hace pués la GNU desarrollando código para sistemas no tan conocidos?
No tiene nada que ver una cosa con la otra... Las motivaciones son variadas, e independientemente de que C sea un lenguaje mas conocido (motivo ademas mas que suficiente para adoptarlo), hasta ahora no se ha encontrado nada mejor para el desarrollo de un sistema operativo (excepcto ensamblador, claro), y lo importante del sistema GNU es que sea tremendamente portable, y eso solo se consigue al 100% con C... Ademas, tambien se aplica lo que dije antes de las bibliotecas del sistema: es mucho mejor desarrollar una biblioteca de sistema en C, porque sera enlazable desde cualquier lenguaje sin problemas, que desde otro lenguaje, sobre todo si el lenguaje esta orientado a objetos. El sistema GNU debe funcionar en cualquier sistema porque la mision es llevar el software libre a cualquier sitio, y no a los mas usados solamente. Segun tu teoria, Windows tambien deberia estar desarrollado sobre C++ y las APIs estan todas en C... En cualquier sistema moderno, lo basico esta escrito en C y ensamblador, y lo de encima se monta sobre lo que quieras. No confundamos unas cosas con otras...
-- "Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
jeje, el comentario anterior se escribio justo a la misma vez que el mio, mira la hora.. Perdona que no lo leyera, pero es que estaba escribiendo el mio... ;).
El otro chico ( el corrector ), puede que sea yo ;).. Salu2
Mas que un paradigma, lo que veo es que se trata de una adopcion de buenas costumbres de codificacion y diseño orientados a objetos... No lo veo como una nueva forma de crear aplicaciones, sino como una forma de aplicar lo actual de forma diferente, tal vez mejor...
-- "Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
Ciertamente, es algo compleja la programación orientada a aspectos (al menos eso me parece). La verdad es que lo poco que sé es lo que ví desde el punto de vista teórico en un curso de doctorado y algo más en la práctica, con la aproximación de IBM a la Programación Orientada a Aspectos (HyperJ).
Lo que saqué en claro es que esta tecnología aún está en pañales (aunque hay muchos grupos de investigación estudiándola), y que su implantación aún está lejos (pongámosle 10 años para que la industria acoja masivamente este paradigma). Vamos, que aún tenemos bastante tiempo para aprender. ;-)
Pooos no... COM se hizo como interfaz para hacer creer al sistema que las funciones C funcionan como objetos... ¿Que crees que es Gnome? Una implementacion de COM que pueden tener una envoltura C++ o de cualquier otro lenguaje. DirectX es tan C como el resto de Windows.
Y yo no me he referido al sistema operativo porque es la interfaz entre la maquina y las aplicaciones, no una cosa concreta que podamos tomar de forma tangible... Es decir, que para las aplicaciones, el SO es la API. Por diox, que ya no se programan las interrupciones desde MSDOS... Para eso precisamente esta la libreria C, para no tener que bajar tanto. El nucleo se convierte, gracias a esto, en el software que implementa las llamadas en si, y la biblioteca la logica de las llamadas.
-- "Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
Bien, vale, aceptamos barco como animal acuatico...
Pero no es un paradigma nuevo propiamente dicho, o al menos segun lo que he leido. No aporta elementos nuevos en el lenguaje que no se puedan implementar directamente desde OOP. Cuando vea un lenguaje diseñado especificamente para tratar AOP de forma completa y que presente diferencias visibles respecto de OOP, entonces hablamos...
-- "Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
-¿Creéis que merece la pena todavía apoyar la PDO?
Si, salvo en proyectos muy pequeños o con una funcionalidad muy especializada (p.e. drivers)
-¿Creéis que realmente los lenguajes más usados son dirigidos a objetos?
Desde mi punto de vista, hay una gran apuesta por parte de los desarrolladores de lenguajes para aportar caracteristicas de OOP, por ejemplo, en PHP se introdujeron a posteriori y Microsoft a la hora de diseñar C#, ni se planteo otra cosa que no fuera un lenguaje OO. De todas formas, estoy totalmente de acuerdo con lo que han dicho algunos BPeros acerca de que es posible (aunque mas tedioso) la OO en lenguajes como C, el ejemplo mas asombroso que he visto de esto es un libro de Microsoft a cerca de Patrones de Diseño en Visual Basic (que dios nos ayude!!) . Personalmente, si no fuera por algunas penitencias que tengo que pasar (VB), el resto de lenguajes que utilizo son todos OO, o semi-OO.
-¿Qué razones daríais para apoyar la PDO frente a la programación funcional, o la procedural?"
Yo creo que la ventaja fuerte (siguiendo alguno de los argumentos que se han escrito) es a la hora del diseño. Personalmente, me da la impresion de que la fase de Diseño es muchas veces (mas de las que creemos) la mas abandonada o descuidada en el desarrollo de un proyecto; desde este punto de vista, creo que la OOP a traido un acercamiento estructurado a esta fase. Cosas como los Patrones de Diseño, hubiesen sido muy dificiles de especificar o extender en otro marco que no fuese la OOP, y creo que es en este sentido, (buscar metodologias de construccion del software) en el que se debe avanzar para llegar a una fiabilidad y garantía que hoy por hoy (muy a nuestro pesar) no tienen los proyectos.
Al grano. Lo primero es diferenciar entre lenguajes de programación que son considerados OO y la POO en si. Cada lenguaje tiene sus propias características, ventajas y desventajas, pero no creo que se trate de eso de lo que quieras hablar. Ciñéndonos a la POO y poniendonos técnicos (y según dice el libro en el que me estoy 'inspirando' : ) ) las características principales que se cumplen en la POO:
Abstracción: capacidad de representar las propiedades importantes de un objeto, dejando las no esenciales (las que no interesan). La herramienta utilizada para esto son las clases.
Encapsulamiento: propiedad que asegura que el contenido de un objeto no sea accesible a otros.
Modularidad: propiedad para dividir una aplicación en partes más pequeñas.
Jerarquía: capacidad de ordenar las abstracciones.
Polimorfismo: capacidad de que una entidad tome diversas formas (puedo referirme a un objeto de diversas formas).
La unión de estas características proporcionan un paradigma distinto al de la programación estructurada. ¿Ventajas? pues estas características en si la ventaja de la POO, que nos llevan a crear un software 'mejor'.
Por lo demás un comentario: tradicionálmente se aprende antes programación estructurada que OO, por lo que en informática se tiende a considerar a la OO un escalón superior, algo más complejo a la hora de programar. Y esa complejidad es el precio a pagar por utilizar un paradigma que a cambio nos permite desarrollar software de más calidad en cuanto a que cumple con las propiedades que mencione antes: encapsulamiento... Sin embargo yo estoy en el grupo de los que empezamos a dudar incluso de esa 'tradición'. No olvidemos que la OO está más cerca del mundo real (que está hecho de objetos o 'cosas', ya sean estos objetos físicos, hechos, relaciones, roles, lugares...) que la programación estructurada. Así que a la hora de modelar un problema (salvo que el tamaño de este sea ridículo) nos encontramos con que la solución surge más clara y fácilmente pensando en objetos que en procedimientos.
Precisamente esa es la idea, encapsular objetos y llamarlos con interfaces
En los lejanos tiempos del clipper, en un programa de gestión hice una función que se ocupaba de actualizar el almacén, de manera que estaba centralizado. La función se fué haciendo más compleja y terminé pasandole una matriz con todos los parámetros, que se inicializaba con ciertos valores por defecto, y desde fuera sólo utilizaba los que necesitaba.
Ahora lo sé, realmente lo que había hecho era un objeto utilizando un lenguaje que no estaba especializado en ello. Este objeto maravilloso me permitía olvidarme del almacén, testear los datos, como estaban implementadas las bases de datos, como se actualizaban precios medios etc.., era un joya
Los objetos son una maravilla, aunque reconozco que es muy facil pasarse, utilizarlos fuera de lugar o en exceso.
¿Te refieres a la Programacion Orientada a Objetos? Imagino que sí.
Apoyo la POO por ser más estructurada que la programacion con funciones (aunque no la he utilizado demasiado).
La POO necesita más recursos pero es interesante aplicarla en proyectos de tamaño considerable y cuando existe un equipo de personas que trabaja para el mismo projecto.
Sin duda, Java, entre otros, es un lenguaje que se utiliza cada vez más.
El pollo que quiere montar Moco$oft con su estrategia .NET se basa en la orientacion a objetos (si no me equivoco demasiado).
Saludos
PD: Buscate cualquier libro de C++ o Java y te lees las diferencias que hay entre las dos formas de "pogramá"
Creo que no, al menos segun lo que he estado leyendo... Aunque en un principio podemos considerar que los objetos no son algo exclusivo de lenguajes como C++, al parecer, que puede ser que me equivoque (y es mas que probable, puesto que la poca documentacion que he podido encontrar es extrañamente muy criptica...), el AOP es algo a utilizar sobre todo sobre lenguajes OOP propiamente dichos. Porque puede ser tanto un tipo de lenguaje como una tecnica (como es el caso de los objetos en C). No te digo que en el futuro no llegue a tener encarnacion linguistica, pero sera cuando este suficientemente maduro, y cuando realmente represente un adelanto concreto en el paradigma de programacion.
-- "Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
Está claro que con C es posible programar orientado a objetos, la cuestión es que el lenguaje no te da facilidades para hacerlo como te pueda dar C++ por ejemplo, de modo que tú mismo debes currártelo para crear esos objetos.
De la misma manera, con BASIC (no VB, el clásico de toda la vida) se puede programar estructurado aun cuando el lenguaje no lo es, es decir no tiene procedimientos ni funciones, pero con un poco de habilidad las puedes emular.
Es más, el código generado por un compilador de un lenguaje orientado a objetos o uno estructurado al final va a acabar siendo código máquina que no es ni estructurado ni mucho menos orientado a objetos.
33 respuestas por debajo de tu umbral de lectura actual.
Simplifica el diseño y la programación
(Puntos:1)( http://enlavin.com/ )
Desde mi punto de vista, la programación dirigida a objetos es una evolución clara de la programación estructurada, al añadir nuevos niveles de abstracción y agrupamiento en el código (estructura de clases, polimorfismo, etc.) El salto mental desde la programación estructurada es mucho menor que si nos pasamos a otros tipos lenguajes (funcionales, etc), aun cuando la curva de aprendizaje de dichos lenguajes para principiantes parece ser menor.
En mi trabajo la programación orientada a objetos me proporciona la capacidad de no reescribir 40000 veces el mismo codigo y aun asi mantener la eficiencia dentro de unos margenes utiles. También simplifica el reparto de trabajo entre un grupo de personas una vez se han identificado los objetos de un proyecto.
Tambien es verdad que estoy empezando a considerar otro tipo de lenguajes (en este caso funcionales, como es Haskell). Pero por ahora me quedo con la PDO.
Nos vemos.
-- Obstáculos es lo que ves cuando apartas la vista del objetivo.
Mucho mejor usar PDO
(Puntos:1)( http://julipedia.blogspot.com/ )
Supongo que con PDO te refieres a la POO, no? Nunca habia oido ese nombre, aunque vamos, por lo que leo en el enlace es lo mismo ;)
Bien... aunque la gente se empeñe en decir lo contrario, la POO es el lenguaje ideal para solucionar la gran mayoria de problemas de programación. Si bien es cierto que la programacion por procedimientos (véase C) se puede usar aún para hacer cualquier cosa, también es cierto que el código homólogo en POO (véase C++) acostumbra a ser muchísimo más claro y bien estructurado. Eso sí, todo depende del diseño que implemente el programador: si es malo, un programa en POO será imposible de mantener, talvez incluso más difícil que uno en C.
Algunas de las técnicas de la POO se pueden aplicar en otros lenguajes. Retomando el ejemplo de C, puedes usar estructuras para mantener los datos y luego obligar a cada función relacionada recibir un puntero a una estructura de éstas para recibir toda la información. En POO es tan simple como declarar una clase que engloba el funcionamiento de este tipo de datos.
De hecho, hace un tiempo empecé un proyecto en C, creando una librería (ver el thread de "Diferentes Makes" ;) basada en gran parte en tipos de datos y objetos. Total, que no tardé mucho en decidir reempezar el poco código que llevaba en C++, y ahora es mucho más legible que antes.
O sino toma el ejemplo de Gnome, y que los de Gnome no se ofendan. Éstos defienden el uso de C; pero ¿que estan haciendo? Estan implementando las técnicas típicas de POO en este lenguaje (herencia, polimorfismo y encapsulación), para conseguir algo similar a C++.
Saludos
The Julipedia [blogspot.com]
POO vs Procedural
(Puntos:1)( http://barrapunto.com/ )
Eso también se puede hacer con lenguajes procedurales como C, pero requiere que el programador ponga más de su parte.
También creo que cabe reseñar que en general me parece que los programas escritos con orientación a objetos (da igual si en un lenguaje pensado para ello como C++, o no, como el C) son más difíciles de entender para las personas que no lo han escrito, en comparación con algo escrito de forma estructurada/modular sin meter objetos y en especial jerarquías.
Se nota sobre todo a la hora de seguir el código y ver qué hace cada rutina (sobre todo por el tema de herencias, ...)
Pienso que hay que tener en cuenta que a pesar que la POO se inventó hace años (más de 20 si no me equivoco) todavía se sigue escribiendo mucho código en lenguajes procedurales, por lo que es bastante claro que los lenguajes procedurales no traen tanta "ventaja". Lo mismo ocurre con la POO, para algunas cosas esta muy bien (mirar el GTK, es una maravilla de la POO y está en C) pero creo que para otras cosas no es lo más adecuado.
Enlar
Programacion en C vs OOP
(Puntos:1)( http://www.kikov.org/ | Última bitácora: Domingo, 14 Diciembre de 2003, 14:31h )
Para mí ese es una forma de ver la cuestión muy a la ligera. Y más teniendo en cuenta de que gtk esta orientado a objetos y esta escrito en C.
Si queréis ver cómo se puede hacer algo así, y no tenéis ganas de leerlo en inglés, pues aquí hay un pequeño manualito que está escribiendo Deepe aquí.
Por cierto, si os lo leéis y veis alguna falta o fallo, pues nada, rogaría un mail con información sobre ello... :], gracias,
Saludos.
Salu2
Ventajas
(Puntos:2)( http://es.gnu.org/ )
En la programacion estructurada tradicional te encuentras muchas veces con que las diferentes bibliotecas no siguen estructuras "predecibles" a priori, con lo que te las tienes que aprender en mayor medida, con todo lo que supone en esfuerzo y tiempo. Cierto es que con cosas tipo GTK la cosa se flexibiliza mucho. La interfaz coherente tambien es posible en C, pero cuesta mucho mas de hacer y es bastante menos consistente... Lo cual no significa que no sea una opcion valida.
En definitiva, es algo que depende del proyecto. Es mucho mejor programar un sistema operativo en C ya que sus bibliotecas son accesibles facilmente por cualquier lenguaje, cosa no tan simple con un lenguaje POO como C++. Al mismo tiempo, hacer una utilidad como "cp" en C++ es bastante absurdo, pero diseñar un videojuego 3D es C es bastante mas complejo que en C++ (al menos su logica, las interioridades son otra cosa).
"Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
Re:Ventajas
(Puntos:2)( http://es.gnu.org/ )
Lo que realmente hace que un sistema operativo sea usable es precisamente la biblioteca del sistema... Es esta biblioteca (a no ser que programas a bajo nivel, claro) la que permite el desarrollo de aplicaciones. Sin ella (y sin otras muchas), un SO no sirve para nada... Por eso me he referido a ellas y no al SO en si.
"Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
Re:cada cosa para lo que es
(Puntos:2)( http://quie.blogalia.com/ )
A ver si nos aclaramos. El tiempo de carga aumenta con el aumento de símbolos a enlazar... En C++ ese número de símbolos crece explosivamente al trabajar con métodos virtuales, pero además en Linux es un problema crónico del 'ld'.
Luego tienes la RTTI, que no la has nombrado para nada, lo que me hace pensar que ni la conoces, y el asunto es que (oh, sorpresa), si no la usas (cosa harto frecuente), la puedes desactivar.
Más allá tenemos todo el asunto de encapsulación, herencia, etc... y perdona que te diga, en su inmensa mayoría es trabajo de compilación, y no de ejecución, como ya te dijeron, con lo cual tampoco resta tiempo (bueno, sí, tarda más en compilar, pero eso nada más).
Uséase que búscate una excusa mejor.
Pero en el fondo que mas da, para ver la mierda de programas que hace un españolito medio da igual el lenguaje.
Jojojo. Ahora resulta que la calidad del código va con la nacionalidad. ¡No te jode!
Sorprendente
(Puntos:1)( http://frosas.net/ )
Pero lo que me sorprende más es el hecho de argumentar esta decisión basándose en que C es el 'lenguaje universal' (el que la mayoría de gente conoce). Acaso Windows no es el OS universal? Y qué hace pués la GNU desarrollando código para sistemas no tan conocidos?
Re:Sorprendente
(Puntos:2)( http://es.gnu.org/ )
"Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
Re:Ventajas
(Puntos:1)( http://diariolinux.com )
-- Rocket propelled cars cause lots of flames unfortunately 8) - Alan Cox
Re:Programacion en C vs OOP
(Puntos:1)( http://www.kikov.org/ | Última bitácora: Domingo, 14 Diciembre de 2003, 14:31h )
El otro chico ( el corrector ), puede que sea yo ;).. Salu2
Salu2
Re:Programacion en C vs OOP
(Puntos:1)( http://www.kikov.org/ | Última bitácora: Domingo, 14 Diciembre de 2003, 14:31h )
Saludos.
Salu2
Re:Programacino Orientada a Aspectos
(Puntos:2)( http://es.gnu.org/ )
"Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
Re:Programacion Orientada a Aspectos
(Puntos:2)( http://www.superiodico.net/ )
Lo que saqué en claro es que esta tecnología aún está en pañales (aunque hay muchos grupos de investigación estudiándola), y que su implantación aún está lejos (pongámosle 10 años para que la industria acoja masivamente este paradigma). Vamos, que aún tenemos bastante tiempo para aprender. ;-)
--- www.superiodico.net * Crónicas de un enrea
Re:Sorprendente
(Puntos:2)( http://es.gnu.org/ )
Pooos no... COM se hizo como interfaz para hacer creer al sistema que las funciones C funcionan como objetos... ¿Que crees que es Gnome? Una implementacion de COM que pueden tener una envoltura C++ o de cualquier otro lenguaje. DirectX es tan C como el resto de Windows.
Y yo no me he referido al sistema operativo porque es la interfaz entre la maquina y las aplicaciones, no una cosa concreta que podamos tomar de forma tangible... Es decir, que para las aplicaciones, el SO es la API. Por diox, que ya no se programan las interrupciones desde MSDOS... Para eso precisamente esta la libreria C, para no tener que bajar tanto. El nucleo se convierte, gracias a esto, en el software que implementa las llamadas en si, y la biblioteca la logica de las llamadas.
"Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
Re:Programacino Orientada a Aspectos
(Puntos:2)( http://es.gnu.org/ )
Pero no es un paradigma nuevo propiamente dicho, o al menos segun lo que he leido. No aporta elementos nuevos en el lenguaje que no se puedan implementar directamente desde OOP. Cuando vea un lenguaje diseñado especificamente para tratar AOP de forma completa y que presente diferencias visibles respecto de OOP, entonces hablamos...
"Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
La OOP facilita metodologias de Diseño
(Puntos:1)( http://talika.fie.us.es/pablo )
Un saludo,
Pablo.
POO vs. programación estructurada.
(Puntos:1)Al grano. Lo primero es diferenciar entre lenguajes de programación que son considerados OO y la POO en si. Cada lenguaje tiene sus propias características, ventajas y desventajas, pero no creo que se trate de eso de lo que quieras hablar. Ciñéndonos a la POO y poniendonos técnicos (y según dice el libro en el que me estoy 'inspirando' : ) ) las características principales que se cumplen en la POO:
Abstracción: capacidad de representar las propiedades importantes de un objeto, dejando las no esenciales (las que no interesan). La herramienta utilizada para esto son las clases.
Encapsulamiento: propiedad que asegura que el contenido de un objeto no sea accesible a otros.
Modularidad: propiedad para dividir una aplicación en partes más pequeñas.
Jerarquía: capacidad de ordenar las abstracciones.
Polimorfismo: capacidad de que una entidad tome diversas formas (puedo referirme a un objeto de diversas formas).
La unión de estas características proporcionan un paradigma distinto al de la programación estructurada. ¿Ventajas? pues estas características en si la ventaja de la POO, que nos llevan a crear un software 'mejor'.
Por lo demás un comentario: tradicionálmente se aprende antes programación estructurada que OO, por lo que en informática se tiende a considerar a la OO un escalón superior, algo más complejo a la hora de programar. Y esa complejidad es el precio a pagar por utilizar un paradigma que a cambio nos permite desarrollar software de más calidad en cuanto a que cumple con las propiedades que mencione antes: encapsulamiento... Sin embargo yo estoy en el grupo de los que empezamos a dudar incluso de esa 'tradición'. No olvidemos que la OO está más cerca del mundo real (que está hecho de objetos o 'cosas', ya sean estos objetos físicos, hechos, relaciones, roles, lugares...) que la programación estructurada. Así que a la hora de modelar un problema (salvo que el tamaño de este sea ridículo) nos encontramos con que la solución surge más clara y fácilmente pensando en objetos que en procedimientos.
Interfaces
(Puntos:2)( http://barrapunto.com/ | Última bitácora: Viernes, 29 Diciembre de 2017, 18:26h )
Precisamente esa es la idea, encapsular objetos y llamarlos con interfaces
En los lejanos tiempos del clipper, en un programa de gestión hice una función que se ocupaba de actualizar el almacén, de manera que estaba centralizado. La función se fué haciendo más compleja y terminé pasandole una matriz con todos los parámetros, que se inicializaba con ciertos valores por defecto, y desde fuera sólo utilizaba los que necesitaba.
Ahora lo sé, realmente lo que había hecho era un objeto utilizando un lenguaje que no estaba especializado en ello. Este objeto maravilloso me permitía olvidarme del almacén, testear los datos, como estaban implementadas las bases de datos, como se actualizaban precios medios etc.., era un joya
Los objetos son una maravilla, aunque reconozco que es muy facil pasarse, utilizarlos fuera de lugar o en exceso.
¿POO?
(Puntos:1)Apoyo la POO por ser más estructurada que la programacion con funciones (aunque no la he utilizado demasiado).
La POO necesita más recursos pero es interesante aplicarla en proyectos de tamaño considerable y cuando existe un equipo de personas que trabaja para el mismo projecto.
Sin duda, Java, entre otros, es un lenguaje que se utiliza cada vez más.
El pollo que quiere montar Moco$oft con su estrategia .NET se basa en la orientacion a objetos (si no me equivoco demasiado).
Saludos
PD: Buscate cualquier libro de C++ o Java y te lees las diferencias que hay entre las dos formas de "pogramá"
Re:Programacino Orientada a Aspectos
(Puntos:2)( http://es.gnu.org/ )
"Hazme sufrir, hazme mala... ¿Me lo has hecho sentir ya?"
Re:Programacion en C vs OOP
(Puntos:1)( http://presi.org/ )
De la misma manera, con BASIC (no VB, el clásico de toda la vida) se puede programar estructurado aun cuando el lenguaje no lo es, es decir no tiene procedimientos ni funciones, pero con un poco de habilidad las puedes emular.
Es más, el código generado por un compilador de un lenguaje orientado a objetos o uno estructurado al final va a acabar siendo código máquina que no es ni estructurado ni mucho menos orientado a objetos.