tutorial software programacion lenguaje introduccion language-agnostic oop programming-languages glossary

language agnostic - software - ¿Qué hace que un lenguaje esté orientado a objetos?



scala tutorial (14)

Dado que el debate sin términos significativos no tiene sentido , pensé que señalaría al elefante en la sala y me preguntaría: ¿Qué hace exactamente que un lenguaje sea "orientado a objetos"? No estoy buscando una respuesta de libro de texto aquí, sino una basada en sus experiencias con los lenguajes OO que funcionan bien en su dominio, cualquiera que sea.

Una pregunta relacionada que podría ayudar a responder primero es: ¿Cuál es el arquetipo de los lenguajes orientados a objetos y por qué?


Admite clases, métodos, atributos, encapsulación, ocultación de datos, herencia, polimorfismo, abstracción ...?


Según Booch, los siguientes elementos: Mayor:

  • Abstracción
  • Encapsulación
  • Modularidad
  • Jerarquía (Herencia)

Menor:

  • Mecanografía
  • Concurrencia
  • Persistencia

Hasta donde puedo decir, la visión principal de lo que hace que un lenguaje esté "orientado a objetos" es apoyar la idea de agrupar datos y métodos que funcionan con esos datos, lo que generalmente se logra a través de clases, módulos, herencia, polimorfismo, etc.

Consulte esta discusión para obtener una visión general de lo que piensa la gente (¿qué piensa?). Orientación de objetos significa.

En cuanto al lenguaje OO "arquetípico", eso es de hecho Smalltalk, como señaló Kristopher.


No son realmente los idiomas que son OO, es el código.

Es posible escribir código C orientado a objetos (con estructuras e incluso con miembros de punteros de funciones, si lo desea) y he visto algunos buenos ejemplos de ello. (Me viene a la mente Quake 2/3 SDK). También es definitivamente posible escribir código de procedimiento (es decir, no OO) en C ++.

Dado eso, diría que es el soporte del lenguaje para escribir un buen código OO que lo convierte en un "Lenguaje orientado a objetos". Nunca me molestaría con el uso de miembros del puntero de función en estructuras en C, por ejemplo, para lo que serían funciones de miembro ordinarias; por lo tanto, diré que C no es un lenguaje OO.

(Ampliando esto, uno podría decir que Python tampoco está orientado a objetos, con la referencia "propia" obligatoria en cada paso y constructores llamados init , whatnot; pero eso es una Discusión Religiosa).


Para avanzar en lo que aib dijo, diría que un lenguaje no está realmente orientado a objetos a menos que las bibliotecas estándar que están disponibles estén orientadas a objetos. El mayor ejemplo de esto es PHP. A pesar de que admite todos los conceptos orientados a objetos estándar, el hecho de que un porcentaje tan grande de las bibliotecas estándar no estén orientados a objetos significa que es casi imposible escribir el código de una manera orientada a objetos.

No importa que estén introduciendo espacios de nombres si todas las bibliotecas estándar aún requieren que prefija todas sus llamadas a función con cosas como mysql_ y pgsql_, cuando en un lenguaje que admite espacios de nombres en la API real, podría deshacerse de las funciones con mysql_ y solo tiene un simple "include system.db.mysql. *" en la parte superior de su archivo para que sepa de dónde provienen esas cosas.


Sin tener en cuenta las implicaciones teóricas, parece ser

"Cualquier lenguaje que tenga una palabra clave llamada ''clase''" :-P


Definiciones para Orientación a Objetos son, por supuesto, una gran lata de gusanos , pero aquí están mis 2 centavos:

Para mí, Object-Orientation tiene que ver con objetos que colaboran mediante el envío de mensajes. Es decir, para mí, el rasgo más importante de un lenguaje orientado a objetos.

Si tuviera que poner una lista ordenada de todas las características que debe tener un lenguaje orientado a objetos, se vería así:

  1. Objetos que envían mensajes a otros objetos
  2. Todo es un objeto
  3. Enlace tardío
  4. Polimorfismo de subtipo
  5. Herencia o algo similarmente expresivo, como Delegación
  6. Encapsulación
  7. Ocultación de información
  8. Abstracción

Obviamente, esta lista es muy controvertida, ya que excluye una gran variedad de lenguajes ampliamente considerados como orientados a objetos, como Java , C # y C ++ , todos los cuales infringen los puntos 1, 2 y 3. Sin embargo, no hay duda que esos lenguajes permiten la programación orientada a objetos (pero también lo hace C ) e incluso la facilitan (lo que C no hace). Por lo tanto, he llegado a llamar a los idiomas que satisfacen esos requisitos "puramente orientados a objetos".

Como lenguajes arquetípicos orientados a objetos, los llamaría Self and Newspeak .

Ambos satisfacen los requisitos mencionados anteriormente. Ambos están inspirados y son sucesores de Smalltalk , y ambos realmente logran ser "más OO" en algún sentido. Las cosas que me gustan de Self y Newspeak son que ambas llevan el paradigma de envío de mensajes al extremo (Newspeak incluso más que Self).

En Newspeak, todo es un mensaje enviado. No hay variables de instancia, ni campos, ni atributos, ni constantes, ni nombres de clase. Todos son emulados usando getters y setters.

En Sí Mismo, no hay clases , solo objetos. Esto enfatiza lo que OO realmente se trata: objetos, no clases.


Básicamente orientado a objetos realmente se reduce a "mensaje de paso"

En un lenguaje de procedimiento, llamo a una función como esta:

f(x)

Y el nombre f probablemente esté vinculado a un bloque particular de código en tiempo de compilación. (A menos que este sea un lenguaje de procedimiento con funciones de orden superior o indicadores de funciones, pero dejemos pasar por alto esa posibilidad por un segundo.) De modo que esta línea de código solo puede significar una cosa inequívoca.

