Discusión:Programación orientada a objetos

message: He reordenado y reagrupado algunos puntos repetidos.
He añadido un par de líneas (evento, estado interno).
He reordenado la lista por orden alfabético.
Al respecto de esto: ¿no habría que distinguir entre lenguajes con orientación a objetos pura como Smalltalk, Ruby, Haskell (que no está en la lista, por cierto), y el resto?
(miguelsan, 18-2-06)
:Añade tu mismo haskell ;), por otro lado habría que ampliar bastante el artículo de Haskell (que si nadie lo hace y tengo tiempo lo haré 0:) ), comentando sus peculiaridades en la OO. (Todo el tema de Class Objeto obj .. instance obj, etc.) Y con respecto a este artículo: 
:Otra manera en que esto es expresado a menudo, es que la programación orientada a objetos anima al programador a pensar en los programas principalmente en términos de tipos de datos, y en segundo lugar en las operaciones ("métodos") específicas a esos tipos de datos. Los lenguajes procedurales animan al programador a pensar sobre todo en términos de procedimientos, y en segundo lugar en los datos que esos procedimientos manejan.  Me da a entender que da una especie de visión de separación entre datos y métodos (el hecho de pensar primero en datos y luego en métodos), cosa que para nada tiene que ver con la orientación a objetos, al contrario, hay que pensar en los objetos como un bloque, y si me apuras (y esto si que se menciona más abajo), mediante una buena utilización del principio de ocultación de la información, los datos que maneje/estén asociados al objeto no deberían ser lo primero en lo que piense el programador, aunque ocultar la información si debería serlo. Por todo esto, lo primero en lo que puede pensar el programador (aunque es otra forma de diseñar y trabajar con la OO), es en ocultar la información, llegando al extremo de camuflar nombres de métodos y olvidarse de getters y setters ... pero esto es otra historia :P, que no se quedaría simplemente aquí (otro artículo quizás). :- Lasneyx'nid Entrada Casa Iliah [de,o] 20:55 2 mar 2006 (CET)
replies: text: En realidad, la OO si puede verse como primero en base a las estructuras de datos (y no a los tipos o a los datos a secas como estaba en el articulo) y luego a los métodos (al reves pues que en la prog. procedural). Cambie en el articulo datos a secas o tipos de datos por estructuras de datos. —Jstitch (discusión) 21:13 2 mar 2006 (CET)
thread_title:  Reordenación 

message: En el artículo y en las propuestas de cambio insisten en diferenciar la programación orientada a objetos de la programación imperativa. Para ello dicen cómo piensan los programadores imperativos. En mi opinión hay un error en esa oposición. La programación imperativa es algo anterior en el tiempo y más amplia en su definición. No implica que el programador tenga que pensar por separado funciones y datos ni que tenga que pensar primero las funciones y luego los datos. 
La POO es un gran avance en las Ciencias Informáticas. La POO aporta a la programación imperativa definiendo una forma coordinada entre código y datos que se basa en un soporte sintáctico y semántico creando lenguajes, compiladores y entornos de ejecución de una generación superior a los que antes existían para los lenguajes imperativos. La POO es una evolución de la programación imperativa pero no es opuesta. 
O sea, creo que no hace falta "enterrar" la programación imperativa ni a sus programadores. Hay que entenderla como algo anterior y menos específico. Espero haber aportado algo a la discusión. Tute 14:15 6 abr 2006 (CEST)
thread_title:  La programación imperativa no se opone a la POO 

message: desde que microsoft compro el lenguaje y lo añadio a su plataforma .net ese lenguaje desaparecio.
* sí, hay gente que lo usa. Soy profesor en la universidad y muchos de mis alumnos trabajan en empresas de desarrollo de sistemas. El Fox Pro se sigue usando (el COBOL también). Claro que se usa muy poco y nadie en el ambiente académico lo recomienda, pero eso es otro problema. Tute 19:05 29 may 2007 (CEST)
thread_title:  Fox Pro ¿Existe Todavia? ¿Alguien lo Usa? 

message: Ada cumple con todas las características de la OOP:
abstracción, encapsulamiento, principio de ocultación, polimorfismo y herencia.
Que el que opine lo contrario lo justifique. —Tute 04:32 8 jul 2007 (CEST)
thread_title:  Ada sí es OOP (tanto como C++, Java o Eiffel) 

