Discusión:Programación orientada a objetos

Esta página le interesa al Wikiproyecto Informática.

quería expresar mi desacuerdo cuando se cita que la POO es una metodología de desarrollo de software; metodologías de desarrollo de software son USDP, SSADM, Yourdon, Merise, Métrica, etc. La POO es sólo un paradigma, al igual que la programación estructurada, la programación funcional, la programación lógica, etc. Esta parte ya ha sido modificada en la visita hecha el 3 de enero del 2006.

Concepto de polimorfismo[editar]

El concepto de polimorfismo que se expone aquí es incorrecto (lo mismo he encontrado en ambos referencias a Polimorfismo y Polimorfismo en programación orientada a objetos. Se insiste en que el polimorfismo puede ser "estático" y se confunde con la sobrecarga (overloading) y con las plantillas o genéricos. Es necesario clarificar perfectamente estos términos de forma definitiva (y me gustaría escuchar las opiniones de otros profesionales). --JavierCantero 17:03 10 oct, 2004 (CEST)

Eso depende de cuánto quieras restringir el concepto de polimorfismo. A menudo las plantillas se consideran una forma de polimorfismo paramétrico: en:Polymorphism (computer science)#Parametric_polymorphism. ManuelGR 22:28 2 jun, 2005 (CEST)

Sí y para saber primero cuánto restringir el concepto de polimorfismo primero hay que definirlo. La definición actual de la Wikipedia es "En programación orientada a objetos se denomina polimorfismo a la capacidad del código de un programa para ser utilizado con diferentes tipos de datos u objetos." En mi opinión los templates de C++ cumplen esta definición (en mi opinión es polimorfismo sintáctico). El polimorfismo paramétrico es lo que existe en los lenguajes funcionales como Haskell y en los lenguajes imperativos con sintaxis funcional como Ocaml. En este último el compilador decide cuándo implementa una función polimórfica en forma dinámica (con polimorfismo clásico) o en forma estática (siempre que pueda lo hace así, como si tuviera templates) y todo en forma transparente para el programador, en este lenguaje ambos polimorfismos son una forma de implementar El polimorfismo (que siempre se escribe de la misma manera). Tute 13:45 8 abr 2006 (CEST)

LA VERDAD ES QUE TIENEN RAZÓN SE SUELE CONFUNDIR POLIMORFISMO CON SOBRECARGA ,PERO PARA ESO ESTA ESTE TIPO DE DISCUSIONES PARA ACLARAR ESOS ERRORES CONCEPTUALES POR LO QUE ME PARECE QUE UN CONCEPTO CONCRETO DEL POLIMORFISMO SERIA :

    "ES LA CAPACIDAD PARA QUE VARIAS CLASES QUE HEREDAN DE UNA SUPER CLASE UTILIZAN UN MISMO MÉTODO DE FORMA DISTINTA".

GUILLERMO PAREDES ALEGRIA - 19:45 23 OCT, 2010

En principio creo que la POO es un paradigma nacido en las ciencias de la computación, pero actualmente se extiende a las restantes ciencias para resolver problemas, tanto en sociología, economía como en medicina.

Usuario:Isvneven|Néstor A. Mellone]] 01:59 8 may, 2005 (ARG.)

---

las definiciones de clases, herencia,encapsulamiento y polimorfismo estan duplicadas.-

-

La definición de polimorfismo que mejor se adapta totalmente al tema es la siguiente:

Polimorfismo es la aptitud que tienen distintos objetos de actuar de una manera diferente frente a una misma llamada a función.

Esto refiere a que un apuntador a un objeto base "A" puede estar haciendo referencia a distintos objetos derivados de "A", gracias a eso una misma llamada a función (o método) responde de diferente forma, debido a que el método en cuestión es virtual y realmente se está haciendo una llamada al método de la clase derivada si bien el apuntador es del tipo de la clase base.

Cabe mencionar que el polimorfismo no existe sin herencia, no se puede aplicar si no es con clases que hereden de otras, es por esto que según esta definición las clases plantilla no deberían ser consideradas como polimorfismo ya que no es necesario heredar un objeto. Como su nombre lo dice son plantillas de código que se adaptan a un tipo de datos en tiempo de ejecución.