En un lenguaje orientado a objetos, paso un mensaje a un objeto, quizás así:

o.m(x)

En este caso. m no es el nombre de un bloque de código, sino un "selector de método" y el bloque de código que se llama en realidad depende del objeto o de alguna manera. Esta línea de código es más ambigua o general porque puede significar cosas diferentes en diferentes situaciones, dependiendo de o.

En la mayoría de los lenguajes OO, el objeto o tiene una "clase", y la clase determina a qué bloque de código se llama. En un par de OO idiomas (el más famoso, Javascript) o no tiene una clase, pero tiene métodos directamente asociados a ella en tiempo de ejecución, o los ha heredado de un prototipo.

Mi demarcación es que ni las clases ni la herencia son necesarias para que un idioma sea OO. Pero este manejo polimórfico de mensajes es esencial.

Aunque puede simular esto con punteros de función en, por ejemplo, C, eso no es suficiente para que a C se le llame un lenguaje OO, porque tendrá que implementar su propia infraestructura. Puede hacerlo, y es posible un estilo OO, pero el idioma no se lo ha proporcionado.


Smalltalk generalmente se considera el lenguaje OO arquetípico, aunque Simula a menudo se cita como el primer idioma OO.

Los lenguajes de OO actuales se pueden categorizar libremente por el idioma del que toman más conceptos:

  • Smalltalk-like: Ruby, Objective-C
  • Simula-like: C ++, Object Pascal, Java, C #

cuando puedes hacer clases, está orientado a objetos
por ejemplo: java está orientado a objetos, JavaScript no, y c ++ parece un tipo de lenguaje "curioso con objetos"


En mi experiencia, los lenguajes no están orientados a objetos, el código es.

Hace unos años, estaba escribiendo un conjunto de programas en AppleScript, que en realidad no aplica ninguna característica orientada a objetos, cuando comencé a asimilar OO. Es difícil escribir Objetos en AppleScript, aunque es posible crear clases, constructores, etc. si se toma el tiempo para descubrir cómo hacerlo.

El idioma era el idioma correcto para el dominio: conseguir diferentes programas en el Macintosh para trabajar juntos para realizar algunas tareas automáticas basadas en archivos de entrada. Tomar la molestia de autoejecutar un estilo orientado a objetos fue la elección de programación correcta porque dio como resultado un código que era más fácil de solucionar problemas, probar y comprender.

La característica que más noté al cambiar ese código de procedural a OO fue la encapsulación: ambas propiedades y llamadas a métodos.


Arquetipo

La capacidad de expresar escenarios del mundo real en código.

foreach(House house in location.Houses) { foreach(Deliverable mail in new Mailbag(new Deliverable[] { GetLetters(), GetPackages(), GetAdvertisingJunk() }) { if(mail.AddressedTo(house)) { house.Deliver(mail); } } }

-

foreach(Deliverable myMail in GetMail()) { IReadable readable = myMail as IReadable; if ( readable != null ) { Console.WriteLine(readable.Text); } }

¿Por qué?

Para ayudarnos a entender esto más fácilmente. Tiene más sentido en nuestras cabezas y si se implementa correctamente hace que el código sea más eficiente, reutilizable y reduce la repetición.

Para lograr esto necesitas:

  • Punteros / referencias para asegurar que esto == esto y esto! = Eso.
  • Clases para apuntar (por ej., Arm) que almacenan datos (int hairyness) y operaciones (Throw (IThrowable))
  • Polimorfismo (Herencia y / o Interfaces) para tratar objetos específicos de forma genérica para que pueda leer libros y graffitis en la pared (ambos implementan IReadable)
  • Encapsulación porque una manzana no expone una propiedad Atoms []

Simples: (comparar el carácter del seguro)

1-Polimorfismo 2-Herencia 3-Encapsulación 4-Reutilización. :)


Objeto: un objeto es un repositorio de datos. Por ejemplo, si MyList es un objeto ShoppingList, MyList podría registrar su lista de compras.

Clase: una clase es un tipo de objeto. Muchos objetos de la misma clase pueden existir; por ejemplo, MyList y YourList pueden ser objetos de ShoppingList.

Método: Un procedimiento o función que opera en un objeto o una clase. Un método está asociado con una clase particular. Por ejemplo, addItem podría ser un método que agrega un elemento a cualquier objeto ShoppingList. A veces, un método se asocia con una familia de clases. Por ejemplo, addItem podría operar en cualquier lista, de las cuales una lista de compra es solo un tipo.

Herencia: una clase puede heredar propiedades de una clase más general. Por ejemplo, la clase ShoppingList hereda de la clase List la propiedad de almacenar una secuencia de elementos.

Polimorfismo: la capacidad de tener un método llamado funciona en varias clases diferentes de objetos, incluso si esas clases necesitan implementaciones diferentes de la llamada al método. Por ejemplo, una línea de código podría llamar al método "addItem" en cada tipo de lista, aunque agregar un elemento a una lista de compra es completamente diferente de agregar un artículo a una ShoppingCart.

Orientada a objetos: cada objeto conoce su propia clase y qué métodos manipulan objetos en esa clase. Cada ShoppingList y cada ShoppingCart saben qué implementación de addItem aplica a ella.

En esta lista, la única cosa que realmente distingue a los lenguajes orientados a objetos de los lenguajes de procedimiento (C, Fortran, Basic, Pascal) es el polimorfismo.

Fuente: https://www.youtube.com/watch?v=mFPmKGIrQs4&list=PL-XXv-cvA_iAlnI-BQr9hjqADPBtujFJd