Quiero saber por qué Python no está completamente orientado a objetos. Por ejemplo, no es compatible con modificadores de nivel de acceso privado, público y protegido.¿Por qué Python no está completamente orientado a objetos?
¿Cuáles son las ventajas y desventajas de esto? Con estas expresiones, Python es adecuado para qué aplicaciones (de escritorio, científicas, web u otras)?
Python no es compatible con la fuerte encapsulación, que es solo una de las muchas funciones asociadas con el término "orientado a objetos".
La respuesta es simplemente filosofía. A Guido no le gusta esconder cosas, y muchos en la comunidad de Python están de acuerdo con él.
+1, la respuesta correcta. Aunque diría: Python no * aplica (ocultación de información/encapsulación) *. obj._field es "privado" en ese código idiomático python no accederá a él a menos que sea necesario (función dir(), reflexión, serialización, tener que hackear la limitación del código heredado que no se puede cambiar). Y Python es más OO que p. Ej. Java o C++ o C#, ya que no hay primitivos. – delnan
@delnan: Tienes razón; Python no aplica la ocultación/encapsulación. Tampoco * admite * ocultar/encapsular más de lo que C lo hace. De hecho, sin ninguna reflexión, C admite ocultarse mejor que Python. :-) –
Solo FYI: las primitivas de C# se derivan de System.ValueType, que se deriva de System.Object. De hecho, C# es el único lenguaje verdaderamente OO que conozco, en el sentido de que todo es un objeto. – Xenoprimate
Creo que Python está diseñado para ser un híbrido. Puede escribir en estilos orientados a objetos o funcionales.
Las características distintivas de la orientación a objetos son la abstracción, el encapsulado, la herencia y el polimorfismo. ¿Cuáles de estos faltan en Python?
La orientación a objetos es un continuo. Podríamos decir que Smalltalk es el más puro de los puros, y todos los demás ocupan diferentes lugares en la escala.
Nadie puede decir cuál es el valor de ser 100% puro. Es posible escribir código muy bueno orientado a objetos en lenguajes que no son Smalltalk, Python incluido.
Python es útil en todas las áreas: científica (NumPy), web (Django) y de escritorio.
Creo que Python es un lenguaje más práctico y pragmático.
Se incluyen conceptos que ofrecen valor al desarrollador, sin demasiada consideración sobre conceptos teológicos como "diseño OO apropiado" y demás. Es un lenguaje para personas que tienen trabajo real que hacer.
Creo que Python es adecuado para todo tipo de entornos, aunque Desktop es un poco difícil debido a la falta de un único marco. Para todas las aplicaciones es útil usar un framework, como NumPy para cosas de computación, Twisted o Django para cosas web, y WxWidgets u otras cosas para escritorio.
En realidad, hay un gran software para GNOME escrito en Python, he escrito 11k lines one, el código es increíblemente legible y fácil de mantener, el desarrollo también es muy rápido y hay enlaces para casi todo. Pero tengo que admitir que GTK es realmente engorroso a veces. –
¡PyQT es el camino a seguir! PySlide by nokia es incluso mucho mejor. QT ahora también es apto para los negocios gracias a LGPL ¡Gracias a Nokia! –
Incluir campos en la interfaz de objetos es _todos_ pero pragmático, hace que la refactorización sea una pesadilla. – Borsunho
Guido dijo una vez que "todos consentimos adultos aquí". Aquí está la explicación más larga de hace mucho tiempo: http://mail.python.org/pipermail/tutor/2003-October/025932.html
Existe un acuerdo que subraya los elementos privados medios y no debe usarlos. A menos que sepas lo que estás haciendo y realmente quieres hacerlo.
El enlace también menciona otra manera de ponerlo en caso de Perl:
"un módulo de Perl preferirían que se quedó fuera de su sala de estar
porque no fueron invitados, no porque tiene una escopeta ".
+1 por la cita, me gusta eso. – Davy8
Me encantan las comillas. Creo que tener variables de instancia privadas es más que solo evitar que * los programadores ingresen a tu sala de estar *. En una serie de casos comunes (especialmente en métodos setter), desea que su objeto altere o formatee algunos datos antes de que el objeto lo almacene internamente, por el motivo que sea. En este caso, no puede esperar que otro programador sepa cómo se debe almacenar o acceder a esa variable. Toda esta lógica puede ser encapsulada dentro de los métodos getter y setter. Y dejar ivars expuestos es desordenado/confuso/engañoso. Ese es prácticamente mi único argumento para la privacidad. –
Los modificadores de acceso (público, privado, protegido, etc.) no son necesarios para class-based programming. Son solo una característica, como multiple inheritance.
¿A qué está orientado exactamente el objeto completo?Alan Kay dijo: "En realidad, inventé el término" orientado a objetos ", y puedo decir que no tenía C++ en mente". Es cierto que, probablemente, tampoco tenía Python en mente, pero vale la pena señalar que Smalltalk también protege las clases por convención, sin mandato.
Se dice que un lenguaje está orientado a objetivos completos si no tiene tipos de datos primitivos. Cada tipo de datos que necesitamos construir.
¿Es esta tarea? – extraneon
Python es adecuado para casi todo, que no se basa en el crujido de números difíciles, pero incluso así puede escribir estas partes en C. La encapsulación no es útil en un lenguaje de tipado dinámico. Solo ayuda al compilador, incluso en Java puede (y a veces lo necesita) eludirlo mediante la reflexión. La encapsulación, en mi humilde opinión, no agrega ningún tipo de seguridad, solo te da la sensación de que hay más seguridad en su lugar. –
@extraneon: No, solo para saber. @Wetzel: estoy de acuerdo con usted en 'La encapsulación no es tan útil en un lenguaje de tipeo dinámico'. –