Gabriel S. Luraschi

Aqui en adelante expongo mis consideraciones al respecto, posiblemente equivocadas en algunos puntos... Por si interesa tenerlas en cuenta.

En mi humilde opión el polimorfismo no puede ser entendido sino en cualición con el concepto de ligadura (o liga) dinámica.

Desde mi punto de vista, el polimorfismo se refiere unica y exclusivamente a las entidades (variables y seudovariables), no a los objetos de por si, ya que estos tienen unicamente un tipo (si entendemos tipo como clase) despues de que son creados en tiempo de ejecución y hasta su desaparición, aunque este no se conozca en tiempo de compilación (otra cosa seria realizar una converisón o casting).

Gracias a la ligadura dinámica, en los lenguajes con polimorfismo puro y por tanto con entidades atipadas (caso de Smalltalk) una entidad variable puede apuntar a un objeto de cualquier tipo (lo que ocurra luego,es otra cuestión), mientras en otros con polimorfismo restringido (caso de Java) y que normalmente son lenguajes con declaración estática de tipos o lo que es lo mismo con entidades tipadas, esta entidades solo pueden apuntar a objetos cuyo tipo sea compatible con el declarado para la entidad, que normalmente son instancias de dicha clase o de sus descendientes.

Con la ligadura dinámica se consigue que se ejecute el metodo correcto para el objeto dado, aun cuando la entidad atraves de la cual referenciamos, no sea del mismo tipo que el objeto refenciado, sino de un tipo antecesor (la clase de la instancia es subclase de...).

Otra cuestión relacionada es el de la sobrecarga, que se refiere en mi opinion exclusivamente a los metodos, y esta relacionado con los espacios de nombres (interfaces de las clases, contextos o ambitos, etc), asi el nombre de un metodo se puede considerar sobrecargado, si este aparece en mas de un espacio de nombre o solo en uno y difieren el tipo y numero de sus argumentos y resultado.

Si el nombre esta cualificado ( cosa que pasa en los lenguajes O-O, debido a la currificación ), no existe colisión de nombres por lo que no se suele hablar de sobrecarga, cuando hablamos de espacios de nombres cualificados (x.p(z) =/= y.p(z), x.p(z) es equivalente a p(x,z), y.p(z) es equivalente a p(y,z), podria darse el caso ademas de que p(x,z) y p(y,z) devuelvan un w, p(x,z) y p(y,z) son funciones distintas por que los son alguno de sus argumentos o su resultado, pero ambas se llaman p, asi que p aparece sobrecargado, aunque no se considera asi).

En cambio si se habla de sobrecarga cuando el nombre aparece mas de una vez en el mismo espacio de nombres y varia el tipo o el numero de sus argumentos o resultado ( x.p(y) o x.p(y,z) o x.p(z) o x.p(y)=z y x.p(y)=w ), ya que en estos casos la cualificacion del nombre (x.) no nos sirve de discriminante para diferenciar la funcion y evitar la colision de nombres.

En los lenguajes con tipo estatico que permiten esta sobrecarga, el compilador se ocupa de de decorar posteriormente las funciones para evitar las colisiones de nombres (caso de C++).

En los lenguajes sin tipo estatico (o si se quiere de tipo dinamico) al existir polimorfismo puro, no suele necesitarse ( salvo quizas en el caso de que se tenga un numero de argumentos distingos como x.p(y) y x.p(y,z) ) y esto es asi debido a que ¡¡las entidades son polimorfas puras!!, y no suele necesitarse escribir metodos distintos basados en los tipos de los argumentos o del resultado (escribir un metodo x.p(y) y uno x.p(z) no tendria sentido ya que no se declara el tipo,asi que si solo se hubiera escrito un metodo x.p(y) y este se llamara con z, seria perfectamente legal la llamada a p, lo que ocurra luego, es otra cuestion).

De lo anterior cabe preguntarse, si el nombre (visto como entidad) de una función en un contexto de polimorfismo puro no es en si una entidad polimorfa por el hecho de poder aparecer casi totalmente sobrecargada (salvo quizas por el caso de de que tenga un numero de argumentos distintos).

