¿Cuáles fueron los patrones de diseño de la era de la programación procesal? [cerrado]

Similar: ¿Cómo se realizó la programación hace 20 años?

OOP está bastante de moda hoy en día, tiene sus raíces en Simula 67 en la década de 1960, y más tarde se hizo popular por Smalltalk y C ++ . Tenemos muchos libros SECOS, SÓLIDOS sobre patrones de diseño en el mundo orientado a objetos.

Pero, ¿cuáles fueron los principios principales en la programación antes de la adopción amplia del paradigma OOP? ¿Y cuáles fueron los principales patrones de diseño?

Fui desarrollador de Cobol antes de aprender Java. Me he desarrollado por más de 35 años.

En los días de los lenguajes de procedimiento, la mayor parte del procesamiento se realizó por lotes. Retroceda lo suficiente en la historia, e incluso la compilación del programa se realizó con una baraja de tarjetas perforadas en lote.

Contrariamente a la afirmación de Kilian Foth , teníamos patrones de diseño en las décadas de 1970 y 1980. Había una cierta forma de codificar una combinación / combinación de varios archivos en Cobol. Había una cierta forma de codificar la adición de transacciones al archivo maestro (cinta) en Cobol. Había una cierta forma de codificar la generación de informes en Cobol. Es por eso que el Report Writer de IBM nunca ganó fuerza en muchas tiendas Cobol.

Hubo una aplicación temprana del principio DRY. Crea muchos párrafos para que no te repitas. Las técnicas de codificación estructurada se desarrollaron en la década de 1970 y Cobol agregó palabras estructuradas (verbos) al lenguaje en 1985.

En general, cuando escribimos un nuevo programa de Cobol, copiamos un viejo programa de Cobol y cambiamos los nombres para proteger a los inocentes. Casi nunca codificamos un programa Cobol a partir de una hoja de papel en blanco o una pantalla en blanco. Ese es un gran patrón de diseño cuando puedes copiar y pegar programas completos.

Había tantos patrones de diseño de Cobol que le llevó años a un programador de Cobol aprenderlos todos. Esa es una razón por la que los programadores de Cobol hoy en día, en su mayor parte, todavía usan la sintaxis de 1985.

Los "patrones de diseño" en el software no existían en la era de la que habla, porque el concepto no había sido inventado. Este no soy yo siendo impertinente; en realidad es la razón; ser llamado un nombre reconocible es lo que hace que un patrón de diseño sea un "patrón de diseño" en lugar de un código que se sigue utilizando de una forma u otra (por ejemplo, una "fábrica" ​​en lugar de "el tipo de clase estática que me gusta usar en lugar de una variedad de constructores ") y el concepto en sí no es una excepción.

Dicho esto, por supuesto, había cosas que cumplían exactamente el mismo papel en el trabajo de los profesionales que los patrones de diseño ahora. Pero se sentirá decepcionado al enterarse de ellos: el típico "truco de los gurús" en aquellos días eran cosas que nos resultaban bastante aburridas ahora, por ejemplo, listas enlazadas individualmente, bucles controlados por un índice incrementado en cada iteración, acceso inteligente " "métodos que parecen no hacer más que darle margen para cambiar de opinión sobre los detalles de implementación más adelante.

Así es, las cosas que ahora damos por sentado, que a veces incluso son parte de los lenguajes que usamos, solían ser conceptos avanzados (y a veces celosamente guardados) conocidos solo por los codificadores más experimentados. Lo más probable es que casi todo lo que no sea completamente trivial que aprendas en un curso de programación básico haya pasado por una fase en la que era el equivalente moral de un "patrón de diseño" para los practicantes de la época. La construcción de software puede que aún no sea una disciplina de ingeniería rigurosa, pero si estudia el estado del arte de los años 50 y 60, no puede negar que ha recorrido un camino enorme desde sus inicios.

