Was waren die Entwurfsmuster der Ära der prozeduralen Programmierung? [geschlossen]

Ähnlich: Wie wurde vor 20 Jahren programmiert?

OOP ist heutzutage ziemlich in Mode und hat seine Wurzeln in Simula 67 in den 1960er Jahren und wurde später von Smalltalk und C ++ populär gemacht . Wir haben DRY, SOLID, viele Bücher über Designmuster in der objektorientierten Welt.

Aber was waren die Hauptprinzipien der Programmierung vor der Übernahme des OOP-Paradigmas? Und was waren die wichtigsten Designmuster?

Ich war ein Cobol-Entwickler, bevor ich Java lernte. Ich habe seit über 35 Jahren entwickelt.

In den Tagen der Verfahrenssprachen erfolgte der größte Teil der Verarbeitung im Batch. Gehen Sie in der Geschichte weit genug zurück, und sogar die Programmerstellung wurde mit einem Stapel Lochkarten durchgeführt.

Entgegen Kilian Foths Behauptung hatten wir bereits in den 1970er und 1980er Jahren Designmuster. Es gab eine bestimmte Möglichkeit, einen Match / Merge mit mehreren Dateien in Cobol zu codieren. Es gab eine bestimmte Möglichkeit, das Hinzufügen von Transaktionen zur Masterdatei (Banddatei) in Cobol zu codieren. Es gab eine bestimmte Möglichkeit, in Cobol Berichte zu erstellen. Aus diesem Grund hat IBMs Report Writer in vielen Cobol-Läden nie wirklich Fuß gefasst.

Es gab eine frühe Anwendung des DRY-Prinzips. Erstellen Sie viele Absätze, damit Sie sich nicht wiederholen. Strukturierte Codierungstechniken wurden in den 1970er Jahren entwickelt und Cobol fügte der Sprache 1985 strukturierte Wörter (Verben) hinzu.

Als wir ein neues Cobol-Programm geschrieben haben, haben wir im Allgemeinen ein altes Cobol-Programm kopiert und die Namen geändert, um die Unschuldigen zu schützen. Wir haben fast nie ein Cobol-Programm von einem leeren Blatt Papier oder einem leeren Bildschirm codiert. Das ist ein großes Entwurfsmuster, wenn Sie ganze Programme kopieren und einfügen können.

Es gab so viele Cobol-Designmuster, dass ein Cobol-Programmierer Jahre brauchte, um sie alle zu lernen. Das ist ein Grund, warum die Cobol-Programmierer heute zum größten Teil immer noch die 1985-Syntax verwenden.

