Original: A Shared View of Sharing: The Treaty of Orlando. By Lynn Andrea Stein, Henry Lieberman, David Ungar.
Los autores del texto proponen la existencia de dos ejes o conceptos fundamentales comunes a todos los sistemas de objetos. A la vez, y en base a trabajos previos, describen diversos enfoques y mecanismos posibles para cada uno de estos ejes.
Nos llama la atención la preponderancia y la aceptación que tiene uno de estos enfoques, el de sharing por herencia, por sobre los demás en el público general no especializado y en la industria. Éste enfoque, implementado en lenguajes como Simula y Smalltalk, en boca de los autores resulta bastante complejo al lado de otras alternativas, como es el caso de la delegación.
Una característica de estos lenguajes que puede ser deseada es la robustez. Esta robustez o rigidez en algunas partes del lenguaje es lo que por lo general se ataca por parte de los defensores de Smalltalk a la programación estructurada o mismo a los lenguajes orientados a objetos tipados. Indudablemente, los lenguajes que revén los autores deben ser más flexibles que Smalltalk, enumerar las razones de este enunciado no es el objetivo de este análisis.
En la comparación entre los distintos enfoques uno podría buscar cuál de todos ellos representa mejor al paradigma de objetos. En este sentido pareciera que los lenguaje que implementan delegación como mecanismo de sharing resultan más puros que los que utilizan herencia de clase. Hemos visto que la metáfora de las clases es externa al paradigma de objetos, por lo tanto su uso, que de ninguna manera es infundado, estaría aumentando la complejidad del sistema. La delegación, en cambio, es un mecanismo transparente. No nos fuerza a crear estos objetos «especiales» que representan ideas abstractas o generalizaciones de otros objetos del sistema. Un aspecto que nos resulta sospechoso de este enfoque es la dispersión de la definición de comportamiento a lo largo del sistema en objetos que a priori no representan nada singular. Pero lo dejamos en el marco de sospecha por que no tengo conocimiento de cómo organizan este tipo de cosas los lenguajes concretos y qué ventajas o comodidades brindan los ambientes de desarrollo de los mismos.
Resulta tentador intentar medir la calidad de cada uno de estos enfoques, o mejor dicho, cual es mejor que otro. Puesto con estas palabras uno diría que tal misión es imposible. Primero habría que definir «mejor para hacer qué» dado que distintas tareas requieren distintas herramientas. Si consideramos el ámbito industrial, el mercado de los lenguajes de objetos esta dominado por lenguajes con herencia de clase, en general, tipados. A lo que nos surge la siguiente pregunta: ¿Hay lugar en el mercado para lenguajes como Self? Uno puede pensar que no, que la flexibilidad y el dinamismo que éste provee no son necesarios para los desarrollos de hoy. O que el know-how existente de los lenguajes «convencionales» está demasiado afianzado en la población de programadores actual y simplemente no vale la pena. Ninguna de estas especulaciones me resulta definitiva. Tal vez el uso de Self y afines esté reservado a ambientes académicos y laboratorios de investigación, cuyo objetivo sea indagar mas profundamente en el paradigma para clarificar sus secretos o buscar la belleza en el mismo. Tal vez su objetivo nunca fue ser un lenguaje «industrial strength» (por la historia de Self en particular sé que no es así) sino mas bien aportarle a estos, desde su posición de vanguardia, funcionalidades y mecanismos concretos para hacer las cosas de otra manera.
Estos pensamientos surgieron a raíz de la lectura del Tratado y, si bien no intentan reafirmar o refutar alguna de sus conclusiones, si quieren buscar un marco en donde situar este desarrollo. Particularmente, consideramos que oír distintas voces o enfoques dentro de la programación orientada a objetos es una experiencia enriquecedora. Tanto porque nos enseña que no hay una sola manera de hacer las cosas como que nos ayuda a manejar y comprender mejor los conceptos subyacentes de una teoría que solemos utilizar a diario.
W3 as it should be 