El gran paradigma anterior fue la programación estructurada . En lugar de UML, había una variedad de diagramas diferentes (diagramas de flujo, diagramas de flujo de datos, diagramas de estructura, etc.). El desarrollo fue principalmente de arriba hacia abajo y siguió un proceso de descomposición funcional. Una de las ideas básicas era que la estructura de su programa debería parecerse a un diamante: el módulo principal en la parte superior, desplegado en módulos de control de alto nivel, que invocaban rutinas en los módulos de nivel inferior. Estos módulos de nivel inferior se basan en módulos de nivel inferior, todos los cuales (en teoría) finalmente convergieron en un puñado de rutinas básicas de E / S. Se suponía que los módulos de alto nivel contenían la lógica del programa, los de nivel inferior estaban más preocupados por la integridad de los datos y el manejo de errores.

Conceptos importantes introducidos durante este tiempo fueron la ocultación de información, la modularidad y la alta cohesión / bajo acoplamiento. Vea los trabajos de Dave Parnas para algunos documentos fundamentales sobre estos temas. Vea también el trabajo de Larry Constantine, Tom DeMarco y Ed Yourdon.

Supongo que uno grande (además de la programación estructurada en sí) fue el concepto de pasar un controlador: en OO tienes un objeto y contiene estado y funcionalidad. Antes de OO, tendría una carga de funciones independientes y pasaría un controlador a algún estado entre ellas, una cookie si lo desea. Esto le dio principios de OO sin tener realmente OO.

Puede ver esto mucho en el antiguo código Win32, pasaría un MANGO que sería un tipo opaco que representa algún estado asignado en el kernel de Windows. Puede hacerlo usted mismo pasando un puntero a una estructura que había asignado previamente como primer parámetro a las funciones que operaban con esos datos.

Como nadie ha mencionado el obvio todavía: un gran patrón de diseño en la era procesal fue Object. Al igual que muchos patrones de diseño populares antes (por ejemplo, Subrutina) y después (por ejemplo, Iterator), se hizo tan popular que incluso recibió soporte de idiomas.

Una "máquina de estados finitos" puede contar como un patrón, y los FSM se escribieron (por ejemplo, para protocolos de comunicaciones) utilizando lenguajes pre-OO.

También los "manejadores de interrupciones" y los TSR solían ser populares, por ejemplo, en DOS.

Términos como "Código de espagueti" y "Punto único de salida" son en realidad retrocesos a esa época. Hoy en día llamamos código que no nos gusta "código de espagueti", pero realmente es una referencia al código unido (mal) con GOTO y JMP.

(Hoy sufrimos el "código de ravioles", en el que el código es como un grupo de clases no relacionadas, muy empaquetadas, muy parecido a un plato de ravioles. Sin embargo, algunos expertos en OO preguntan justificadamente: "Pero no es eso lo que se supone que debe hacer OO ¿parece?")

El "Punto único de salida" de hoy es solo una frustrante refactorización. Muchos desarrolladores con los que hablo ni siquiera han oído hablar de eso, y me horrorizo ​​cuando lo explico. Pero en los viejos tiempos significaba no saltar de un bloque de código de repente y entrar en el código de espagueti. Avance hasta el final de la lógica, luego salga con gracia.

Estirando mi memoria muy, muy atrás, me parece recordar que la idea de agrupar el código en los procedimientos fue un gran salto adelante. La idea de que podría empaquetar los procedimientos en módulos interoperables y reutilizables era una especie de Santo Grial de la programación.

EDITAR: "Código de auto-modificación" también fue un patrón utilizado notablemente en el Doom original. Ahí es donde el programa realmente sobrescribiría sus instrucciones con instrucciones más rápidas basadas en su estado. Cuando era un tío que tomaba un curso de programación en el Museo de Ciencias, mi instructor nos advirtió severamente: "¡No escriba código auto modificable!"

EDITAR EDITAR: Sin embargo, antes de Internet, la palabra viajaba mucho más lentamente. La idea de implementar algoritmos y estructuras de datos solía ser mucho más importante. Hoy lo hago todo el tiempo sin siquiera saber qué tipo estoy usando. Pero en aquel entonces tenías que codificarlo tú mismo. Recuerdo un artículo que hablaba sobre los desafíos de programación que solían llevar días que hoy en día eliminamos en media hora, o menos. Por lo tanto, la programación "algorítmica" y "estructura de datos" realmente consciente probablemente estaría en la lista, mucho más que hoy.