Por ultimo nos surge la cuestion (esta era la otra cuestion) de los errores pueden ser considerados como tipos o como metodos, o han de ser considerados aparte, en los lenguajes dinamicos con polimorfismo puro suelen ser tratados de la primera forma (Smalltalk hasta lo que se lo hace como metodos), mientras que en los tienen una declaración estatica de tipos suelen ser considerados a parte (caso de Eiffel si no recurdo mal, en el caso de Java en cambio son tratados como clases).

De la exposición anterior, se puede sacar que sería conveniente, explicar en el articulo, que es la ligadura dinamica y su relacion con la herencia y la sobrecarga, la declaración estatica de tipos, y si se puede consiederar los errores en el paso de mensajes ( o llamadas a funciones o caracteristicas, etc ) como un tipo o como mensajes.Y destacar que existen lenguajes estaticos y lenguajes dinamicos. Tambien sería interesante dar cierta perspectiva al respecto de si tipo (tanto primitivo, como TAD) y clase se pueden considerar conceptos análogos.

Para acabar disculparme por adelantado las incorreciones y las posibles faltas ortograficas. Espero que se me entienda.

APG — El comentario anterior sin firmar es obra de 187.209.243.230 (disc. • contribs • bloq). 13:37 30 ago 2019 (UTC)[responder]

Encapsulamiento[editar]

En varios libros he visto el término "Encapsulamiento" en vez de "Encapsulación". Sugiero agregarlo como referencia en el artículo a menos que sea linguísticamente incorrecto ¿alguien sabe si es correcto?

Gracias.

Lo corregí a "encapsulamiento" porque la palabra "encapsulación" no existe.

Revise en el libro de Programación orientada a objetos de Luis Joyanes, y en la definición de Encapsulamiento se encuentra el siguiente parrafo: "El encapsulamiento o encapsulación es la propiedad que permite asegurar que el contenido de la información de un objeto esta oculta al mundo exterior:" (*) Como se puede observar también se puede utilizar el termino "encapsulación".

Sugiero que se revise el artículo completo ya que la definición del paradigma es incorrecta. En primer lugar el paradigma de programación orientada a objetos no menciona a las clases, estas son sólo una implementación del paradigma (lo mismo con la herencia, para mayores referencias consultar la especificación del lenguaje self). En el mismo artículo en inglés están bien definidas las características de la POO.

El polimorfismo también está mal definido.

--Edward Cetera 02:48 13 sep, 2005 (CEST)

Sugiero que lo hagas tú mismo. Como dice la vieja regla wikipédica, "Sé valiente editando páginas" ;) --Comae (discusión) 22:47 16 sep, 2005 (CEST)

Encapsulamiento y Ocultamiento[editar]

Creo que en la literatura de programación orientadaa objetos, se hace mal uso de las palabras encapsular y ocultar. Si se asume que el concepto de encapsular es agrupar información, no es conveniente confundirlo (o mezclarlo que es peor) con el concepto de ocultar la información.

Se hace encapsulamiento en la programación funcional cuando se definen estructuras de datos. La estrategia usada en laprogramación orientada a objetos para evitar que clases externas modifiquen los atributos de dichos objetos es a lo que se le debe llamar ocultamiento.

La Programación orientada a objetos como solución[editar]

Donde da la definición de Clases. Las clases no son un conjunto de objetos.

Cambio en definiciones de clase, herencia...[editar]

Hola, he añadido un par de cosas que me han parecido necesarias en lo referente a la definición de clase, herencia múltiple (y limitación particular de Java) y el concepto de instanciación.

Si es de utilidad, será bueno. Sírvanse de cambiar, añadir o eliminar lo que corresponda.

Un saludo. 138.100.29.210 (es mi ip :))

Diferencias con la programacion procedural[editar]

Hola, estoy descontento con la primera parte del parrafo que no esta bien redactado y solo lo limita a la programacion estructurada. Voya a chequear el libro de Luis Joyanes para tomarlo como referencia y modificar esta parte.

