¿Por qué, entonces, no se castiga corporalmente al programador que diseña módulos groseros, con los que no puede entablarse ningún tipo de comunicación que no sea el de abordaje y destrucción? ¿Por qué se relajan las costumbres en los ambientes informáticos hasta tal punto que cada cual mete su mano en los módulos de otros sin control ni concierto? ¿Por qué se prefiere la creación al reúso? ¡Por falta de educación, naturalmente! El mismo gesto del grosero comensal que limpia su plato con la servilleta es el que se repite, aprensivamente, cuando el programador le hace ascos a la codificación de sus colegas. Y es que uno no cesa de asombrarse de tantas carencias en el ambiente informático diario: de educación modular (modelos de componentes prudentes), de educación corporativa (normas de integración razonables, junto con estrategias y tácticas de uso), de educación personal (gestión controlada de recursos, ideas y código), de educación social (normas de trabajo en equipo, automatismos urbanísticos), de educación vial (reglas de circulación de módulos, control de versiones y gestión de bibliotecas), de educación ... ¡Uf! Y eso que de todo el mundo es sabido que las normas de urbanidad facilitan la comunicación entre personas/módulos, procurando una serie de interfaces normalizados que trocan sencilla la integración de nuevos elementos. "¡Ah, demonios!" -exclamará algún enterado lector- "¡Está hablando de CORBA!". Bien, bien. Pero en realidad estoy elucubrando sobre modelos genéricos de componentes sobre entornos heterogéneos. Incluso podría hablar de la aplicación de patrones de diseño en la codificación de identificadores en un lenguaje dado: revise sino el lector aquel importante, aunque discutible libro de Taligent titulado "Well-mannered Object-Oriented design in C++", o estudie los sistemas de identificación que permiten a los JavaBeans ser tratados como merecen por continentes distintos, lejanos y disconexos: El continente simplemente supone: "Ah, posee usted dos métodos "T getX" y "void setX(T aX)", por lo que infiero que voy a poder preguntarle por su propiedad X e, incluso, llegar a cambiarla", como podría suponer una clara disposición en el invitado antes de abordar una pregunta política comprometida. Educación, educación. Pero, ¿y el contexto? O sea, ¿no es la educación sino automática elegancia y consideración para con los demás? ¡Pues claro! Es absurdo pensar que podemos codificar componentes que, sin modificación, puedan desenvolverse con igual elegancia y eficacia en un casino que en la playa, en un sistema bursátil en tiempo real o en una contabilidad distribuida. La educación de nuestros componentes les procurará esa patina básica que habrá de permitirles que un determinado continente (el contexto) les someta al envoltorio (wrapper) de chaqueta y corbata o, en general, de cualquier filtro que permita una más eficaz comunicación con el resto de los módulos y con el entorno que habitan. Pero no es ésta una idea nueva: Bertrand Meyer, en su texto "Object Oriented Software Construction" y, sobre todo, en su reciente segunda edición[1] nos habla de módulos software que no se susurrarán al oído secretitos (interfaces explícitos), no se agolparán hablando todos a la vez (pocos interfaces) y, además, no intentarán contar su vida entera en cada ocasión (interfaces pequeños). Recuerden con todo, amigos lectores, que la educación en el software es consecuencia y corolario de la educación en las personas que lo crean, modifican y mantienen, y es por esto que acertadamente se enuncia "Las personas son más importantes que la tecnología".

Alicante, 01 de junio de 1997

[1] Categóricamente afirmo: será un animal de bellota quien obvie este imprescindible libro, en el que Eiffel está y, sorprendentemente, no está ni se menta. Meyer ha vuelto a conseguir, en la segunda edición de su justamente celebrada obra de 1.988, mejorar las previsiones más optimistas. ¿Creen en la ingeniería de software? Lean este libro, sin disculpas.