Seguro que algún momento de tu vida como desarrollador Go o si estás empezando y vienes de otro lenguaje, te habrás hecho esta fabulosa pregunta. Y es que cuando uno empieza en Go todo parece muy distinto a lo que estamos acostumbrados, pero también hay cosas que nos resultan muy familiares.
Si estás empezando con Go y me haces está pregunta, probablemente te diría que No, que no es un lenguaje orientado a objetos, ¿pero es esto realmente cierto?
Conociendo a Alan Kay
Cuando uno viene de lenguajes como C++, Java, PHP… creen entender que es la orientación a objetos (OO) como (encapsulación, composición, polimorfismo y herencia).
¿Pero qué pasa cuando aplicamos estos conceptos que hemos aprendido en otros lenguajes en Go?
En este punto toca hablar de Alan Kay uno de los padres de la orientación a objetos, entre otras grandes hazañas. Pero, ¿qué pasaría si le preguntamos a él sobre que opina sobre como se define hoy en día la OO
Inventé el término orientación a objetos, y puedo deciros que C++ no es lo que tenía en mente. Alan Key, OOPSLA 97
Seguro que más de uno llegados a esta parte del artículo estará un poco desconcertado o pensando que en Friends of Go nos hemos vuelto locos, así que mejor vamos a ver que definió Alan Key como Orientación a objetos
¿Qué es para Alan Kay la Orientación a Objetos?
Como hemos comentado anteriormente si le preguntamos a cualquier programador, sobre la orientación a objetos empezará a hablarlo de los términos previamente mencionados, pero realmente estos no son más que una evolución como efectos colaterales.
Alan Kay basó el término orientación a objetos en los siguientes conceptos:
- Mensajería. (Posible en Go gracias a los canales)
- Posibilidad de aislar, proteger o esconder el estado. (Podemos definir métodos o propiedades, como exportadas o no exportadas en Go)
- Asignación tardía de todas las cosas. (Esto es posible gracias a las funciones de orden superior, es decir funciones que reciben funciones o devuelven funciones, o bien mediante interfaces)
Como vemos Go cumple sobradamente las tres reglas de la orientación a objetos establecida por Alan Kay, así que podemos afirmar que Go puede ser un lenguaje orientado a objetos.
¿Cuál es la definición actual de Orientación a Objetos?
Si nos vamos a la Wikipedia, como hemos comentado realmente veremos una definición de este término algo diferente.
Existe un acuerdo acerca de qué características contempla la “orientación a objetos”. Las características siguientes son las más importantes:1
- Abstracción
- Encapsulamiento
- Polimorfismo
- Herencia
- Modularidad
- Principio de ocultación
- Recolección de basura
Como vemos realmente engloba las características enumeradas por Alan Key y añade nuevas, ¿entonces? ¿seguimos pudiendo utilizar Go como un lenguaje POO? Y la respuesta es sí, pero no de la manera en la que estamos acostumbrados y es por esto que si de entrada alguien me pregunta sobre esta cuestión, respondo con una negativa, porque tendemos a trasladar lo que ya sabemos, pero escribiéndolo en otro lenguaje, esto puede medio funcionar entre lenguajes similares, pero en Go no es el caso.
¿Y qué dicen sus creadores al respecto?
Las Go FAQ dicen lo siguiente:
Sí y no. A pesar de que Go tiene tipos y métodos y permite la programación orientada a objetos, no hay jerarquía de tipos. El concepto de “interfaz” en Go tiene una aproximación que creemos que es mucho más sencilla de usar y en algunos casos más general. También hay maneras de embeber tipos en otros tipos proporcionando algo similar – pero no idéntico – a la subclases. Además, los métodos en Go son más generals que en C++ o Java: se pueden definir para cualquier tipo de datos, incluso tipos integrados como enteros simples. No están restringidos a estructuras (clases).
Además, la falta de jerarquía de tipos hace que los “objetos” en Go parezcan mucho más ligeros que en lenguajes como C++ o Java.
Conclusión
Podemos decidir enfocar y utilizar Go como lenguaje OO pero tenemos que tener en cuenta que será al estilo Go y debemos aprender a convivir con ello, vamos a ver sus principales diferencias.
No hay clases, hola structs
Al principio los structs nos pueden parecer clases pero no caigamos en ese error, no tienen el mismo comportamiento y no son lo mismo. Podemos asignar a nuestros structs métodos, dándole el comportamiento de una clase tradicional, donde la estructura sólo contiene el estado y no el comportamiento, los métodos le proporcionaran el comportamiento al permitirle cambiar el estado.
Encapsulación
La encapsulación en Go funciona a nivel de paquetes y además se realiza de manera implícita dependiendo de la primera letra del método o atributo. Así que si declaramos un método o atributo con la primera letra en mayúscula, quiere decir que está exportado, es decir, es público fuera del paquete. Go no implemente protected ya que no hay herencia, aunque tiene algo que se le podría asemejar que son los internals (que ya veremos en algún otro artículo)
No hay herencia, sólo composición
Muchos llegan a Go no ven herencia y se empiezan a tirar por las ventanas, en mi opinión es hasta una ventaja, ya que nos olvidamos de las discusiones eternas, de si es mejor composición o herencia, que aporta una frente a la otra y bla bla.
Interfaces
Otro quebradero de cabeza para los recién llegados, las interfaces en Go son implícitas, es decir si tienes los métodos de los que se compone la interfaz, implementas la interfaz. Al principio a mí también me cogió por sorpresa, pero ahora, no entiendo porqué no es así en los demás lenguajes.
Podemos seguir hablando de más diferencias en el tema de programación orientada a objetos en Go pero para empezar con esto ya tenemos una buena idea.
Todo este artículo sirve de introducción a una serie de artículos que queremos poner en marcha de como realizar correctamente programación orientada a objetos en Go, donde veremos:
- Diferencia entre clases y structs, ¿cómo funcionan los structs?
- Composición vs Herencia, ¿cómo funciona la composición?
- Polimorfismo
Esperamos haber podido añadir un poco más de luz sobre este tema y dejar clara la respuesta a sí Go puede ser un buen lenguaje de orientación a objetos, si alguien os vuelve a preguntar sobre ello, traedlo con nosotros.
adrianpgl
aperezg