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

Simile: Com'è stata fatta la programmazione 20 anni fa?

OOP è piuttosto di moda al giorno d'oggi, affondando le sue radici in Simula 67 negli anni '60 e in seguito reso popolare da Smalltalk e C ++ . Abbiamo DRY, SOLID, molti libri sui modelli di design nel mondo orientato agli oggetti.

Ma quali erano i principi fondamentali nella programmazione prima dell'adozione su larga scala del paradigma OOP? E quali sono stati i principali modelli di design?

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

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

Contrariamente a quanto afferma Kilian Foth , negli anni '70 e '80 abbiamo avuto modelli di design. Esisteva un certo modo per codificare una corrispondenza / unione di più file in Cobol. Esisteva un certo modo per codificare l'aggiunta di transazioni al file master (nastro) in Cobol. C'era un certo modo per codificare la generazione di report in Cobol. Ecco perché il Report Writer di IBM non ha mai veramente preso piede in molti negozi Cobol.

C'è stata una prima applicazione del principio DRY. Crea molti paragrafi in modo da non ripetere te stesso. Negli anni '70 furono sviluppate tecniche di codifica strutturata e Cobol aggiunse parole strutturate (verbi) alla lingua nel 1985.

Generalmente, quando abbiamo scritto un nuovo programma Cobol, abbiamo copiato un vecchio programma Cobol e cambiato i nomi per proteggere gli innocenti. Non abbiamo quasi mai codificato un programma Cobol da un foglio di carta bianco o da uno schermo vuoto. Questo è un grande modello di progettazione quando è possibile copiare e incollare interi programmi.

C'erano così tanti modelli di design Cobol che ci vollero anni perché un programmatore Cobol li imparasse tutti. Questo è uno dei motivi per cui i programmatori Cobol oggi usano, per la maggior parte, la sintassi del 1985.

I "modelli di progettazione" nel software non esistevano nell'era di cui parli, perché il concetto non era stato inventato. Non sono io ad essere irriverente - in realtà è la ragione; essere chiamato un nome riconoscibile è ciò che rende un modello di progettazione un "modello di progettazione" piuttosto che solo il codice che si continua a utilizzare in una forma o nell'altra (ad esempio, una "fabbrica" ​​anziché "il tipo di classe statica che mi piace usare anziché un assortimento di costruttori ") e il concetto stesso non fa eccezione.

Detto questo, ovviamente ci sono state cose che hanno svolto esattamente lo stesso ruolo nel lavoro dei professionisti come fanno ora i modelli di progettazione. Ma rimarrai deluso nel sentirli parlare: il tipico "trucco dei guru" a quei tempi erano cose che per noi sono abbastanza noiose ora - ad esempio elenchi collegati singolarmente, loop controllati da un indice incrementato su ogni iterazione, intelligente "accessorio "metodi che sembrano non fare altro che darti margine per cambiare idea sui dettagli di implementazione in un secondo momento.

Esatto, le cose che ora diamo per scontate - che a volte fanno addirittura parte delle lingue che usiamo - erano concetti avanzati (e talvolta gelosamente custoditi) conosciuti solo da programmatori più esperti. Le probabilità sono, quasi tutto, non del tutto banali che apprendi in un corso di programmazione di base oggi attraversato una fase in cui era l'equivalente morale di un "modello di progettazione" per i praticanti dell'epoca. La costruzione del software potrebbe non essere ancora una disciplina ingegneristica rigorosa, ma se studi lo stato dell'arte degli anni '50 e '60, non puoi negare che è arrivata in modo enorme sin dai suoi inizi.

Il precedente grande paradigma era la 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 è stato prevalentemente top-down e ha seguito un processo di decomposizione funzionale. Una delle idee di base era che la struttura del programma dovesse assomigliare a un diamante: il modulo principale in alto, che si trasformava in moduli di controllo di alto livello, che invocava routine nei moduli di livello inferiore. Questi moduli di livello inferiore si basavano su moduli ancora di livello inferiore, i quali (teoricamente) alla fine convergevano su una manciata di routine di I / O di base. I moduli di alto livello dovevano contenere la logica del programma, quelli di livello inferiore erano maggiormente interessati all'integrità dei dati e alla gestione degli errori.

Concetti importanti introdotti in questo periodo erano nascondimento delle informazioni, modularità ed elevata coesione / basso accoppiamento. Vedi le opere di Dave Parnas per alcuni documenti fondamentali su questi argomenti. Scopri anche il lavoro di Larry Constantine, Tom DeMarco ed Ed Yourdon.

Suppongo che uno di grandi dimensioni (oltre alla stessa programmazione strutturata) fosse il concetto di far passare una maniglia - in OO hai un oggetto e contiene stato e funzionalità. Prima di OO, avresti un sacco di funzioni indipendenti e passeresti una maniglia in qualche stato tra loro - un cookie se vuoi. Questo ti ha dato i principi di OO senza effettivamente OO.

Puoi vederlo molto nel vecchio codice Win32, passeresti un HANDLE che sarebbe un tipo opaco che rappresenta uno stato allocato nel kernel di Windows. Puoi farlo tu stesso passando un puntatore a una struttura che hai precedentemente assegnato come primo parametro alle funzioni che hanno operato su quei dati.

Dato che nessuno ha ancora menzionato l'ovvio: un grande modello progettuale nell'era procedurale era Object. Come molti modelli di progettazione 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ò essere considerata un modello e gli FSM sono stati scritti (ad es. Per i protocolli di comunicazione) usando linguaggi pre-OO.

Anche "gestori di interrupt" e TSR erano molto diffusi, ad esempio su DOS.

Termini come "Spaghetti Code" e "Single Point of Exit" sono in realtà un ritorno a quell'epoca. Al giorno d'oggi chiamiamo codice che non ci piace "spaghetti code", ma in realtà è un riferimento al codice collegato (malamente) con GOTO e JMP.

(Oggi subiamo il "codice dei ravioli", in cui il codice è come un gruppo di classi non correlate, strettamente imballate, proprio come un piatto di ravioli. Tuttavia, alcuni esperti di OO chiedono giustamente, "Ma non è questo ciò che OO dovrebbe Assomiglia a?")

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

Allungando la mia memoria molto indietro, mi sembra di ricordare che l'idea di raggruppare il codice in procedure è stato un grande balzo in avanti. L'idea che si potesse impacchettare le procedure in moduli interoperabili e riutilizzabili era una specie di Santo Graal di programmazione.

EDIT: "Codice auto-modificante" era anche un modello 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 tipo che frequentava un corso di programmazione al Museo delle Scienze, il mio istruttore ci avvertì 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 l'ordinamento tutto il tempo senza nemmeno sapere quale tipo sto usando. Ma allora dovevi codificarlo tu stesso. Ricordo un articolo che parlava di sfide di programmazione che un tempo richiedevano giorni che oggi eliminiamo in mezz'ora o meno. Quindi la programmazione "algoritmica" e "struttura dei dati" davvero concisa sarebbe probabilmente sulla lista, molto più di oggi.