Hice la siguiente modificación en el comienzo del primer parrafo:

La programación procedural conduce a las mejoras de la técnica, tales como la programación estructurada y "refinamientos sucesivos" (1),

y coloque la siguiente bibliografía:

(1) JOYANES, Luis. Programación Orientada a Objetos, segunda edición, MC-GRAW HILL/INTERAMERICANA DE ESPAÑA, Madrid 1998, p. 37.

Reordenación[editar]

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)

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)

Bibliografía[editar]

(*) JOYANES, Luis. Programación Orientada a Objetos, segunda edición, MC-GRAW HILL/INTERAMERICANA DE ESPAÑA, Madrid 1998, p. 20.

(*) http://cursos.aiu.edu/Lenguages%20de%20Programacion/PDF/Tema%202c.pdf

Propuesta de cambios[editar]

Proponemos se cambie lo siguiente, de la introducción al artículo:

Ahora mismo, se tiene lo siguiente: La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto difiere de los lenguajes procedurales tradicionales, en los que los datos y los procedimientos están separados y sin relación. Estos métodos están pensados para hacer los programas y módulos más fáciles de escribir, mantener y reutilizar.

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 estructuras de datos, y en segundo lugar en las operaciones ("métodos") específicas a esas estructuras de datos. Los lenguajes procedurales animan al programador a pensar sobre todo en términos de procedimientos, y en segundo lugar en las estructuras de datos que esos procedimientos manejan.

Los programadores que emplean lenguajes procedurales, escriben funciones y después les pasan datos. Los programadores que emplean lenguajes orientados a objetos definen objetos con datos (estructuras) y métodos y después envían mensajes a los objetos diciendo qué realicen esos métodos en sí mismos.

A ver que les parece cambiarlo por esto:

La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. De esta forma, los objetos contienen toda la información, los denominados atributos, que permite definirlos e identificarlos frente a otros objetos pertenecientes a otras clases (e incluso entre objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos) y a su vez, disponen de mecanismos de interacción, los llamados métodos, que favorecen la comunicación entre objetos (de una misma clase o de distintas) y en consecuencia, el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separa (ni debe separarse) entre información (datos) y procesamiento (métodos).

Es por esta propiedad de conjunto entre datos y métodos, por las que el programador debe pensar indistintamente en ambos términos, ya que no debe dejar de lado nunca a los atributos en favor de los métodos, ni viceversa. Es cierto que una clase de objetos al contar con una serie de atributos definitorios, requiera de unos métodos para poder tratarlos, pero no hay que considerarlos a estos en un segundo plano ya que ambos conceptos están íntimamente entrelazados. Separar o dar mayor importancia a unos frente a los otros puede llevar al programador a seguir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen esa información por otro (llegando a una programación estructurada camuflada en un lenguaje de programación orientado a objetos).

Esto difiere de los lenguajes procedurales tradicionales, en los que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida Estos métodos están pensados para hacer los programas y módulos más fáciles de escribir, mantener y reutilizar. ...

resto igual

¿qué opinan? —Jstitch (discusión) 20:06 6 mar 2006 (CET) y Lasneyx'nid (Entrada Casa Iliah [de,o])

ok, a falta de objeciones, me dispongo a realizar estos cambios, para el día de mañana si no hay ninguna objeción mas, lo haré. saludos. —Jstitch (discusión) 20:40 13 mar 2006 (CET)

Vaya, no lo ví antes. He rescatado un poco de la descripción antigua de programación estructurada, y he reducido el número de líneas relativas a la unidad datos-atributos, resultaba en mi opinión muy recargado. Digamos que lo he refactorizado :) miguelsan 21-6-06

No entiendo por qué hay que denostar como distinta la programación imperativa. Además no hay que llamar procedural o procedimental a la programación imperativa (que así se la llama acá en la Wikipedia). Tute 14:06 6 abr 2006 (CEST)

La programación imperativa no se opone a la POO[editar]

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)

-- También existe programación orientada a objetos lógica o funcional. -- Inconexo

Argumentos que explican porque la POO se opone a la programacion Imperativa[editar]

