¿Como surgió OOP?

Vamos a frikear un poco y hablar del punto de vista de metodología de la ciencia como surgió OOP. Déspues de haber leído el siguiente artículo: "Existe una bala de plata" de Brad J. Cox. sobre la crisis del software, que podréis encontrar en el site de Cox.

Junto a los artículos titulados 'No Silver Bullet, Essence and Accidents of Software Engineering' y 'No silver buller revisited' se dibuja una buena perspectiva acerca de la crisis del software que vivimos en un pasado y qué seguimos viviendo de vez en cuando, todavía existen muchas funcionalidades y APIs que deberían ser cajas negras para nostros, pero sin embargo, siempre acabamos investigando un buen rato hasta verlas grises, ó blancas del todo, para su manejo.

En 1968, la Conferencia sobre Ingeniería de Software de la OTAN acuño la expresión "Crisis" para indicar que el software era escaso, caro, de insuficiente calidad, difícil de planificar y casi imposible de gestionar.

De otra parte, algunas publicaciones de Fred Brooks especialmente No Silver Bullet: Essence and Accidents of Software Engineering aducen que las dificultades son inevitables, ya que surgen de la esencia ineludible del software. ¿Como explica Brad j. cox esta crisis? ¿Qué son los criterios que nos permiten reconocer que efectivamente vivimos una crisis de software?

Muy bien, notamos que los componentes del dominio del software obedecen unas leyes específicas de un caso único, no existen directrices generales que pongan orden en el ámbito del software, no podemos evitar la confusión en clasificarlos ni en definir con precisión los conceptos usuales en este dominio.

La comunidad del software mantiene su encaprichamiento con los procesos que utilizamos para la construcción de objetos, persiguiendo la perfección, en vez de centrarse en hacer software tangible y dúctil ante la manipulación del sentido común facilitando a los consumidores de software que cada uno resuelva sus propios problemas especializados de software de la misma forma que se resuelven los problemas de fontanería: montando soluciones a partir de un robusto mercado de componentes reutilizables y fácilmente asequibles que, a su vez son suministrados por múltiples grados de producción de nivel inferior.

El desarrollo de un mercado robusto y muy detallado de componentes de software reutilizables en el cual podemos encontrar piezas estándar implica una arquitectura multinivel de software análoga a la arquitectura multinivel de hardware.

Al leer estos textos se refleja claramente una corriente de metodología científica que converge y corresponde con los paradigmas de Thomas S. Kuhn.

Fases del desarrollo científico de acuerdo con los paradigmas de khun:

Pues tenemos una etapa précientifica: Después de la revolución industrial, que había provocado suficientes avances, produciendo importantes logros en el transporte, las comunicaciones y la informática. La era de la información, el recurso crítico para convertir datos en bruto en información útil, estaba empezando.

Luego tenemos la fase de Constitución de paradigmas: El modelo centrado en los procesos

Otro componente de los paradigmas de Khun que se cumple; Ciencia Normal: Los programadores no se cuestionan el paradigma ni sus realizaciones. Esta fase se caracterizó con una gran productividad. Sin embargo, esto no quita la existencia de anomalías que han ido apareciendo al marco del paradigma.

Anomalías: Plazos incumplidos y presupuestos que se podían disparar en el desarrollo de algunas aplicaciones, llevando en algunas ocasiones a productos fallidos.

Crisis: El software era escaso, caro, de insuficiente calidad, difícil de planificar y casi imposible de gestionar.

Revolución científica: Una revolución industrial del software basada en piezas reutilizables e intercambiables.

Nuevo paradigma: Tecnologías orientadas a objetos


Este suceso de la crisis de software se puede explicar tambien de acuerdo a una metodología científica elaborada por Imre Lakatos, el falsacionismo refinado.

Falsacionismo refinado:

Una Teoría T es falseada por otra T’ si y solo si:
1) T’ tiene un exceso de contenido teórico respecto a T.
2) T’ explica todo el éxito previo de T.
3) Una parte del exceso de contenido de T’ resulta corroborado.


Lakatos plantea con el falsacionismo refinado una crítica al criterio irracional de sustitución de teorías y al concepto de revolución científica. Aplicando dicha metodología, el cambio de paradigma estructurado centrado en procesos por el paradigma orientado a objetos no resulta coherente. Pues, no se cumplen las condiciones para poder falsear el modelo antiguo y aducir el cambio de paradigma.

Otro hecho en la historia de informática que planteó un cambio de paradigma es por ejemplo: la aparición de los computadores personales y su encuentro con las redes. Esto ha introducido cambios radicales en la práctica informática, ya que el modelo al cual se aspiraba antes era que con unas pocas de aquellas enormes máquinas como el ENIAC se suplirían las necesidades computacionales de la época.

Aquello supuso cambios auténticos humanos y empresariales, tanto en la industria tecnológica (arquitecturas de ordenador, modelos de programación, arquitecturas de sistemas operativos…) como en la sociedad.

Seguiremos viviendo procesos de evolución entre entropías tendiendo a utopías.