message: Tanto nuestro artículo sobre encapsulamiento como el artículo en inglés, cuyo título principal es :en:Information hiding (ocultamiento de información, aunque también se redirige desde :en:Encapsulation (object-oriented programming)) como el artículo en francés (:fr:Encapsulation (programmation)) definen claramente el concepto como la idea de esconder información contenida en los objetos, permitiendo que sea visible sólo la que gobierna las actuaciones del objeto. El alemán no está a mi alcance, pero con ayuda de un amable traductor automático, tiendo a pensar que :de:Datenkapselung (Programmierung) también confunde encapsulamiento con ocultación de datos, desde la introducción al artículo. Leyendo el artículo portugués, :pt:Encapsulamento y, sobre todo, la definición de encapsulamiento que dan en el artículo :pt:Orientação a objetos, llego a la conclusión, salvo error de traducción, de que ellos tampoco consideran inconveniente la confusión entre encapsulamiento y ocultación. En italiano la confusión de ambos conceptos también es evidente, tanto en el texto como en el hecho de que su artículo :it:Information hiding sea una redirección a :it:Incapsulamento. Saliendo ya de las wikipedias, de la lectura del artículo sobre "encapsulation" de la School of Computer Science de la Carnegie Mellon vuelvo a deducir que encapsular es ocultar a los procesos que utilizan un objeto la información que no resulta necesaria para dicha utilización, conjurando así el peligro de que "el alma" del objeto sea modificada por todos los procesos usuarios... Vuelvo a nuestra wikipedia en español y leo el artículo Ocultación de información, intentando extraer de su lectura las diferencias entre eso y el encapsulamiento. Sin éxito. Curiosamente, este artículo sobre la ocultación de información está vinculado vía interwiki a los artículos en otros idiomas que tratan del... encapsulamiento (el artículo de encapsulamiento no tenía ninguna interwiki hasta hace quince minutos; acabo de ponerlas yo, y por eso me he dado cuenta de la confusión).
No puedo opinar, porque de esto tampoco entiendo (por eso soy lector de enciclopedias, jeje), pero creo que es urgente alertar a los que escriben sobre OOP en otros idiomas: ¡¡¡están todos confundidos!!! ;)  Este comentario es obra de Vivero, quien no olvidó ni omitió firmarlo  22:58 12 mar 2008 (UTC)
replies: text: Yo entiendo que el ocultamiento es una consecuencia de la encapsulación, según se desprende de la lectura de 'Turbo Pascal for Windows 3.0 Programming' (1991 Tom Swan - Bantham Books) o Análisis y Diseño Orientado a Objetos (1996 dy Booch - Addison Wesley Longman) JMorchio (discusión) 19:12 21 mar 2009 (UTC)
thread_title:  Decimos que no se debe confundir encapsulamiento y ocultación de información. ¿No estaremos solos en el Universo? 

message: Hola
¿Por que cuando uno busca programacion basada en componentes termina aca?
¿No seria mejor hablar de programacion orientada a componentes y darle su propio articulo? Estoy trabajando en el, por cierto, pero me gustaria que una vez este listo, programacion basada en componentes se vaya para alla tambien. ¿Como lo hago?
>> Pedro Otero << (discusión) 12:52 28 abr 2009 (UTC)
thread_title:  Programacion basada en componentes 

message: Por ejemplo, se confunde el paradigma con la implementación que hace la mayoría de los lenguajes: herencia y eventos no son características del paradigma. La mayoría de los lenguajes OO están basados en clases, pero otros no: Self y javascript, entre ellos.
Quien es, tal vez, el máximo referente en este campo, Alan Kay, dijo:
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things".
Es importante observar que no se hace mención a clases ni a herencia. Como dije antes la misma existencia de los lenguajes basados en prototipos descarta de plano que los conceptos de clase y herencia sean parte del paradigma.
La frase meciona: "(...), local retention and protection and hiding of state-process, (...)"
Es importante observar las comas antes y después del texto entrecomillado, porque ellas indican que Alan Kay menciona estos conceptos como un todo. Después nos perdemos discutiendo si encapsulamiento es o no lo mismo que ocultamiento de información. Mientras que es posible hacer disquisiciones conceptuales sobre los conceptos anteriores, lo importante es observar que en el paradigma de programación OO es una sola cosa:
* Local retention: el objeto retiene su comportamiento junto con la información necesaria.
* Protection and hiding of state-process: desde afuera no debe haber visibilidad respecto de cómo el objeto lleva a cabo su comportamiento.
Lo anterior sintetiza, con un lenguaje muy técnico por cierto, lo que es un objeto desde la perspectiva de un lenguaje orientado a objetos. Los objetos fueron la forma de conceptualizar esto, pero si un lenguaje lo conceptualizara de otro modo (sin usar el concepto de objeto) igual sería un lenguaje OO. En consecuencia, ni siquiera el concepto de objeto es esencial al paradigma.
Sin embargo, estos conceptos afectan al modo en que es posible razonar con un lenguaje. Los conceptos de objeto y herencia tienen implicaciones que van más allá de la mera implementación y que tienen que ver con cómo razonamos acerca del espacio del problema y de la solución.
Otra cosa importante a observar es que Alan Kay habla de late binding que es la técnica que posibilita el polimorfismo. Otra cuestión a considerar es que Kay también dijo que a él le gustaría que se empleara el término "genericidad" en lugar de "polimorfismo".
También sería importante mencionar las implicaciones que tiene que en el paradigma de objetos "todo es un objeto".
Ya que se trata de un artículo que versa sobre el paradigma de objetos, creo que estas cuestiones deberían ser abordadas.
--Fabián Flores Vadell (discusión) 20:42 11 mar 2012 (UTC)
thread_title:  Este artículo contiene algunos conceptos erróneos 

message: * http://www.scala-lang.org/page.jsp
Elvisor (discusión) 04:41 27 nov 2015 (UTC)
thread_title:  Enlaces rotos