Claro que, antes de recalar en tan manido esquema hay que recordar –con Heidegger– que las buenas respuestas provienen de adecuadas preguntas, de forma que... ¿Qué demonios significa "estado-del-arte", traslación literal del state-of-the-art anglosajón? El diccionario Webster afirma que se trata de "el nivel de desarrollo (de un dispositivo, procedimiento, proceso, técnica o ciencia) alcanzado en un momento dado, usualmente debido a la aplicación de nuevos métodos". La traducción es, con todo, una barbaridad, así que resulta preferible un simple "Estado de la Tecnología de Objetos", sobre todo en el sentido de "resumen por partidas generales que resulta de las relaciones hechas al por menor" (DRAE), pues se tratarían de contabilizar así los logros parciales de la tecnología para asentar después su bondad genérica. Lo malo es que los mayores éxitos en el uso de la Tecnología de Objetos han pasado a ser ventajas estratégicas competitivas para las grandes empresas, mientras que los fracasos han devenido en ser a la vez poderosas vacunas e inaccesibles Secretos de Estado: así que difícilmente podremos contabilizar logros y tropiezos. Pero recordemos que la definición inglesa mentaba "nuevos métodos", por lo que quizás la cuestión debiera ser formulada de nuevo como "¿Cuál es el estado actual del software tras la adición de los nuevos métodos procurados, proclamados y literalmente impuestos por la Tecnología de Objetos? Y es que la Tecnología de Objetos no es nada en sí, sino un conjunto de métodos, técnicas, heurísticos, trucos y asunciones gratuitas que pretenden "mediar" en la consecución de una adecuada correspondencia entre el dominio de la realidad y el del software. Es, sin más, una nueva vuelta de tuerca en la disminución de la distancia intelectual que –como señalara Dijkstra– separa ambos dominios. Aunque habría que resaltar que la mera Tecnología de Objetos, entendida como "composición modular inteligente en sistemas software", junto con el práctico difuminado de los límites conceptuales de un "objeto", han conseguido que se batalle por la "objetividad" de un componente, o por la facilidad de composición de un "objeto" dado, de forma que –finalmente– de la mano del encapsulado, de la abstracción de tipos y de los objetos han llegado el Componentware, el BPR modular, más de un lenguaje universal de modelado, el pasmo Java, y la confusión metódica. Es decir, que si un objeto es "todo lo que tiene entidad"... ¡ya todo son objetos, en alguna medida! Pues, ¿cómo podrían sostener un programador o un analista que cualquier pieza de su trabajo carece de entidad? ¿No son objetos incluso ellos mismos? Claro que, si casi todo son objetos, ¿cómo apreciar la inserción de los nuevos métodos orientados-a-objetos en la ingeniería del software? Y, sobre todo, si tantos objetos se usan, ¿por qué todavía la tecnología de Objetos no es masivamente conocida y usada? Pues porque, como el burgués gentilhombre que hablaba prosa sin saberlo, la borrosa definición de los objetos y la carencia de marcos formales en el desarrollo de software han ocasionado una suerte de complacencia universal del tipo: "¿Cómo que no utilizo objetos? ¡Mira este applet Java!". Así que –finalmente– en la Tecnología de Objetos, más que por su estado habrá que preguntarse por su "estado de cosas" asociado, en el sentido de "conjunto de circunstancias que concurren en un asunto determinado" (DRAE). Así notaremos que la difusión de la Tecnología de Objetos ha devenido en extensa atomización, como la de los pulverizadores domésticos, y parece que se ha perdido intensidad en favor de una informal aquiescencia sobre la tecnología misma. A la vez los conceptos se vulgarizan ("poseo una configuración muy bien distribuida"), las técnicas se relajan ("yo suelo aplicar el encapsulado de entidades después, cuando he terminado de programarlas"), los métodos se alteran ("mi enorme experiencia[1] me ha llevado a crear una versión mejorada de OMT"), la abstracción formalista se dispara[2] y los programas siguen fallando (las máquinas siguen necesitando el botón de "reset"). Claro que, por desgracia, pese a los fallos, los mismos programas "funcionan", como sus retadores creadores afirman. La cuestión es, finalmente, que la informalidad, las asunciones implícitas, las afinidades emocionales y el barullo de acrónimos, impiden que se avance hacia una auténtica ingeniería del software y, lo que es peor, hacia la inserción razonable de tal software en el ámbito industrial. ¿Qué falta, entonces? Quizás un golpe de estado a la complacencia software, en la confianza de preñar mediante el pálpito emocional a la reglada enseñanza (que así quedaría, pizpireta ya, "en estado"). O quizás la creación de una auténtica comunidad tecnológica, en la que los distintos estados de sus participantes respecto de la Orientación-a-Objetos puedan conjugarse y unirse en una suerte de "estados [con-]federados" para lograr que, finalmente, los estados de ánimo y satisfacción se generalicen. Desde luego lo que falta es una sintonía maestro-discípulo que sitúe a cada parte en el ámbito práctico de la tecnología, de forma que cualquiera, ante la pregunta “¿Conoces la Tecnología de Objetos?” podría responder con un ufano "Sí, yo he estado".

[1] El tamaño de la experiencia tecnológica empieza a competir ya con el de los coches y las páginas web en el "acerbo de bar" masculino, así que ya se oyen frases como "poseo una experiencia de más de diez años en Java", o "yo es que, cuando trabajaba con tarjetas perforadas, ya trabajaba con objetos".

[2] Del academicismo huero cabría suscribir lo que Nietzsche afirmó del Estado: "El monstruo más frío entre todos los monstruos fríos".