"Design Patterns" in Software gab es in der Ära, von der Sie sprechen, nicht, weil das Konzept nicht erfunden worden war. Das bin ich nicht in der frivol - es tatsächlich ist der Grund; Ein erkennbarer Name ist das, was ein Entwurfsmuster zu einem "Entwurfsmuster" macht und nicht nur zu Code, den Sie in der einen oder anderen Form weiter verwenden (z. B. eine "Factory" anstelle einer "Art statischer Klasse", die ich lieber verwende als eine Auswahl von Konstrukteuren ") und das Konzept selbst ist keine Ausnahme.

Das heißt, es gab natürlich Dinge, die in der Arbeit der Praktiker genau dieselbe Rolle spielten, wie dies jetzt bei Entwurfsmustern der Fall ist. Aber Sie werden enttäuscht sein, wenn Sie von ihnen hören: Typische "Tricks der Gurus" waren damals Dinge, die uns jetzt ziemlich langweilig sind - z. B. einfach verknüpfte Listen, Schleifen, die von einem Index gesteuert werden, der bei jeder Iteration erhöht wird, kluger "Accessor msgstr "" "Methoden, die nichts anderes zu tun scheinen, als Ihnen Spielraum zu geben, Ihre Meinung zu Implementierungsdetails später zu ändern.

Richtig, Dinge, die wir heute für selbstverständlich halten - die manchmal sogar Teil der von uns verwendeten Sprachen sind -, waren früher fortgeschrittene (und manchmal eifersüchtig gehütete) Konzepte, die nur erfahreneren Programmierern bekannt waren. Die Chancen stehen gut, dass fast alles, was Sie heute in einem grundlegenden Programmierkurs lernen, eine Phase durchlief, in der es für die Praktiker der Zeit das moralische Äquivalent zu einem "Designmuster" war. Softwarekonstruktion mag noch keine strenge technische Disziplin sein, aber wenn Sie den Stand der Technik der 50er und 60er Jahre studieren, können Sie nicht leugnen, dass sie von Anfang an einen enormen Weg zurückgelegt hat.

Das vorherige große Paradigma war die strukturierte Programmierung . Anstelle von UML gab es verschiedene Diagramme (Flussdiagramme, Datenflussdiagramme, Strukturdiagramme usw.). Die Entwicklung erfolgte größtenteils von oben nach unten und folgte einem Prozess der funktionellen Zersetzung. Eine der Grundideen war, dass Ihre Programmstruktur einem Diamanten ähneln sollte: Das Hauptmodul oben, das sich in übergeordnete Steuerungsmodule aufteilt, die Routinen in untergeordneten Modulen aufriefen. Diese untergeordneten Module basieren auf noch untergeordneten Modulen, von denen alle (theoretisch) auf eine Handvoll grundlegender E / A-Routinen konvergierten. Übergeordnete Module sollten die Programmlogik enthalten, untergeordnete befassten sich mehr mit Datenintegrität und Fehlerbehandlung.

Wichtige Konzepte, die in dieser Zeit eingeführt wurden, waren das Verstecken von Informationen, Modularität und hohe Kohäsion / niedrige Kopplung. In den Werken von Dave Parnas finden Sie einige wegweisende Artikel zu diesen Themen. Schauen Sie sich auch die Arbeiten von Larry Constantine, Tom DeMarco und Ed Yourdon an.

Ich nehme an, ein großer Punkt (neben der strukturierten Programmierung selbst) war das Konzept, ein Handle zu übergeben - in OO haben Sie ein Objekt und es enthält Status und Funktionalität. Vor OO hatten Sie eine Menge unabhängiger Funktionen, und Sie würden ein Handle an einen Zustand zwischen ihnen übergeben - ein Cookie, wenn Sie möchten. Dies gab Ihnen OO-Prinzipien, ohne tatsächlich OO zu haben.

Sie können dies häufig im alten Win32-Code sehen. Sie übergeben einen HANDLE, der ein undurchsichtiger Typ ist, der einen im Windows-Kernel zugewiesenen Status darstellt. Sie können dies selbst tun, indem Sie einen Zeiger auf eine Struktur übergeben, die Sie zuvor als ersten Parameter für Funktionen zugewiesen haben, die diese Daten verarbeiten.

Da noch niemand das Offensichtliche erwähnt hat: Ein großes Entwurfsmuster in der prozeduralen Ära war Object. Wie viele gängige Entwurfsmuster vor (z. B. Subroutine) und nach (z. B. Iterator) wurde es so beliebt, dass es sogar Sprachunterstützung erhielt.

Eine "endliche Zustandsmaschine" kann als Muster gelten, und FSMs wurden (z. B. für Kommunikationsprotokolle) unter Verwendung von Pre-OO-Sprachen geschrieben.

Auch "Interrupt-Handler" und TSRs waren früher beliebt, zB unter DOS.

Begriffe wie "Spaghetti Code" und "Single Point of Exit" sind Rückschläge in diese Zeit. Heutzutage nennen wir Code, den wir nicht als "Spaghetti-Code" bezeichnen, aber das ist wirklich ein Hinweis auf Code, der (schlecht) mit GOTOs und JMPs verbunden ist.

(Heute leiden wir unter "Ravioli-Code", in dem der Code wie ein Bündel nicht verwandter, dicht gepackter Klassen ist, ähnlich wie ein Teller Ravioli. Einige OO-Experten fragen jedoch zu Recht: "Aber ist es nicht das, was OO soll aussehen wie?")

"Single Point of Exit" ist heutzutage nur ein frustrierender Refactoring-Roadbump. Viele Entwickler, mit denen ich gesprochen habe, haben noch nicht einmal davon gehört und sind entsetzt, wenn ich es erkläre. Aber früher hieß es, nicht plötzlich aus einem Codeblock in Spaghetti-Code zu springen. Springe vorwärts zum Ende der Logik und verlasse sie dann mit Anmut.

Ich erinnere mich immer wieder daran, dass die Idee, Code in Prozeduren zu bündeln, ein großer Fortschritt war. Die Idee, Prozeduren in interoperable, wiederverwendbare Module zu packen, war eine Art Heiliger Gral der Programmierung.

BEARBEITEN: "Selbstmodifizierender Code" war auch ein Muster, das insbesondere im ursprünglichen Doom verwendet wurde. Dort würde das Programm seine Anweisungen tatsächlich mit schnelleren Anweisungen überschreiben, die auf seinem Status basieren. Als ich ein Typ war, der einen Programmierkurs im Science Museum belegte, warnte mich mein Ausbilder streng: "Schreiben Sie keinen selbstmodifizierenden Code!"

BEARBEITEN BEARBEITEN: Vor dem Internet verbreitete sich das Wort jedoch viel langsamer. Die Idee, Algorithmen und Datenstrukturen zu implementieren, war früher viel wichtiger. Heute sortiere ich die ganze Zeit, ohne zu wissen, welche Sorte ich benutze. Aber damals musste man es selbst verschlüsseln. Ich erinnere mich an einen Artikel über Programmierherausforderungen, die früher Tage in Anspruch nahmen, die wir heute in einer halben Stunde oder weniger überwunden haben. Wahrscheinlich würde die wirklich bewusste "algorithmische" und "Datenstruktur" -Programmierung auf der Liste stehen, viel mehr als heute.