la Programación imperativa y la programación orientada a objetos son Paradigmas Opuestos esto parte del concepto de paradigma como el conjunto de teorías generales, suposiciones, leyes o técnicas de que se vale una escuela de análisis o comunidad científica para evaluar todas las cosas. Thomas Kuhn, historiador de ciencia, habla del "paradigma dominante" como el “conjunto de creencias compartidas o de sabiduría convencional acerca de las cosas”, cuando ambos paradigmas coexisten se habla de programacion hibrida por ejemplo C++,Visual Basic Clasico, etc...con la Internet y el desarrollo de paginas web y programas del lado servidor, todas las grandes corporaciones de software propietario y la organizacion de software libre se han decantado por la OOP en sus entornos de desarrollo Microsoft con .NET y Sun Microsystem con su J2EE y FSL con PHP 5 Appserv,los problemas complejos de la realidad y de clientes y usuarios los ha obligado a tomar este camino ¿acaso no se enterraron para siempre a los programadores de GOTO?-[dijkstra,1968] no se trata de decir que la programacion Imperativa esta enterrada del todo pero el paradigma Imperativo sufrió un Infarto Fulminante cuando enterramos el llamado a función o sub o tambien CALL que la sustentaba[nigaard,1970], aún asi la tecnica de programación extructurada sigue siendo fundamental como aun es fundamental usar secuencias de instrucciones que vienen desde los comienzos de la programación con assembler[kernighan,1975]. El modelo metal anómalo que llevaría al llamado a funciones o CALL,y el uso de variables globales y locales(super desastroso en proyectos a largo plazo)todo se corrige efectivamente con la OOP pero también tiene un precio y es que el diseño previo debe ser muy cuidadoso, aun asi la OOP no resuelve todos los enigmas de la realidad ya que existen otros paradigmas como el funcional, esotérico[sistemas operativos modernos,Tanembaum,1998], etc...que se adaptan mejor a los diferentes enigmas de la realidad caótica,la OOP cambio "la extructura de la lógica de programacion"[gosling,1984][eich,1990]¡OJO! UML no funciona con C,Fortran,Cobol,etc ni la diagramacion clasica extructurada funciona con Java,Delphi,C# me baso en articulos y trabajos como los de Dijkstra,Strouptoup,Kernigham,Wirth,Ritchie,Neegark,Lerdorf, wirth,kleene,etc que hablan bastante al respecto¡OJO!, finalmente concluyo en que son los problemas de la realidad los que se pueden adaptar al paradigma que mejor lo resuelva pero decir que la OOP y la Programacion Imperativa son subconjuntos o se complementan es falso ya que la realidad ha demostrado que los híbridos estan entrando en desuso[kernighan] y el surgimiento feroz de la OOP vaticinada ya en los 80's nos invita de alguna forma al triste y dolido velorio del Paradigma Imperativo[gosling]. Sobre la opinion de Javier Cantero pienso que hay polimorfismo en lenguajes Hibridos donde existe este concepto especifico llamado la Sobrecarga(C++)[strouptup,1985] y se diferencia del polimorfismo en Lenguajes OOP puros, en el primero caso hay extructuras logicas mezcladas por que se mezclan dos paradigmas(Híbridos), en el segundo caso el polimorfismo es mas simple de definir en lenguajes OOP puros(Java, Simula,Smalltalk,C#). Pienso que el articulo esta bien escrito y la fuente es muy reconocida y de gran reputacion en la area de informatica como es el Prof.Joyanes Aguilar, ha publicado muchos buenos libros de Informatica esto es libro didacticos y no esotericos como el manual IBM/360 , seria temerario sentarnos acá a hacer definiciones propias ya que para eso existen las tesis y trabajos de ascensos donde nosotros de manera cientifica podemos hacer nuevas evaluaciones o criterios sobre temas especificos[Sabino,1975] pero creo que este no es el sitio adecuado corrijamos citando fuentes reconocidas de autores y teorias,sin animos de agraviar a nadie[gorillaz,2006]. gorillazmigeekcode: GED/CS/MU d-- s:++ a>$>? C+++ L--? P! E---- W++ N* o K- W++++ O M- V+(++$) PS+++ PE- Y+ PGP- t++ 5+ X-- R+ tv+(+++) b++++ DI? D++++$(--) G++++(@) e++ h++>$ r-@ y++*** busca el interprete de GEEKCODE en http://ebb.org/ungeek/ --gorillaz

