Un día fui a un chat de Stack Overflow y vi una frase que decía que la herencia, el encapsulado y el polimorfismo son los pilares de la POO (en el sentido de que son fundamentales, una suela de construcción).
Además, hay una pregunta similar, que me han preguntado muy a menudo en los exámenes universitarios y las entrevistas de trabajo, y la respuesta correcta siempre fue la declaración pronunciada en el título de la pregunta ("Sí, la herencia, la encapsulación y el polimorfismo son los pilares de la OOP )
Pero en el chat de Stack Overflow me ridiculizaron severamente, los participantes no estuvieron de acuerdo con tal declaración. Entonces, ¿qué tiene de malo esta afirmación?
¿Los programadores parecen estar entrenados en diferentes cosas en las universidades post-soviéticas y de los Estados Unidos?
¿La herencia, la encapsulación y el polimorfismo no son considerados los pilares de la POO por los programadores de EE. UU.
fuente
Respuestas:
Muchos programadores los consideran pilares, y muchas universidades enseñan OO de esa manera.
Desafortunadamente, también es una vista miope.
OOP tiene muy pocos fundamentos, ya que en realidad es muy conceptual: "Enfoque el diseño de su programa pensando en las cosas como objetos: paquetes cohesivos de datos y funcionalidad".
Y aunque el diseño moderno del programa tiene una visión pobre de hacer las cosas de una manera "puramente OO", la mayoría de los programadores expertos estarán de acuerdo en que los principios SÓLIDOS (o algún subconjunto) son mejores candidatos para los "pilares de la Programación Orientada a Objetos" (aunque aplicar bien a no OOP). Estos no funcionan con estos términos en absoluto. En su lugar, utilizan los conceptos de entidades de software (de las cuales, los objetos son uno), interfaces (de las cuales, C # / Java / etc.
interfacees uno), abstracción y subtipado (de los cuales, la herencia es una forma).fuente
tl; dr: Puedes tener herencia sin OO, puedes tener encapsulación sin OO, puedes tener polimorfismo sin OO, incluso puedes tener los tres a la vez sin OO. Por otro lado, puede tener OO sin herencia. Además, hay diferentes tipos de encapsulación (orientada a ADT y OO), aunque no toda la encapsulación es OO.
Versión larga:
El término "Programación orientada a objetos" fue inventado por Alan Kay, por lo que puede decidir qué significa. Y lo define así :
En cuanto a la implementación, la mensajería es una llamada a procedimiento con retraso, y si las llamadas a procedimiento tienen retraso, entonces no puede saber en el momento del diseño qué llamará, por lo que no puede hacer suposiciones sobre la representación concreta del estado. Entonces, realmente se trata de mensajes, el enlace tardío es una implementación de mensajes y la encapsulación es una consecuencia de ello.
Más tarde aclaró que " La gran idea es 'enviar mensajes' ", y lamenta haberlo llamado "orientado a objetos" en lugar de "orientado a mensajes", porque el término "orientado a objetos" pone el foco en lo que no es importante (objetos ) y distrae de lo que es realmente importante (mensajes):
(Por supuesto, hoy en día, la mayoría de las personas ni siquiera se enfocan en objetos sino en clases, lo cual es aún más incorrecto).
La mensajería es fundamental para OO, tanto como metáfora como mecanismo.
Si le envía un mensaje a alguien, no sabe qué hace con él. Lo único que puedes observar es su respuesta. No sabe si procesaron el mensaje ellos mismos (es decir, si el objeto tiene un método), si enviaron el mensaje a otra persona (delegación / representación), incluso si lo entendieron. De eso se trata la encapsulación, de eso se trata OO. Ni siquiera puede distinguir un proxy del real, siempre que responda como espera que lo haga.
Un término más "moderno" para "mensajería" es "despacho de método dinámico" o "llamada de método virtual", pero eso pierde la metáfora y se enfoca en el mecanismo.
También se hacen puntos similares en On Understanding Data Abstraction, revisado por William R. Cook y también en su Propuesta de definiciones modernas y simplificadas de "objeto" y "orientado a objetos" .
¡En Smalltalk-72, ni siquiera había ningún objeto! Había sólo flujos de mensajes que quedó analizando, reescrito y redireccionados. Primero llegaron los métodos (formas estándar de analizar y redirigir las secuencias de mensajes), luego vinieron los objetos (agrupaciones de métodos que comparten algún estado privado). La herencia llegó mucho más tarde, y las clases solo se introdujeron como una forma de apoyar la herencia. Si el grupo de investigación de Kay ya hubiera conocido los prototipos, probablemente nunca habrían introducido clases en primer lugar.
Todo programador debe leer Sobre la comprensión de la abstracción de datos, Revisited . Explica en detalle cuál es exactamente la diferencia entre Objetos y Tipos de datos abstractos. Da ejemplos usando Java, y eso es extremadamente relevante para esta pregunta, porque tanto en los ejemplos ADT como en los ejemplos Object usa herencia, encapsulación y polimorfismo, ¡pero solo uno de los ejemplos está orientado a objetos! En otras palabras: puede tener herencia, encapsulación y polimorfismo, incluso puede tener los tres a la vez y aún no tener OO.
Por otro lado, puede tener OO sin herencia. Como indiqué anteriormente: las versiones originales de Smalltalk (el lenguaje diseñado por Alan Kay, el inventor del término "Programación Orientada a Objetos") no tenían herencia.
Por último, pero no menos importante, el Tratado de Orlando analiza la delegación como una alternativa a la herencia y cómo las diferentes formas de delegación y herencia conducen a diferentes puntos de diseño dentro del espacio de diseño de los lenguajes orientados a objetos. (Tenga en cuenta que incluso en los idiomas que admiten la herencia, como Java, a las personas se les enseña a evitarlo, lo que nuevamente indica que no es necesario para OO)
fuente