Quali erano i modelli di progettazione dell'era della programmazione procedurale? [chiuso]

Ero uno sviluppatore Cobol prima di imparare Java. Ho sviluppato per oltre 35 anni.

Ai tempi dei linguaggi procedurali, la maggior parte dell'elaborazione è stata eseguita in batch. Torna indietro abbastanza nella storia e persino la compilazione del programma è stata eseguita con un mazzo di schede perforate in batch.

Contrariamente all'approvazione di Kilian Foth, abbiamo avuto modelli di design negli anni '70 e '80. C'era un certo modo per codificare una corrispondenza multipla / unione in Cobol. C'era un certo modo per codificare l'aggiunta di transazioni al file master (nastro) in Cobol. C'era un modo per codificare la generazione di report in Cobol. Questo è il motivo per cui il Report Writer di IBM non ha mai realmente preso piede in molti negozi Cobol.

C'è stata una prima applicazione del principio DRY. Crea molti paragrafi in modo da non ripeterti. Le tecniche di codifica strutturata sono state sviluppate negli anni '70 e Cobol ha aggiunto parole strutturate (verbi) alla lingua nel 1985.

In generale, quando abbiamo scritto un nuovo programma Cobol, abbiamo copiato un vecchio programma Cobol e modificato i nomi per proteggere gli innocenti. Non abbiamo quasi mai codificato un programma Cobol da un foglio di carta bianco o uno schermo vuoto. È un grande modello di design quando puoi copiare e incollare interi programmi.

C'erano così tanti modelli di design Cobol che ci sono voluti anni perché un programmatore Cobol li imparasse tutti. Questa è una delle ragioni per cui i programmatori Cobol oggi, per la maggior parte, usano ancora la sintassi del 1985.

"Modelli di design" nel software non esistevano nell'era di cui parli, perché il concetto non era stato inventato. Questo non è che io sia sfacciato - in realtà è il motivo; essere chiamato un nome riconoscibile è ciò che rende un modello di progettazione un "modello di progettazione" piuttosto che un semplice codice che continui a utilizzare in una forma o nell'altra (ad esempio una "fabbrica" piuttosto che "il tipo di classe statica che preferisco usare piuttosto che un assortimento di costruttori ") e il concetto stesso non fa eccezione.

Detto questo, naturalmente c'erano cose che svolgevano esattamente lo stesso ruolo nel lavoro dei professionisti come fanno ora i modelli di progettazione. Ma rimarrai deluso nel sentirli: il tipico "trucco dei guru" in quei giorni erano cose che per noi sono abbastanza noiose ora - per es. elenchi collegati singolarmente, loop controllati da un indice incrementato su ogni iterazione, metodi intelligenti di "accessor" che sembrano non fare altro che darti la possibilità di cambiare idea sui dettagli di implementazione in seguito.

È vero, le cose che ora diamo per scontato - che a volte sono persino parte delle lingue che usiamo - erano concetti avanzati (e talvolta gelosamente custoditi) conosciuti solo da codificatori esperti. È probabile che quasi tutto non del tutto banale, che impari in un corso di programmazione di base, abbia attraversato una fase in cui era l'equivalente morale di un "modello di progettazione" per i professionisti dell'epoca. La costruzione del software potrebbe non essere ancora una rigorosa disciplina ingegneristica, ma se si studia lo stato dell'arte degli anni '50 e '60, non si può negare che sia arrivato un modo enorme sin dai suoi inizi.

Il precedente grande paradigma era programmazione strutturata . Invece di UML, c'erano una varietà di diagrammi diversi (diagrammi di flusso, diagrammi di flusso di dati, diagrammi di struttura, ecc.). Lo sviluppo era principalmente dall'alto verso il basso e seguiva un processo di decomposizione funzionale. Una delle idee di base era che la struttura del tuo programma assomigliasse a un diamante: il modulo principale in alto, che si apriva a ventaglio in moduli di controllo di alto livello, che invocavano le routine nei moduli di livello inferiore. Questi moduli di livello inferiore si basavano su moduli ancora di livello inferiore, che alla fine (teoricamente) convergevano su una manciata di routine I / O di base. I moduli di alto livello dovevano contenere la logica del programma, quelli di livello inferiore erano più interessati all'integrità dei dati e alla gestione degli errori.