xDDDD qué matete que tenés en la cabeza; se nota que sos universitario xD. Me encantaron los detalles como el "infarto fulminante", "paradigma esotérico", "híbridos y puros", y... el mejor... "Joyanes Aguilar ha publicado buenos libros". Jajajajajajaaaaaa xDDDDDDDDDDDDDD. --angus (msjs) 17:45 25 abr 2006 (CEST) SCNR.

Dijkstra,Strouptoup,Kernigham,Wirth,Ritchie,Neegark,Lerdorf, Zuraski,Gutsman,thompson,gosling,kleene,turing,boole,shannon,church,van rossum,wall,guthrie,kemini,kurtz,Eich,berners-lee,cerf,widenius,codd,atanasoff,wiener,von newman,backus,etc ellos supongo tambien deberian causarte mucha mas risa --perdon tal vez ud. es un notable programador del mounstruo aquel llamado IBM/360,entonces se frustra un poco si alguien se opone al Imperativo en el que se basan los kernel...yo llamaria a esa programacion de kernel paradigma esoterico donde los locos y genios estan agrupados sin distincion...xDDDDDDgorillaz

- Creo que aqui el problema no es de conceptos, sino de traduccion. Anteriormente se hablaba de "imperative" vs. "object oriented". Pero hoy en dia los articulos hablan de "imperative" vs "declarative" (ver: http://en.wikipedia.org/wiki/Imperative_programming por ejemplo). Creo que en vez de hablar de un paradigma imperativo se deberia contrastarlo con el procedual (a veces procedural) donde se orienta la programacion a procedimientos (hoy se usa mas "procedural programming" para representar lo que haciamos en Pascal que "imperative programming"). El problema de llamarlo programacion imperativa es que no es claro a cual concepto se refiere.(am)

Fox Pro ¿Existe Todavia? ¿Alguien lo Usa?[editar]

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)

Si aún se usa, y mucho, creo que se encuentra entre los 7 lenguajes mas utilizados en el mundo. Y no es de extrañar, conoci y use mucho tiempo y puedo asegurarte que es muy poderosa POO puros... claro podrias pogramar de forma lineal o desordenada pero Porque no usar todo el poderío si vas a practidar con VFP? Viva el Zorro.

Ada sí es OOP (tanto como C++, Java o Eiffel)[editar]

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)

Decimos que no se debe confundir encapsulamiento y ocultación de información. ¿No estaremos solos en el Universo?[editar]

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)[responder]

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)[responder]

Programacion basada en componentes[editar]

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)[responder]

Si hablas de tecnicas de programacion en arquitectura de tres capas, como por ejemplo el modelo vista controlador pudiera verse la programacion orientada a objetos como un grupo de componenetes reutilizables para varios proyectos de naturaleza similar. En resumen no existe programacion orientada a componentes sino programacion BASADA en componentes.>> Gorillaz <<

Smalltalk[editar]

Cambié el Smalltalk = "Proyecto de Investigación" ya que actualmente existen cientos de Empresas e Instituciones en el mundo usando Smalltalk, ver http://www.goodstart.com/who-uses-smalltalk.ssp. También saqué el "Influenció a Java" ya que influenció a casi todos los lenguajes de objetos tradicionales. Por otro lado, Smalltalk es considerado un entorno de objetos y no simplemente un lenguaje.

Visual Basic[editar]

Como tal, hasta su versión .NET ... NO ES ORIENTADO A OBJETOS, sino que emplea "objetos". Los programas que se crean en él son con módulos y funciones, pero no objetos. Creo que se debería de quitar de la lista -- Manuel Rubio.

Este artículo contiene algunos conceptos erróneos[editar]

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)[responder]

Enlaces rotos[editar]

http://www.scala-lang.org/page.jsp

Elvisor (discusión) 04:41 27 nov 2015 (UTC)[responder]