Importanti concetti introdotti in questo periodo sono stati l'occultamento delle informazioni, la modularità e l'alta coesione / basso accoppiamento. Vedi i lavori di Dave Parnas per alcuni articoli seminali su questi argomenti. Guarda anche il lavoro di Larry Constantine, Tom DeMarco e Ed Yourdon.

Suppongo che uno di grandi dimensioni (oltre alla programmazione strutturata stessa) fosse il concetto di passare un handle in giro - in OO si dispone di un oggetto e contiene stato e funzionalità. Di ritorno prima di OO, avresti un carico di funzioni indipendenti, e passeresti un handle con uno stato tra di loro: un cookie se lo desideri. Questo ti ha dato i principi OO senza avere effettivamente OO.

Si può vedere molto nel vecchio codice Win32, si passerebbe in un HANDLE che sarebbe un tipo opaco che rappresenta uno stato assegnato nel kernel di Windows. Puoi farlo tu stesso passando un puntatore a una struttura che avevi precedentemente assegnato come primo parametro alle funzioni che operavano su quei dati.

Poiché nessuno ha ancora menzionato l'ovvio: un grande modello di design nell'era procedurale era Object. Come molti modelli di design popolari prima (ad esempio, Subroutine) e dopo (ad esempio Iterator), è diventato così popolare che ha persino ottenuto il supporto linguistico.

Una "macchina a stati finiti" può contare come un Pattern e sono stati scritti FSM (ad esempio per i protocolli di comunicazione) usando le lingue pre-OO.

Anche "gestori di interruzioni" e TSR erano popolari ad es. su DOS.

Termini come "Codice degli spaghetti" e "Punto singolo di uscita" sono in realtà dei richiami a quell'epoca. Oggi chiamiamo codice non ci piace "codice spaghetti", ma in realtà è un riferimento al codice legato insieme (male) con GOTO e JMP.

(Oggi subiamo il "codice dei ravioli", in cui il codice è simile a un mucchio di classi non strettamente correlate, molto simile a un piatto di ravioli.Tuttavia, alcuni esperti OO chiedono giustificatamente, "Ma non è quello che OO dovrebbe apparire? ")

"Single Point of Exit" oggi è solo un frustrante refactoring roadbump. Un sacco di sviluppatori di cui parlo non ne hanno nemmeno sentito parlare, e sono stupefatto quando lo spiego. Ma ai vecchi tempi significava non saltare improvvisamente da un blocco di codice & nel codice degli spaghetti. Salta in avanti fino alla fine della logica, quindi esci con garbo.

Estendendo la mia memoria, molto indietro, mi sembra di ricordare che l'idea di raggruppare il codice nelle procedure è stato un grande passo avanti. L'idea di poter impacchettare le procedure in Moduli interoperabili e riutilizzabili era una specie di Santo Graal della programmazione.

EDIT: "Codice auto-modificante" era anche un pattern usato in particolare sul Doom originale. È qui che il programma sovrascrive effettivamente le sue istruzioni con istruzioni più veloci in base al suo stato. Quando ero un tyke che frequentava un corso di programmazione al Museo delle Scienze, il mio istruttore ci ha avvertito severamente, "Non scrivere codice auto-modificante!"

MODIFICA MODIFICA: tuttavia, prima di Internet, la parola viaggiava molto più lentamente. L'idea di implementare Algoritmi e Strutture Dati era un affare molto più grande. Oggi faccio sempre tutto il resto senza nemmeno sapere che tipo sto usando. Ma allora dovevi codificarti da solo. Ricordo un articolo che parlava di sfide di programmazione che prima richiedevano giorni che oggi abbiamo messo fuori combattimento in mezz'ora o meno. La programmazione "algoritmica" e "data stucture" così concreta sarebbe probabilmente nella lista, molto più di oggi.